The same parameter can come from several sources, and all fine-tuning rests on knowing their precedence. For an ordinary scalar value it is this: managed (the organization's policy) overrides CLI arguments, those override local (personal to this repository), then project (team-shared in the repository) and user (a personal default for all projects). A higher layer overrides the lower ones - this is precedence, and without understanding it, configuration turns into guessing why a value is "wrong".

Layers differ not only in priority but in whether they are committed. managed comes from the administrator and carries mandatory security and compliance rules. user lives in ~/.claude and is not committed - these are personal defaults and UI. project lies in .claude/settings.json and .mcp.json, is committed and sets the team's single workflow. local in settings.local.json is not committed - for machine paths and experiments. It helps to gather this into a table once, to put a setting in the right layer.

The merging of layers works by value type. A scalar value from a higher source simply replaces the lower one. Objects usually deep-merge, and documented arrays may merge and de-duplicate. But there is a principled exception - permission allow, ask and deny: rules from different scopes are kept together rather than replaced. This is done deliberately, so a broad user allow does not erase a project or managed deny; security here matters more than the convenience of overriding.

It helps to see a minimal settings with $schema once, so the editor gives autocomplete and validation. Below is a fragment with a model and permissions. A caveat: the schema may update with a delay relative to the freshest CLI, so on a discrepancy you first check the official settings page and changelog, and then run /doctor. The schema is an editor helper, not the final truth about available keys.