Sandbox auto-adds config/ to denyWithinAllow, breaking git checkout across refs

Summary

Claude Code's sandbox auto-includes config/ (the Rails-conventional config
directory) in its denyWithinAllow list when the working directory is a Rails
project. There is no corresponding user setting — .claude/settings.json,
.claude/settings.local.json, and ~/.claude/settings.json contain no rule
that would produce this entry.

This is the same shape of bug as #40133 (.claude/skills auto-added) and
#51303 (.vscode/ hardcoded deny), but for a directory that is part of normal
application source code, not editor/Claude metadata.

Repro

1. In project with config/, start a Claude Code session with the sandbox enabled.
2. Inspect the Bash tool's sandbox block in the system prompt — config/

appears in denyWithinAllow despite no user config asking for it.

1. Have Claude run git checkout <other-ref> where <other-ref> differs in

any file under config/.

Expected

git checkout succeeds; the working tree matches the target ref.

Actual

git checkout partially succeeds — HEAD moves to the target ref, but the
sandbox blocks the unlink/replace of files inside config/:

warning: unable to unlink 'config/<file>': Operation not permitted
error: unable to unlink old 'config/application.rb': Operation not permitted
error: unable to unlink old 'config/database.yml': Operation not permitted
error: unable to unlink old 'config/routes.rb': Operation not permitted
...

The working tree is left in a hybrid state: target ref's commit pointer, but
the previous ref's config/* files still on disk. Returning to the original
ref then fails because the tree is dirty:

error: Your local changes to the following files would be overwritten by checkout:
    config/application.rb
    config/database.yml
    ...

Impact

This silently corrupts any workflow that uses git checkout to switch refs —
e.g. baseline-vs-HEAD performance benchmarking, bisecting, or comparing
behavior across branches. Measurements taken after the partial checkout are
invalid because they run against a hybrid tree, but neither Claude nor the
user gets a clear error at the point the corruption happens.

Environment

• Platform: macOS (sandbox-exec, not bwrap)

Asks

1. Document where the denyWithinAllow list comes from — currently undocumented

(the published settings docs cover allowWrite/denyWrite/denyRead/
allowRead only).

1. Either don't auto-add config/ (standard for Rails projects), or make git checkout

(and similar tree-mutating git operations) bypass the sandbox by default.

1. At minimum, fail loudly when a git command can't fully apply a tree

change because of sandbox restrictions, instead of leaving the working
tree silently corrupted.

Related

• #40133 — .claude/skills auto-added to denyWithinAllow
• #51303 — Sandbox blocks git checkout/worktree add on repos tracking

.vscode/ (closed as duplicate of #46000)

• #46000 — Sandbox filesystem rules can't scope to git root