I Put a Setting in My Project Config and It Did Nothing

I put autoMode in .claude/settings.json, committed it, and it had no effect.

The JSON was valid. Startup printed no warning. --debug said nothing. I spent

a while assuming I had the semantics wrong before I found the actual reason:

that key does not apply from that file.

Claude Code's settings reference has a column I had never read carefully. Every

key names the scopes it applies from. Counting it:

Any file                  152 keys
Managed                    39 keys   only from managed settings
User or managed            23 keys   ~/.claude/settings.json, or managed
User, local, or managed     3 keys   settings.local.json but not settings.json
Global config               6 keys   ~/.claude.json only
------------------------------------
                          223 keys, of which 71 are scoped

71 of 223. Put one of those in a project's .claude/settings.json and it is

not an error, produces no warning, and does nothing.

The ones I would expect people to hit:

autoMode                          user or managed
autoMode.classifyAllShell         user or managed
skipAutoPermissionPrompt          user or managed
useAutoModeDuringPlan             user, local, or managed
spellcheck                        user or managed
sandbox.network.strictAllowlist   user or managed
sandbox.filesystem.disabled       user or managed
diffTool                          ~/.claude.json only
autoConnectIde                    ~/.claude.json only

If you run several agents at once you get more approval prompts, so loosening

autoMode is the obvious move — and the obvious place to put it is the project

config you already have open. That is the one place it does not work.

User, local, or managed     3 keys

settings.local.json is a different scope from settings.json. Three keys

apply from the local one and not from the shared one:

useAutoModeDuringPlan`` syncClaudeAiSkills``skipDangerousModePermissionPrompt So: you put one in settings.local.json, it works. Later you move it into the

shared file so the team gets it, and it silently stops. Nothing changed except which file it lives in.

This is a manufactured "works on my machine" — with the unusual property that

the person who wrote it is the one for whom it works.

The documentation names them the way you would write a path, not the way you

would write JSON:

sandbox.network.strictAllowlist        ← this is what is scoped
sandbox                                ← this is not

Which matters if you go looking. I wrote a checker for this and inspected only

the top level of the settings object, so this:

{ "sandbox": { "network": { "strictAllowlist": true } } }

produced nothing at all. 20 dotted keys were invisible to it, 12 of them sandbox.*.

I had been maintaining this list by hand, copied out of the documentation, with

a comment I wrote myself:

/** そのファイルからは効かないスコープのキー（一部。確実なものだけ） */

"Some. Only the certain ones." I knew it was partial. I did not know how partial.

             actual   I had
Managed          39      14
User or managed  23       0     ← the whole row
Global config     6       6

The user or managed row was missing entirely — 23 keys, including autoMode, the one that started this.

I had read the table by grouping it: Managed is for organisations deploying

policy, which is not my situation, so I skipped past it — and past the row

sitting next to it, which turned out to mean "applies from your own ~/.claude/settings.json" and was the row I most needed.

Reading it row by row would have worked. Reading it by category is what failed.

So it is generated now, straight from the scope column, and the count comes out

of the same place the checker reads.

npx @quintetkit/ccheck
warn  .claude/settings.json:63
      `autoMode` applies from user or managed settings only. It has no effect from this file.
      why: https://code.claude.com/docs/en/settings-reference

One thing that took a second pass to get right: ~/.claude/settings.json

is the user scope. Deciding "this key doesn't apply here" from the path alone

would report a correctly placed autoMode on the machine of anyone who runs it

against their home directory — including mine, which has autoMode in it. So

the scope is decided by whether the directory being scanned is your home, not by

what the path looks like.

The full list of 71, and the same list as JSON if you would rather check the

claim than trust it:

https://quintetkit.github.io/en/reference/claude-code-settings-scope.html

I publish the configuration for splitting Claude Code into separate personas —

Architect, Coder, Reviewer, Conflict Resolver — under MIT. Copy it, run

./setup.sh, and it works. It does not depend on your tech stack.

https://github.com/quintetkit/quartet

I built one real tool using nothing but this workflow. Every Issue, PR, review

and merge is still there. The parts that went wrong were not deleted.

https://github.com/quintetkit/mdlinkcheck

The version that adds a UI Designer persona, review criteria, a per-Issue

parallel execution script and a 11-chapter guide is on the

product page.

The full kit — five personas, the scripts and the complete guide — is available here.

source & further reading

dev.to — original article Inside the SFPU: How a 40-Year-Old Rounding Trick Breaks on Modern AI Accelerators From Custom Code to Mature Library: Why I Replaced My SSRF Protection with requests-hardened A Practical Checklist for an Agent-Ready API