[FEATURE] Sandbox should isolate all tool execution, not just Bash

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's sandbox (documented at https://code.claude.com/docs/en/sandboxing) enforces filesystem and network restrictions only on the Bash tool and its child processes. The official documentation states:

"Sandboxing provides OS-level enforcement that restricts what Bash commands can access at the filesystem and network level. It applies only to Bash commands and their child processes."

This means Read, Write, Edit, Glob, and Grep tools execute in the same process as Claude Code itself, with full access to the host environment. As a result:

1. Credentials in environment variables are exposed: Claude Code's own credentials (e.g., ANTHROPIC_API_KEY, CLAUDE_CODE_OAUTH_TOKEN) and any other environment variables present in the parent process are readable via the Bash tool. The sandbox does not filter environment variables passed to child processes.

1. Claude Code can modify itself: Since non-Bash tools operate outside the sandbox, Claude Code can read and edit its own configuration files (e.g., CLAUDE.md, settings.json) using the Edit tool, regardless of sandbox settings.

1. No structural separation between execution and workspace: Frameworks like OpenClaw separate the agent runtime (which holds credentials and makes decisions) from the sandbox (where tool execution happens) using process-level isolation. Claude Code runs everything in a single process, so there is no boundary between "where the agent runs" and "where the agent works."

The current sandbox protects against Bash-based attacks (e.g., curl exfiltration, arbitrary command execution), but a prompt injection attack can use Read to access credential files, Edit to modify agent configuration, or Glob/Grep to discover sensitive paths — all without triggering any sandbox restriction.

Proposed Solution

Extend sandbox enforcement to cover all tool execution, not just Bash:

1. Filesystem restrictions for all tools: Apply the same denyRead/denyWrite rules that the Bash sandbox enforces to Read, Write, Edit, Glob, and Grep tools as well, at the OS level.

1. Environment variable filtering: Do not pass the parent process's environment variables to Bash child processes by default. Credentials like API keys should not be visible inside the sandbox. The sandbox runtime could use --clearenv (bubblewrap) or equivalent to start with a clean environment, explicitly passing only non-sensitive variables.

1. Self-modification protection: Prevent Claude Code from modifying its own configuration files (.claude/, CLAUDE.md, settings.json) through any tool, unless explicitly permitted.

Alternative Solutions

• Permissions (deny rules): The current workaround is to use permission deny rules for Read/Edit on sensitive paths. However, permissions are evaluated within the Claude Code process and rely on correct configuration. They are not OS-level enforcement like the Bash sandbox.
• Devcontainer: Running Claude Code inside a container provides OS-level isolation for the entire process. However, this isolates Claude Code from the host rather than isolating tool execution from the agent runtime. Credentials needed by Claude Code (e.g., API keys) are still accessible to all tools within the container.
• Related: #4320 proposed Docker/Podman-based sandboxing for all tools but was auto-closed. #7097 resulted in the current Bash-only sandbox implementation.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I run Claude Code on a development server where multiple credentials exist as environment variables (GitHub tokens, API keys for various services). I have sandbox enabled with network.allowedDomains restricted to necessary domains.

Despite this, a prompt injection embedded in a fetched webpage or a repository file could instruct Claude Code to:

1. Use Bash with printenv to list all environment variables including API keys (sandbox does not filter env vars)
2. Use Read to access ~/.claude/.credentials.json (Read is not subject to sandbox filesystem restrictions)
3. Use Edit to modify CLAUDE.md to alter its own behavior for future sessions (Edit is not subject to sandbox)

Steps 2 and 3 would succeed silently regardless of sandbox configuration, because the sandbox only applies to Bash.

Additional Context

• The sandbox runtime (@anthropic-ai/sandbox-runtime) uses bubblewrap on Linux, which supports --clearenv for environment variable isolation, but this is not currently used
• The official sandboxing documentation acknowledges the Bash-only scope but does not explain why other tools are excluded
• The devcontainer reference implementation (https://code.claude.com/docs/en/devcontainer) addresses a different threat model (isolating Claude Code from the host) rather than isolating tool execution from the agent runtime

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)