Claude Code Can Now Work Inside a Safer, More Controlled Sandbox

Anthropic has documented sandbox controls for Claude Code Desktop that restrict the filesystem and network access available to Bash commands run in local coding sessions. An optional strict setting blocks commands that cannot operate within those limits, rather than allowing an unsandboxed retry.

What happened

According to Anthropic’s sandboxed Bash documentation, Claude Code can execute shell commands inside a configured local sandbox. The restrictions can define which directories and network destinations a command may access.

Anthropic describes multiple permission approaches. In a regular-permissions configuration, a command that needs access beyond the sandbox may prompt for permission or run outside the restricted environment when approved. Strict mode changes that behavior: commands that cannot complete within the sandbox are blocked instead of being retried without sandboxing.

The company says strict mode is a computer-wide setting for Claude Code sessions, including terminal sessions, although project-specific settings can override it. Updates to sandbox settings apply to newly started sessions.

Claude Code Desktop runs local sessions on a user’s machine and shares settings with Claude Code, Anthropic says in its desktop guide. The company distinguishes the sandboxed Bash tool from the desktop application’s separate computer-use capabilities.

Source evidence

Anthropic’s Configure the sandboxed Bash tool documentation says the sandbox applies filesystem and network restrictions to Bash commands. It also outlines auto-allow and regular-permissions approaches, alongside strict mode for preventing unsandboxed retries.

In its engineering article, Making Claude Code more secure and autonomous with sandboxing, Anthropic says the runtime enforces configured directory and network boundaries with operating-system controls. The company identifies macOS Seatbelt and Linux bubblewrap as underlying mechanisms on those platforms.

These documents indicate that the feature is intended as an execution boundary around local shell activity, rather than solely a layer of permission prompts. Its effective scope, however, depends on the filesystem and network rules a user configures, as well as the operating system in use.

Why it matters

Coding tools commonly need to inspect project files, install packages, run tests, start local services and call developer utilities. Those actions can bring shell commands into contact with source code, environment variables, credentials and network-connected resources.

Sandboxing can narrow that access to the directories and destinations required for a task. Strict mode is particularly relevant where predictable containment is more important than allowing a workflow to continue after a command reaches a restricted boundary. For example, a command requiring access outside permitted directories or to an unapproved network destination could fail under strict settings instead of receiving broader execution access.

That trade-off may also create friction. Projects with dependencies, development tools or services outside the configured boundaries may require expanded rules or a different permissions configuration to work normally.

What to watch

The practical effect of these controls will depend on how readily users can define appropriate directory and network rules for their projects. It will also depend on the interaction between project-level configuration and computer-wide strict mode.

Users may want to monitor Anthropic’s documentation for additional detail on platform support, default settings and troubleshooting for denied commands. Anthropic’s descriptions of macOS Seatbelt and Linux bubblewrap also suggest that sandbox behavior can differ across operating systems.

For organizations using local coding assistants, the key implementation question is whether the permitted boundaries align with ordinary development work without granting unnecessary access to files, services or network endpoints.