[BUG] SANDBOX: Cannot express “workspace-only filesystem access” with current sandbox rules

[smolcompute]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Expected Sandbox Possible Rules Setup

1. Allow all Read|Edit|Write inside the workspace (CWD).
2. Hard-block all filesystem access outside the workspace (CWD).

Actual

Because deny trumps everything else and the rules don't allow for exceptions, any deny hierarchically higher than the CWD will also block the CWD ...

With precedence Deny > Ask > Allow and no exception/negation syntax, any deny that matches a parent scope (e.g., ~/) also blocks the workspace subtree when the workspace lives under it. A parent-escape rule like ../ does not catch absolute paths (/Users/...), ~, or symlink targets. “Ask” is not a boundary because user consent allows the read.

Why this cannot be modeled today

1.	No “except” rules; deny always wins across User + Workspace scopes.
2.	No predicate like “inside workspace realpath,” so absolute or ~ paths bypass ../**.
3.	Symlinks can point outside the workspace; string patterns don’t resolve targets.
4.	A blanket deny(//**), which would seem to help, also kills absolute paths to files inside the workspace and cannot be overridden.

Workarounds (insufficient)

•	Keep the workspace under ~ and maintain a growing deny list for home subtrees + system roots. Fragile and high-maintenance.
•	Move the workspace outside ~ (e.g., /Users/Shared/CWD) so you can deny ~/** globally and explicitly allow the workspace path. Closer to a dev container, but requires relocation.

Request

Add a first-class way to confine file access to the workspace, for example: • A boolean workspaceOnlyFs: true that restricts all file ops to the workspace realpath. • Or a path predicate insideWorkspace() evaluated on the resolved realpath. • Or scoped precedence that lets a Workspace allow override a broader User deny only for the workspace subtree. • Optionally resolve symlinks before policy evaluation to prevent path tunneling.

What Should Happen?

The sandbox should allow me to:

1. Allow all Read|Edit|Write inside the workspace (CWD).
2. Hard-block all filesystem access outside the workspace (CWD).

Error Messages/Logs

Steps to Reproduce

Scenario A — Parent deny kills workspace 1. Create workspace at ~/project. 2. ~/project/.claude/settings.local.json: {"sandbox":{"enabled":true},"permissions":{"allow":["Read(./**)","Edit(./**)","Write(./**)"],"deny":["Read(../**)","Edit(../**)","Write(../**)"],"ask":[]}}

3.	~/.claude/settings.local.json:

{"sandbox":{"enabled":true},"permissions":{"deny":["Read(~/**)","Edit(~/**)","Write(~/**)"],"ask":[]}}

4.	Reload. Ask: Read ./README.md → Denied. Deny on ~/** also blocks the workspace.

Scenario B — Without global deny, escapes succeed 1. Keep the workspace file from A(2). 2. ~/.claude/settings.local.json: {"sandbox":{"enabled":true},"permissions":{"ask":["Read(//**)","Edit(//**)","Write(//**)"]}} 3. Reload. Ask: Read ~/.zshrc → Prompted then Allowed. CWD-only cannot be enforced with Ask.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.0.25

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

[tfriedel]

I would also want this. Having to think of all the files and folders that could contain sensitive material is not feasible. Much better to only allow project dir and a select few other ones that are necessary.

[minionOfZuul]

The sandbox feature is insufficient for any serious use without this being resolved.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

[tfriedel]

I am very much still interested in this