Three checks for one setting
Start with editor recognition. Then confirm which configuration source the session loaded. Finally, test the action the rule should govern.
← All insights
KN-10 · Configuration gap audit
Do your Claude Code settings do what you think?
A setting can work even if your editor never suggests it. A setting can also be valid and go unread by the session where you need it. This audit counted one schema gap and used the vendor’s documentation to map the other boundaries.
In this article
What the schema audit found
The published JSON schema listed 142 top-level keys on the day of the audit. The mid-September documentation copy had 231 settings headings, a count that may include nested settings. The numbers count different things.
The direct comparison used one working file with 17 top-level keys. Nine were absent from the schema and eight were present. The schema allowed unknown keys, so an absent completion or a passing editor check could leave a typo undetected. The audit did not test whether Claude Code itself warned about unknown keys.
Figure 01Field measurement
Nine keys were missing from editor schema coverage
Top-level keys in the working file
- Present in schema
- 8 of 1747.06%
- Absent from schema
- 9 of 1752.94%
One working file with 17 top-level keys checked against the published schema in early October 2026. The schema accepted unknown keys. Runtime handling was outside the audit.
Which settings reach each session
The original note distinguished local sessions from a cloud clone. The local terminal and desktop app use the same local settings files. Local user and project-local settings stay on the machine. Some keys apply only at specific scopes. The settings screen exposes a subset of options.
The historical note also described folder trust as a boundary for local permission rules: allow rules waited for trust, while deny and ask rules applied before trust. Check the rule in the trust state and release you actually use.
Documentation update, November 6, 2026. Current Claude Code documentation distinguishes three cloud surfaces. A single-repository cloud session outside a project’s threads reads committed shared project settings. In a cloud thread within a project, repository settings do not supply permission rules, hooks or environment variables. An Anthropic-hosted multi-repository session reads only limited marketplace and plugin settings from each repository, and does not take its permission rules, hooks or environment variables from those files. Self-hosted runners have separate configuration rules.
A committed rule can therefore work in one surface and be absent in another. Check the controls available to the target environment, including applicable managed settings.
Figure 02Evidence comparison
The session decides which settings reach it
Local terminal and desktop
Repository or local settingsBoth read the same local settings files.
What to checkVerify the key’s scope and the current trust state.
Single-repository cloud outside a project thread
Repository or local settingsThe clone includes committed shared settings.
What to checkLocal user and project-local settings stay on the machine.
Cloud thread in a project
Repository or local settingsRepository permission rules, hooks and environment values do not apply.
What to checkUse the configuration path documented for project threads.
Anthropic-hosted multi-repository session
Repository or local settingsThe session reads limited marketplace and plugin keys from each repository.
What to checkConfigure permission rules, hooks and environment values through the applicable cloud controls.
Documentation reviewed on November 6, 2026. Check key scope and managed settings for the target environment. Self-hosted runners have separate rules.
What a plugin can carry
Plugins can distribute skills, commands, agents, hooks and servers. A plugin-root CLAUDE.md does not load as project instructions. Anthropic’s plugin reference says its plugin settings accept agent and subagentStatusLine. Permission rules do not take effect through that settings channel.
Ship reusable capabilities as plugins where they fit. Place instructions and permission rules in configuration sources that the target sessions actually read. For a local shared project, that can be a committed project file. Verify cloud configuration separately.
Prove the effect before you rely on the rule
- Check the key and scope in the documentation, then confirm the running session reads the intended source.
- Decide which sessions need the same rule. Configure it in a source supported by each one.
- Test a safe action that should be blocked, and check the observed result.
- Repeat the check when versions or session surfaces change.
How we know
A script counted the schema once in early October 2026. The 231 documentation headings came from a mid-September copy. The 17-key sample was one working file. The session and plugin sections describe documentation, including the November update, rather than runtime tests. Code-level extensions that can refuse calls were outside the audit. The original counts were not rerun for this publication.
Related field notes: Your agent read the rule. Did it follow it? and Your hook blocks the path. Does it block the folder?.