fix(claudecode): refuse managed-only sandbox paths and aggregate the trust warnings

[dyoshikawa]

Works through the five follow-ups deferred from the review of #2720.

1. Managed-scope sandbox restriction paths

sandbox.filesystem.allowManagedReadPathsOnly and sandbox.network.allowManagedDomainsOnly are both documented with a Managed scope in the settings reference, and the sandboxing guide says the same in prose ("Set allowManagedReadPathsOnly to true in managed settings ..."). Neither file rulesync writes is the managed settings file, so both are now dropped in both scopes with a warning naming that file — the sandbox counterpart of the treatment CLAUDECODE_UNHONORED_KEY_SOURCES already gives the Managed top-level keys.

They are dropped rather than warned about because they only ever narrow: a sandbox block that reads as though it locked the policy to managed values, while Claude Code ignores it, is the worse of the two failure modes. Import keeps them, unlike the command-executing paths: a value already hand-written in a settings.json was written to be honored somewhere, so round-tripping it preserves that intent for the day it moves into a managed file, at the cost of a warning on every generate until it is removed. That reasoning is now in the table's JSDoc.

2. Warning volume and aggregation

The trust warnings from the permissions fields, the sandbox paths and the top-level passthrough are now collected into one summary line per file:

Claude Code permissions: writing 4 trust-affecting settings to settings.json; review them as you would a hook, especially if this permissions file came from 'rulesync fetch'. 'permissions.defaultMode: "acceptEdits"' — every file edit is then applied without a prompt; 'sandbox.enabled' — turns the sandbox on, ...; 'env' — sets environment variables for every process Claude Code spawns, ...

The per-key reasons are what differ; the "review this as you would a hook" framing only needed saying once, and repeating it per key buried them. The refusal warnings (a key or path that is not written) stay one per key — each carries its own remediation instruction.

3. value !== false on documented defaults

Kept, with the reason now recorded next to both predicates. allowUnsandboxedCommands and autoAllowBashIfSandboxed do default to true, but a project .claude/settings.json outranks the user file, so an explicit true from a fetched override re-opens the escape hatch a user's false closed — and it does so without changing anything a diff of the effective policy would show.

4. Future warn candidates

All six were checked against the settings reference. Every one is scoped Any file, so none is skipped at project scope; all are added to CLAUDECODE_TRUST_AFFECTING_KEYS, four of them with a widening-value predicate so the restrictive value stays quiet:

Key	Scope	Warned at
claudeMdExcludes	Any file	a non-empty list (drops the CLAUDE.md files it matches)
modelOverrides	Any file	a non-empty map (decides which endpoint a prompt reaches)
skipWebFetchPreflight	Any file	true (turns off the WebFetch domain safety check)
remoteControlAtStartup	Any file	true, in the global scope only
prUrlTemplate	Any file	any value (rewrites the PR links Claude Code renders)
companyAnnouncements	Any file	a non-empty list

remoteControlAtStartup turned out to be the one key whose scope depends on its value: Claude Code honors a false from project or local settings but ignores a true, so a checked-in file cannot turn Remote Control on for everyone who opens the repository. A project-scope true is therefore skipped with its own warning and emitted only under --global; a false is written and says nothing.

5. Defensive Object.hasOwn

CLAUDECODE_TRUST_KEY_WIDENING_VALUES[canonicalKey] is now guarded, so the lookup is safe on its own terms rather than because the CLAUDECODE_TRUST_AFFECTING_KEYS check happens to short-circuit first. Note that no test can distinguish the guarded lookup from the unguarded one today — the two tables' key sets are disjoint, so the earlier check short-circuits before the lookup is reached. The accompanying test pins that short-circuit order, not the guard itself.

Review follow-ups

Applied after the first review round:

• The three strip*SandboxPaths functions were byte-identical apart from their table and message. They are now one stripSandboxPaths over a list of SandboxPathRefusal records, which also drops the override from three nested structuredClones to one.
• The widening predicates are named helpers (isNotFalse, isNotTrue, isNonEmptyList, isNonEmptyMap) shared across the table, each stating the restrictive value and reporting everything else. skipWebFetchPreflight and disableSkillShellExecution previously matched their widening value exactly, so an off-type value such as 1 was written with no warning at all.
• remoteControlAtStartup's predicate is shared between the widening table and the project-scope drop table instead of written out twice.
• crossSessionInbound is added to CLAUDECODE_TRUST_AFFECTING_KEYS. It is on the same stricter-value-wins list, but its project value is honored only when it is stricter than the one above it, which no per-value predicate can decide without reading the user's settings. Under --global a fetched "accept" is honored outright, so it is warned about rather than dropped.
• The widening it.each now carries a 0-or-1 element list of quiet values, so "no quiet value" (prUrlTemplate) cannot be confused with a quiet value that happens to be undefined.

Verification

pnpm cicheck passes. claudecode-permissions.test.ts grows from 107 to 123 tests, covering the aggregated summary (count, singular/plural, silence when nothing widens), the managed-only drops in both scopes, each new key at both its widening and its quiet value, all three remoteControlAtStartup cases, and a settings key named after an Object.prototype member.

Closes #2721

[dyoshikawa]

@dyoshikawa Thank you!