The override doctor could not see
Issue #3877, item 1. A project-scope sandbox.enabled: false wins over a user-scope true, and nothing said so.
1. What was measured, 2026-09-02
| where the probe ran | pastebin.com (denied) | write to ~/ | why |
|---|---|---|---|
headless claude -p from /tmp, no project settings | CONNECT tunnel failed, 403 | refused | user scope sandbox.enabled: true in force |
| interactive session in orchestkit | 200 | succeeded | gitignored .claude/settings.local.json carried "sandbox": {"enabled": false}; CC merges local over user, so the boundary was off |
The gap: doctor read the effective value (false) but never said which file set it or that a user-scope true was being defeated. Check 15 reads settings.local.json only, and the setup 3.6 posture writes the user scope only, so both looked green.
2. Simulate the two scopes
Exit code never changes on this finding. It is warn-level, like the read boundary from #3871: doctor reports, names the file and line, and the operator decides. The remedy is one key in a file doctor will not touch.
3. What the JSON carries
| key | value |
|---|---|
sandbox.source | the file the effective enabled was read from (new) |
sandbox_override | null, or {file, line, user_file, user_line, warning} when a project scope sets false over a user scope that sets true |
| line numbers | the "enabled" line after the "sandbox" key in each file, so the warning reads path:line and is clickable in most terminals |
Not covered: managed settings (invisible to doctor, as before), a CLI flag with no settings key, and a project false with no user true (CC's default is off, so nothing is being overridden). Items 2 and 3 of the issue are operator probes and stay open.