claude-code - 💡(How to fix) Fix Sandbox auto-adds config/ to denyWithinAllow, breaking git checkout across refs [1 comments, 2 participants]

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.
3. 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).
2. 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.
3. 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