Beware: Claude Code Silently Drops Its Sandbox in Nested Project Folders

You configure Claude Code’s sandbox carefully. "enabled": true, "allowUnsandboxedCommands": false, a network allowlist that only permits your own domains. You watch the main session block a command that tries to reach outside. Everything seems locked down.

Then a subagent working inside a nested repository directory runs the same command — fully unsandboxed, with unrestricted network access. Nothing tells you it happened. That is the situation documented in Claude Code issue #83035, reported on August 1, 2026, against Claude Code v2.1.220 on macOS.

This is a sandbox-escape-class failure, and it has a nasty property: it is silent. The main session enforces the sandbox, so you reasonably believe the boundary is holding. The subagent shows you it isn’t. If you keep multiple git repositories under one workspace root — which is the common case for anyone working in several projects at once — you need to read this and check your own setup.

What happened

Claude Code reads sandbox settings from .claude/settings.local.json (or settings.json) at the project root where the session starts. That file can contain a sandbox block like this:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["api.mycompany.com"]
    }
  }
}

That configuration is supposed to mean: run everything inside the sandbox, never let commands escape it, and block outbound network to anywhere but my own domains.

The bug report describes what happens when your workspace contains a nested project directory — for example a workspace/repo/ subfolder that is itself a Claude Code project — and a session or subagent roots itself there. The key chain:

Your workspace root has a .claude/settings.local.json with the sandbox block above.
The nested project — workspace/repo/ — has its own .claude/settings.local.json, which contains only permissions, no sandbox key.
You ask Claude Code to work on a task in the nested project, or spawn a subagent that routes there.
Instead of merging the parent’s sandbox policy with the child’s settings, Claude Code treats the child file as a complete replacement. The sandbox block disappears.

The reporter verified this with an ssh host hostname test against a host in the parent’s allowedDomains blocklist. On the main workspace session it was declined. Inside the nested project it ran, silently, unsandboxed — full network access.

Who is affected

This is not a rare corner case. You are exactly in the affected situation if:

You keep multiple repositories under one parent workspace folder (monorepo workspaces, ~/code with several repos, nested git checkouts).
You let subagents or child tasks work inside a repository within that workspace.
Any of those nested repos has its own .claude/settings.local.json or settings.json without a sandbox block.
You relied on the parent workspace’s sandbox to protect work that actually runs in the nested repo.

The report notes two aggravating realities:

Subagents are the common case, not the edge case. Delegated agents naturally root themselves in the nested repo they are asked to work on. So the least-supervised work — the exact place you want the sandbox strongest — runs with the weakest restrictions.
The failure is silent. The operator sees the main session blocked, reasonably concludes commands cannot escape the sandbox, and has no idea the delegated work ran with full network access.

An attacker who can place a malicious file in a repo, or who controls content the agent reads while working in the nested project, can make the agent run unsandboxed commands, exfiltrate data, or reach internal hosts — all without anything misbehaving in a way you’d notice at the parent level.

How to check if you are affected

Run this from your workspace root to list every Claude Code settings file under it:

find . -name "settings.json" -o -name "settings.local.json"

For each file, check whether it contains a sandbox block:

jq '.sandbox' .claude/settings.local.json

If the output is null for any nested project file, and your workspace root (or an ancestor directory) has a non-null sandbox block, you are exposed.

You can also check what Claude Code sees for the current project with:

claude config list --local 2>/dev/null || claude --settings

Then, if you want to verify the escape deterministically, follow the reporter’s reproduction on a test host you control:

Put a domain you do not want accessed, for example blockme.test, outside your parent workspace’s sandbox allowedDomains list.
In a session rooted at the parent, run ssh block.me — it should be blocked.
Start a session or subagent rooted in a nested repo under that workspace, and run the same command. If it succeeds, your nested project silently discarded the parent’s sandbox.

Do this against a test host; never against a production system.

How to protect yourself

Until Anthropic ships a fix, your sandbox is only as strong as the settings.local.json files at each project root. So:

1. Add an explicit sandbox block to every nested project’s settings file.

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["api.mycompany.com"]
    }
  }
}

That makes the configured sandbox the source of truth again — the nested file can no longer silently drop it.

2. Don’t rely on parent-workspace sandbox to protect nested repos. As long as this issue is open, assume a nested project with a settings file of its own has whatever sandbox its file says — and if it says nothing, assume it has none.

3. Harden subagent delegation. When you spawn a subagent or ask for work on a path under a nested repo, check what settings that repo carries first. Better: keep the shared sandbox settings in a user-level or enterprise policy location, and keep nested project files minimal.

4. Mind the “Yes, and don’t ask again” trap. That default creates permissions-only .claude/settings.local.json files in nested subtrees — exactly the vector documented in #83035 that makes the sandbox vanish. After answering, re-run the checks above.

5. Watch the issue. Follow claude-code/#83035 to find out when Anthropic resolves it, and re-run the checks above after every upgrade.

Is there a fix?

As of this writing (August 8, 2026), no: claude-code #83035 is open, with no fix published and no maintainer response noted in the thread. The related prior issue #20218 closed in January 2026 after the permissions side of the same shadowing mechanism was fixed — but the sandbox side remained unfixed and is now tracked separately.

The fix direction the reporter suggests: nested sandbox configs should inherit-and-merge with the parent, never replace it — or at minimum, a loud warning at session start whenever an ancestor sandbox config is being discarded.

Until then, the explicit per-project workaround above is the practical mitigation.

Bottom line

Claude Code’s sandbox is a strong default, but its per-project configuration model assumes your projects are flat. If you use nested projects in one workspace, a permissions-only settings.local.json in a subdirectory quietly turns off the boundary you thought you’d configured. Subagents — the least supervised work you run — get the weakest protection, and nothing in the UI tells you.

The Unix security rule applies here unchanged: inspect what each project actually inherits before you trust a parent’s sandbox. jq '.sandbox' every settings file, put an explicit sandbox block in every nested project, and verify after each Claude Code upgrade.

Sources: Claude Code issue #83035 (reported 2026-08-01), #20218, #40831, #70711. Terminalblog verified the public reports and reproduction steps at the time of writing.