Settings ownership

The native ownership declarations and reconciliation journal bound what harness sync may write. claude/OWNERSHIP.json records the Claude template fields. Read it before changing the template.

Claude Code (~/.claude/settings.json)

• Owned keys: outputStyle, plansDirectory, useAutoModeDuringPlan, showThinkingSummaries. Reconciled against the ownership journal; user edits produce conflicts.
• Output style: outputStyle comes from the voice stance, not from the template. A variant with a file in claude/output-styles/ installs that style — scannable installs Scannable — and a variant without one, answer-card and off today, installs none. scannable is likewise the only variant the Codex projection gives presentation material to, which it names explicitly, so both runtimes make the same variant mean the same thing. Ownership is what the reconciliation journal records the harness writing, never what the style is called: a style you chose yourself — including one named Scannable you picked before installing — is never rewritten, never removed at uninstall, and never reported as drift. The style the harness did install is taken back out when the variant changes.
• Posture key: permissions.defaultMode, written only when config permissions is not inherit (bypass → bypassPermissions, auto → auto, manual → default).
• Allow rules: the template’s list is merged as a set into permissions.allow. The list is what lets plan mode run read-only commands without prompting: reads anywhere under home, read-only shell tools the built-in set misses, read forms of gh, npm, cargo, uv, WebSearch, and documentation and registry domains for WebFetch. Rules you added yourself are kept. A rule that an earlier template carried and the current one has dropped is removed at the next sync, so a rule withdrawn here does not outlive it in your settings. Tools whose read-only form depends on their flags (sort, sed, awk, fd, rg, tree) are not in the list; the readonly-bash hook approves their safe invocations and lets sort -o, sed w, fd -x and the like fall through to the prompt.
• Plan mode: no settings key. Under a bypass or auto posture the PreToolUse coordinator answers the investigative calls the allow rules cannot prove, rather than leaving plan mode to prompt below the posture you selected; plan_allow_tools in the user config extends that to named tool globs. What each grade gets: docs/preferences.md.
• Hooks: one shared-policy coordinator at each of PreToolUse, PostToolUse, SessionStart, Stop and SessionEnd, generated by the native adapter. Legacy harness markers are replaced; unrelated hooks remain. The harness owns only its own entries in each event’s list, the ones whose command carries a # harness: marker or names one of its legacy scripts, so a hook you add beside them is not a sync conflict or drift, and uninstall leaves it in place. Add yours as a separate entry: a command put inside one of the harness’s entries makes that entry an edit, which sync reports and uninstall preserves. Policies decide whether the selected stance activates a check.
• Never touched: model, theme, viewMode, effortLevel, alwaysThinkingEnabled, skipDangerousModePermissionPrompt, env, permissions.deny, permissions.ask, and any key not named here.

VS Code (user settings.json)

• Owned: claudeCode.focusView, claudeCode.preferredLocation, claudeCode.hideOnboarding.
• Posture: claudeCode.initialPermissionMode, claudeCode.allowDangerouslySkipPermissions.
• Everything else, including editor, terminal and theme settings, is left alone.

Codex (~/.codex/config.toml)

• Owned: project_doc_fallback_filenames = ["CLAUDE.md"].
• Posture: approval_policy, sandbox_mode, and the approval-reviewer key. Manual requests user review with a read-only sandbox; auto requests automatic review with workspace writes. Both spellings of that key — approvals_reviewer, which current Codex accepts, and the older approval_reviewer — are harness-owned: sync writes the one the installed client accepts and removes the other, and uninstall restores whichever it had written.
• Generated: AGENTS.md, role TOML and workflow skills, tracked in the ownership journal.
• Hooks: the harness’s own entries in each hooks.json event array, beside any you add; native trust is never fabricated.
• Model, reasoning effort, notify hooks, MCP servers, plugins and per-project trust are never touched.

Adding an owned key

Add it to the template, to OWNERSHIP.json, to this page, and to a test in tests/test_harness.py that shows a user’s value for a non-owned key survives the merge.

See installation ownership for adoption, conflict handling and restoration.