confine native shell commands to the project

/sandbox on runs native-loop spawned shell commands and lifecycle hooks inside the strongest supported host boundary. It does not skip permission prompts, does not wrap structured file tools (read_file, edit_file, …), and does not wrap a delegated subscription CLI.

• /sandbox — report the backend and whether it is on.
• /sandbox on · /sandbox off
• /sandbox read-only — the project is mounted read-only inside the sandbox and every file edit is denied (for review runs). --sandbox on|off|read-only sets it for one dgc launch.
• /sandbox network on — allow network from sandboxed commands. Off by default.

• Linux — bubblewrap (bwrap). The project is the only persistent writable host path for those commands. Ambient user state is masked. Home, temporary, runtime, process, and network namespaces are private.
• macOS — sandbox-exec. Ambient-home reads outside the project are denied; host writes except the project and shared system temporary paths are denied. Temporary and process namespaces are not private.
• Anything else — fail closed. DGC will not pretend a requested sandbox is on.

sandbox_env_allow in config.json is the list of extra environment variable names to pass through. Other non-baseline host variables are withheld; DGC still supplies a small safe baseline plus sandbox-specific home, temporary, and runtime paths.

The Python code-action is not covered by /sandbox. MCP server processes start unsandboxed in the workspace — treat a configured server command as a trusted executable.