[BUG] sandbox.filesystem.allowWrite paths not applied to Bash tool (rm, mv, etc.) — only Write/Edit tools

Status Fixed / completed

Maintainer reply None cached

Activity 5 comments · opened Mar 5, 2026 · closed Mar 5, 2026

Bug Description

Paths added to sandbox.filesystem.allowWrite allow the Write and Edit tools to create/modify files, but the Bash tool cannot write to or delete files in those same paths. Bash commands get Read-only file system errors.

Steps to Reproduce

Add .vscode/** and .claude/** to sandbox.filesystem.allowWrite:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": [
        "dev.azure.com",
        "github.com",
        "*.github.com",
        "npmjs.org",
        "*.npmjs.org",
        "visualstudio.com",
        "*.visualstudio.com"
      ]
    },
    "filesystem": {
      "allowWrite": [
        "~/.npm/**",
        "/tmp/claude-1000/**",
        "/tmp/claude/**",
        ".vscode/**",
        ".claude/**"
      ]
    }
  }
}

Use the Write tool to create .vscode/_test.txt → succeeds (no prompt)
Use the Edit tool to modify .vscode/_test.txt → succeeds (no prompt)
Use Bash to rm .vscode/_test.txt → fails with Read-only file system
Same with absolute path: rm /full/path/to/.vscode/_test.txt → same error

Expected Behavior

sandbox.filesystem.allowWrite paths should apply uniformly to all tools — Write, Edit, and Bash.

Actual Behavior

Write/Edit tools: respect allowWrite paths ✅
Bash tool: ignores allowWrite paths, treats them as read-only ❌

Environment

Claude Code (CLI)
Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2)
Sandbox enabled with autoAllowBashIfSandboxed: true

View original on GitHub ↗

5 Comments

dfaivre-pcs · 7 months ago

Additional finding: The permissions.allow entries for Write/Edit also don't consistently suppress prompts:

"allow": [
    "Edit(.claude/**)",
    "Edit(.vscode/**)",
    "Write(.claude/**)",
    "Write(.vscode/**)"
]

Despite these being in the allow list, Write and Edit tools still prompt for permission on files in .claude/ and .vscode/. The allowWrite sandbox paths and the permissions.allow patterns appear to be evaluated independently, and neither reliably grants unprompted access via all tools.

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

dfaivre-pcs · 7 months ago

Confirmed: Both Write and Edit tools prompt despite being in the allow list.

.claude/_sandbox-test.txt prompt:

Do you want to create _sandbox-test.txt?
  1. Yes
  2. Yes, and allow Claude to edit its own settings for this session
  3. No

.vscode/_sandbox-test.txt prompt:

Do you want to overwrite _sandbox-test.txt?
  1. Yes
  2. Yes, allow all edits during this session (shift+tab)
  3. No

The .claude/ prompt offers "allow Claude to edit its own settings" — suggesting .claude/** paths are hardcoded as "settings" and override permissions.allow entries. The .vscode/ prompt is a standard write prompt, but still shouldn't appear given Write(.vscode/**) is in allow.

So there are two separate issues:

.claude/** paths appear to be force-gated as "settings" regardless of allow rules
.vscode/** allow rules are simply not being matched/applied

dfaivre-pcs · 7 months ago

Closing as duplicate of #17727

github-actions[bot] · 7 months ago

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.

[BUG] sandbox.filesystem.allowWrite paths not applied to Bash tool (rm, mv, etc.) — only Write/Edit tools

Bug Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Environment

5 Comments

Related Claude Code issues

Browse by topic