# Claude Code's settings If you already use Claude Code, a project set up for it should not need setting up a second time. Codey reads three kinds of thing from Claude Code's files — [its MCP servers](mcp.md#claude-codes-servers), its permission rules, and its CLAUDE.md files — and none of it is copied anywhere or written back: change it in Claude Code and the next start here sees the change. **Permissions.** The `permissions` block of three settings files, in the order Claude Code reads them: | File | Whose | `deny` / `ask` | `allow` | `defaultMode` | | --- | --- | --- | --- | --- | | `~/.claude/settings.json` | yours, every project | honoured | honoured | `acceptEdits` only | | `.claude/settings.json` | the repository's, committed | honoured | only once [trusted](mcp.md#trusting-a-project) | ignored | | `.claude/settings.local.json` | yours, this project, git-ignored | honoured | honoured | `acceptEdits` only | The rule underneath that table is who wrote the file. A deny or an ask rule can only make the agent do less or ask more, and nobody comes to harm from that, so a repository may add as many as it likes. An allow rule is the opposite: it is a decision that something runs without you being asked, and a decision written into a repository was made by whoever wrote the repository. The shared file's allow rules therefore wait for the same trust question as its `.mcp.json`, and until you answer it they are listed and ignored. A `settings.local.json` that git turns out to be tracking arrived with the clone, whatever its name says, and is treated as shared. The rules act before anything else in the approval policy. A deny holds in every mode, `-yolo` included — that is what writing it down is for — and it holds for the read-only tools too, since `Read(.env)` is a rule about reading. An ask rule puts the call to you even when the mode would have let it through, and even when you said "always this tool" earlier in the session. An allow rule lets a call through without a prompt. Between them deny beats ask beats allow, as in Claude Code, so no allow rule anywhere argues a call past a deny. The denial the model reads names the rule and the file, so it can tell you which line to change instead of retrying. `/allowed` lists every rule under the file it came from, and says which are in force and why the others are not. Claude Code's names map onto Codey's: `Bash` is `bash`, `Read` is `read_file` (and, as best it can, `glob` and `grep`), `Edit` is both `edit_file` and `write_file`, `MultiEdit` is `edit_file`, `Write` is `write_file`, `Glob`, `Grep`, `WebFetch`, `WebSearch` and `TodoWrite` are the obvious ones, and `mcp__server` and `mcp__server__tool` are unchanged. A rule naming a tool Codey does not have, or written in a form it does not understand, is reported at startup and takes no part. Paths follow Claude Code's conventions: `//path` is absolute, `~/path` is under your home, `/path` is under the project root, and anything else is relative to it, with a bare name such as `.env` matching at any depth the way `.gitignore` would. Links are followed, so a rule about `.env` also catches a symlink to it. `Bash(npm run test:*)` is matched one simple command at a time, using the same parser as the approval prompt. An allow rule covers `npm run test && rm -rf ~` only if something also allows `rm`; a deny rule catches the line if it catches any part of it. A command the parser cannot see through — `$(...)`, backticks, `bash -c`, a variable in command position — never matches an allow rule, and where a deny rule cannot be ruled out for it, the call is asked about rather than run. So is anything that does more than its words say: `PATH=. git status`, or `echo hi > ~/.bashrc`, is not covered by an allow rule for `git` or `echo`. None of this makes shell allowlisting a security boundary — see [Safety](safety.md) — but it does stop the commonest way a prefix rule says yes to something nobody wrote down. `defaultMode: "acceptEdits"` in a file of yours lets file edits through, as Claude Code's mode of that name does. `default` is the default. The other modes are ignored with a notice, from every file: `bypassPermissions` in particular, because in Codey the way to stop being asked is `-yolo`, typed on the command line for one run, and neither a file of yours nor a repository's gets to say it for you. **CLAUDE.md.** The files Claude Code loads into every conversation are loaded into this one's system prompt, at startup, in Claude Code's order: `~/.claude/CLAUDE.md`, then — from the top of the project down to the working root — each directory's `CLAUDE.md`, `.claude/CLAUDE.md` and `CLAUDE.local.md`. The top is the nearest directory with a `.git` in it, or your home directory if there is none on the way; a root that is in neither is a project of one directory, because walking up to `/` would read whatever happened to be lying in `/tmp`. Later files are more specific and the prompt says they win. `@path/to/file` imports are followed, relative to the file they appear in and up to five deep, skipping anything in a code block. A project's files may import only from the project, and that is checked where symlinks lead: a repository's CLAUDE.md that could import `@~/.aws/credentials` would be a repository reading your credentials into a conversation that is then sent to the model. Your own `~/.claude/CLAUDE.md` and `CLAUDE.local.md` may import from your home directory. The whole thing is read once per session, so the cached prompt prefix stays the same from request to request; restart to pick up an edit. `AGENTS.md` is not loaded this way, but the agent is still told to read one if the repository has it, as before, and a CLAUDE.md that says `@AGENTS.md` brings it in. **What is not carried over**, so nobody has to find out the hard way: - Hooks in Claude Code's format (`PreToolUse`, `PostToolUse` and the rest). Codey's [hooks](hooks.md) are a different thing — they watch, they cannot veto — and a script written to block a tool call would silently block nothing here. - `env`, `model`, `apiKeyHelper`, `statusLine`, `outputStyle`, `cleanupPeriodDays` and the other non-permission settings. Codey has its own config for the ones it has an equivalent of. - `permissions.additionalDirectories`: the file tools keep the working root as their only root. - Claude Code's own record of which `.mcp.json` servers you approved (`enabledMcpjsonServers`, `enableAllProjectMcpServers`). It approves by name, so a server whose command changed under the same name would still count; Codey asks its own question about the exact definitions instead. - Managed (enterprise) settings, subdirectory CLAUDE.md files loaded on demand, and `.claude/rules/`. - Remote MCP servers, which Codey's client does not speak.