[BUG] sandbox.enabled: false does not disable bwrap when working directory is ~/.claude/

[vnz]

Description

When the working directory is ~/.claude/ (e.g., when ~/.claude is a git repo for version-controlling settings/skills), all Bash commands fail with bwrap errors — even when the sandbox is explicitly disabled via every available method.

Steps to reproduce

1. Have ~/.claude as a git repo (version-controlled settings, skills, hooks)
2. Set sandbox.enabled: false in ~/.claude/settings.json
3. Start Claude Code with ~/.claude as the working directory
4. Run any Bash command

Expected behavior

Bash commands execute without bwrap wrapping when sandbox.enabled: false.

Actual behavior

Every Bash command fails with:

bwrap: Can't create file at /home/<user>/.claude/.github: Read-only file system

The specific path changes as directories are created (first scripts, then .github, etc.) — bwrap tries to set up overlay mount points for denyWithinAllow paths relative to the working directory.

What I've tried (none work)

Method	Result
sandbox.enabled: false in ~/.claude/settings.json	Still uses bwrap
sandbox.enabled: false in .claude/settings.local.json	Still uses bwrap
/sandbox toggle (shows "Sandbox disabled")	Still uses bwrap
dangerouslyDisableSandbox: true on tool calls	Still uses bwrap

Non-Bash tools (Read, Edit, Glob, Grep) work fine — only Bash is affected.

Root cause hypothesis

bwrap's denyWithinAllow list auto-includes paths like .claude/skills, .claude/hooks, .claude/settings.json relative to the working directory. When the working directory IS ~/.claude/, these resolve to paths inside the config directory itself. bwrap tries to create bind-mount file nodes for each, hitting read-only overlay conflicts.

Additionally, per #19996, the sandbox dependency check may run before config files are read, so sandbox.enabled: false never takes effect.

Environment

• Claude Code: v2.1.101 (latest)
• OS: Linux 6.18.21
• Shell: bash
• Working directory: ~/.claude/ (git repo)

Related issues

• bwrap: Can't create file at .claude/skills: Is a directory when sandbox enabled with symlink SSOT structure #40133 — bwrap fails with .claude/skills as symlink (same bwrap error pattern)
• [BUG] Cowork fails on macOS - checks for bubblewrap (Linux-only) instead of using Seatbelt #19996 — sandbox config read order (sandbox check before config load)
• [BUG] Windows: sandbox bash ignores CLAUDE_CODE_SHELL and sandbox.enabled: false (v2.1.59) #28880 — sandbox.enabled: false ignored on Windows
• [BUG] Linux sandbox broken - bad bwrap calls and no allow permissions #17727 — Linux sandbox broken with bad bwrap calls

[Alexendros]

