AI coding tools · Claude Code ·

Claude Code sandbox settings: exit code 126, WSL2 and OOM

You turned on Claude Code’s sandbox, and now every Bash command fails with Exit code 126, or Bash is refused inside a Docker Desktop container, or your sessions grow until the OOM killer steps in. As of October 2026, three open user reports in the Claude Code repo describe these problems. This guide covers what each report says, the workarounds the reporters found, and the sandbox settings the official docs give.

If you want the next step, read Claude Code deleted my files: recover them, then guard against a repeat.

Quick fix

  • Exit code 126 on Linux with zsh: start Claude Code with bash as its shell. The reporter says SHELL=/bin/bash claude made the sandbox work again.
  • Docker Desktop (WSL2) container refuses Bash: the reporter says mounting one empty, read-only Windows folder into the container worked around it. This sidesteps a safety check, so read the caution below first.
  • Memory grows to 6–8 GB: the reporter says moving the project’s sandbox settings file aside stopped it straight away. Start with a short sandbox config and add entries one at a time.

Exit code 126 for every command (zsh on Linux)

In anthropics/claude-code#104912 (opened 24 Oct 2026, still open), a user on Linux whose login shell is zsh reports that with sandbox.enabled: true every sandboxed Bash call fails, with empty output, even for true:

Error: Exit code 126        # stdout and stderr both empty

The reporter traced it to a line in the sandbox’s inner script, exec 3<&- || exit 126, which they say bash tolerates and zsh doesn’t. They report it started between 2.1.291 and 2.1.302 and is still there in 2.1.309, and that SHELL=/bin/bash claude fixes it. As of 25 Oct 2026 the issue has no +1 reactions, no comments and no reply from the Claude Code team.

Claude Code’s environment variable docs describe CLAUDE_CODE_SHELL, which sets “the shell Claude Code uses to run Bash tool commands” and accepts a path to a bash or zsh binary. Setting it to your bash path is designed to do the same job as the reporter’s workaround without changing your login shell:

CLAUDE_CODE_SHELL=/bin/bash claude

We haven’t confirmed that CLAUDE_CODE_SHELL avoids this bug; the reporter tested SHELL=/bin/bash. Keep an eye on the issue and the Claude Code releases for a fix.

No Windows filesystem mount was recognized in Docker Desktop

In anthropics/claude-code#104796 (opened 24 Oct 2026, still open), a user running Claude Code 2.1.309 in an Ubuntu container on Docker Desktop for Windows (WSL2 backend) reports that Claude Code sees the WSL2 kernel, looks for Windows drive mounts to hide, finds none, and refuses every sandboxed Bash call:

A shell tool was granted, but no Windows filesystem mount was recognized in the WSL mount table, so the Windows side could not be put out of the sandboxed shell's reach - the run was refused.

The reporter’s workaround is to start the container with one read-only bind mount of an empty Windows folder, for example -v C:\empty:/mnt/x:ro. They say the same case then ran in the sandbox and passed. This is a workaround for a safety check, not a fix: we haven’t confirmed how it affects what the sandbox can reach, so mount only an empty folder, read-only, and watch the issue for an official answer. The reporter also ran the container “with a seccomp profile that allows unshare, clone, clone3, mount, umount2, pivot_root, setns (Docker’s default blocks them)”. That loosens the container’s own isolation, so we don’t recommend copying it without checking with your security team. As of 25 Oct 2026 the issue has no +1 reactions, no comments and no team reply.

The sandboxing docs also say that if bubblewrap can’t start inside an unprivileged container and fails with an error such as Can't mount proc on /newroot/proc: Operation not permitted, you can set enableWeakerNestedSandbox to true, but only “when the outer container already provides the isolation boundary you need”. The docs warn that this mode “considerably weakens security” and exposes process information to sandboxed commands. That’s a different error from the one above.

Sessions grow to 6–8 GB until OOM

In anthropics/claude-code#104891 (opened 24 Oct 2026, still open), a user on Ubuntu with Claude Code 2.1.308 (Desktop Code tab) and 3–4 sessions in git worktrees of one repo reports that adding a project .claude/settings.json with the sandbox on made every running session grow from about 2 GB to 6–8 GB RSS, until the OOM killer stopped them. Their file had about 35 filesystem.denyRead entries, including globs, plus network.allowedDomains, credentials.envVars and other sandbox keys. Moving the file aside stopped it with no restart. The reporter hasn’t narrowed it to one setting yet. As of 25 Oct 2026 the issue has no +1 reactions, no comments and no team reply.

The same reporter saw a second error in that setup: with denyRead: ["~/projects"] and allowRead for the repo, every command failed with bwrap: Can't create file at <worktree>/.claude/hooks: Read-only file system.

Until there’s a fix, a smaller config is easier to rule in or out. Start with the sandbox on and nothing else, check memory, then add your denyRead and network entries back a few at a time.

A minimal sandbox config to start from

The sandboxing docs give these keys under sandbox in a settings file such as ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}
  • Network allowlist: sandboxed commands have no direct route out, and the allowed domains “start empty”. Add hosts to network.allowedDomains, or approve them when Claude Code prompts. The settings reference says: “Wildcards such as *.example.com match subdomains”. network.deniedDomains blocks a domain even when a broader wildcard would allow it.
  • Writes: commands can write to the working directory and a per-user temp directory. Add other paths with filesystem.allowWrite, such as "~/.npm".
  • Reads: use filesystem.denyRead to hide paths, and filesystem.allowRead to re-open part of a denied region.
  • Tools that can’t run sandboxed: excludedCommands, such as "docker compose *", runs matching commands outside the sandbox with your full access, so keep patterns narrow.
  • Check what’s in force: run /sandbox and open the Config tab to “view the resolved sandbox settings”. It also lists most protected paths under Denied within allowed.

If the sandbox can’t start, the docs say Claude Code runs commands without it by default. Set sandbox.failIfUnavailable to true if you’d rather it stop at startup.

For a broader set of guardrails around what Claude Code can touch, see Claude Code deleted my files.

Sources

As of October 2026 (sources checked 25 Oct 2026):

Claude, Claude Code, Anthropic, Docker, Docker Desktop, Windows, WSL, Microsoft, GitHub, Linux, Ubuntu, bash, zsh, bubblewrap, npm and other names belong to their owners. Names are used only to identify products and compatibility. Stack & Ship is not affiliated with or endorsed by any of them.

Related posts