Title: Feature: Introduce Integrated Runtime Sandboxing for Tool Execution

Labels: enhancement, feature-request, security

Is your feature request related to a problem? Please describe.

Currently, the primary recommendation for running Claude Code in an isolated environment is using devcontainers. While this is excellent for creating consistent development environments, it is not a true runtime sandbox for tool execution.

This poses a security risk, especially when using powerful tools with side effects, such as the Bash tool. Every command executed by the agent runs with the same permissions as the user, creating a potential vector for accidental filesystem damage or the execution of malicious commands resulting from prompt injection. The burden of ensuring safety falls entirely on the user to manually vet every single operation, which is not scalable or foolproof.

Describe the solution you'd like

We propose implementing an integrated, lightweight, and configurable runtime sandboxing feature directly within the Claude Code CLI. This feature would isolate the execution environment of tools, preventing them from affecting the host system outside of a clearly defined scope.

The implementation should be inspired by the robust sandboxing model used in Google's Gemini CLI and should include:

• Container-based Sandboxing: Support for Docker and Podman, allowing tool execution to occur inside a minimal, isolated container. The project's working directory would be mounted into the container to provide context.
• macOS Native Sandboxing: On macOS, the CLI should leverage the built-in sandbox-exec (Seatbelt) framework to provide a low-overhead sandboxing option with configurable profiles.
• Easy Configuration: Users and administrators should be able to enable, disable, and configure the sandbox via settings.json files and command-line flags (e.g., --sandbox).

Rationale and Value Proposition

An integrated sandbox provides a critical layer of security by default, making the tool safer for everyone.

• Prevents Accidental Damage: Isolates file system modifications and command execution to prevent accidental deletion or modification of files outside the project workspace.
• Contains Side Effects: Ensures that shell commands and their subprocesses are contained and cannot interfere with other parts of the user's system.
• Mitigates Prompt Injection: Reduces the potential impact of a successful prompt injection attack by limiting the scope of what a malicious command can achieve.
• Enterprise-Ready: A strong security posture is essential for enterprise adoption. This feature would make Claude Code a much more viable and secure tool for teams.

Prior Art & Implementation Guidance

Google's Gemini CLI provides an excellent blueprint for this feature. We should look to their implementation for inspiration:

• Core Logic: The main sandboxing logic can be found in packages/cli/src/utils/sandbox.ts.
• macOS Profiles: Example Seatbelt profiles are located in packages/cli/src/utils/sandbox-macos-*.sb.
• Container Definition: The Dockerfile at the root of their repository defines the minimal container environment.

Acceptance Criteria

• Users can enable sandboxing via a command-line flag (e.g., claude --sandbox).
• Sandboxing can be configured as a default in ~/.claude/settings.json and .claude/settings.json.
• On macOS, if Docker/Podman is not available, the CLI attempts to use sandbox-exec.
• On Linux/Windows, the CLI attempts to use Docker or Podman.
• When sandboxing is active, file system and Bash tool operations are executed within the isolated environment.
• The current working directory is correctly mounted and accessible within the sandbox.
• Documentation is updated to explain the new sandboxing feature, its configuration, and security benefits.