Adding a confirmed instance and a verified local workaround for the symlink-to-directory variant of this denyWithinAllow family of bugs (closer to #40133 than to the read-only-overlay shape in this issue's OP).

Environment

• OS: Fedora Silverblue 43 (rpm-ostree), kernel 6.19.14-300.fc44.x86_64
• Claude Code CLI: v2.1.126 (/var/home/<user>/.local/share/claude/versions/2.1.126)
• bwrap (bubblewrap): system default on Silverblue 43
• ~/.claude/ is a local git repo for version-controlling skills/hooks/settings/cuadernos
• /etc/claude-code/managed-settings.json does not exist on this host

Symptom

Any Bash invocation under default sandbox aborts before running the user command:

bwrap: Can't create file at /var/home/<user>/.claude/skills: Is a directory

dangerouslyDisableSandbox: true mitigates the main thread but does not propagate reliably to sub-agents (Task, Explore, Plan, custom verifiers), which silently degrade to read-only tooling.

The hardcoded denyWithinAllow list is larger than the user-visible system prompt suggests

The system prompt at session start declared a 5-entry denyWithinAllow containing only ~/.claude/skills as a user-path. After triggering the failure and iterating, I confirmed empirically that v2.1.126 has three symlink-to-directory entries under ~/.claude/ that bwrap chokes on, not just one:

1. ~/.claude/skills (symlink → herramientas/skills/)
2. ~/.claude/commands (symlink → herramientas/scripts/commands/)
3. ~/.claude/agents (symlink → herramientas/agents/)

Reproduction (the canary): replace each symlink with an empty physical directory one at a time and run echo OK under default sandbox. bwrap successively reports each entry, in this order, until all three are physical dirs — at which point Bash starts working without bypass. Other top-level symlinks under ~/.claude/ (hooks, scripts, plugins, templates) are NOT in denyWithinAllow and do not trigger the failure regardless of their type.

This means downstream users with the recommended ~/.claude/{agents,commands,skills} symlink layout (e.g. when separating user-content from harness internals) hit the bug on three entries, not one. Whatever fix lands needs to consider all three.

Verified local workaround (applied 2026-05-01)

Convert each of the three paths from symlink-to-directory into a physical directory, and invert the symlink for backward compatibility:

# For each of skills, commands, agents:
rm ~/.claude/skills
mv ~/.claude/herramientas/skills ~/.claude/skills           # canonical path becomes a real dir
ln -s ../skills ~/.claude/herramientas/skills               # legacy path now a symlink → physical dir
# (commands and agents follow the same pattern; commands needs ../../commands due to depth)

Result after applying to all three paths:

• bash -c 'echo OK' works under default sandbox on the main thread, no dangerouslyDisableSandbox needed.
• Sub-agents (Task / Explore) can run Bash trivially without a bypass prompt.
• find ~/.claude/skills -name SKILL.md | wc -l returns the expected count (83 in my case).
• All previous absolute references via ~/.claude/herramientas/{skills,agents,scripts/commands}/... keep resolving thanks to the inverted symlinks, so existing hooks, agents, and documentation do not need a rewrite pass.

This is non-destructive (full tar backup of the three dirs takes ~234 KB in my setup, instant mv because everything is on the same filesystem) and transparently reversible.

Suggestions for an upstream fix

In rough order of intrusiveness:

1. Tolerate symlink-to-directory in denyWithinAllow setup. When the entry resolves to a directory (via lstat/stat), use a read-only bind-mount of an empty tmpfs dir instead of open(O_CREAT) for the placeholder. This fixes both this variant and bwrap: Can't create file at .claude/skills: Is a directory when sandbox enabled with symlink SSOT structure #40133 without changing semantics.
2. Honor sandbox.enabled: false before evaluating denyWithinAllow. This is the parent issue described by the OP of [BUG] sandbox.enabled: false does not disable bwrap when working directory is ~/.claude/ #46560 and [BUG] Cowork fails on macOS - checks for bubblewrap (Linux-only) instead of using Seatbelt #19996; addressing it would also work around the present case as a side effect.
3. Make the auto-generated denyWithinAllow list visible and overridable from settings.json. Today it appears in the system prompt but is hardcoded; users hitting this variant cannot opt out without binary patching. Even a documented sandbox.denyWithinAllow.disable: ["skills","commands","agents"] knob would unblock the affected workflows.
4. Document the workaround. Until (1)-(3) ship, acknowledging in the README/troubleshooting section that turning the three offending symlinks into physical directories resolves the bug at zero data risk would save users a lot of bypass churn.

Related issues

• bwrap: Can't create file at .claude/skills: Is a directory when sandbox enabled with symlink SSOT structure #40133 (CLOSED · duplicate of [BUG] bwrap sandboxing regression in 2.1.2+: broken with ~/ symlinks #18631) — same EISDIR symptom on WSL2, also symlink-to-directory; this comment confirms the pattern persists in v2.1.126 and broadens it from one path to three.
• [BUG] bwrap sandboxing regression in 2.1.2+: broken with ~/ symlinks #18631 (CLOSED · duplicate root) — original closure; suggesting reopen or umbrella consolidation here.
• [BUG] bwrap fails in a worktree when .claude/skills is a symlink in a repository #44567 (OPEN) — symlink + git-worktree variant; same family.
• [BUG] Cowork fails on macOS - checks for bubblewrap (Linux-only) instead of using Seatbelt #19996 — sandbox config read order; related but distinct.

Happy to share traces, the exact reproduction script, or test patches against this environment.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.