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 — turning it on also denies the python tool, which runs outside the sandbox; turning it off takes back only the rules /sandbox itself added.
• /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.

A delegated sub-agent works in a private Git worktree whose .git is a pointer into your repository, so the repository directory is re-exposed read-only inside the sandbox — otherwise the pointer dangles and the child cannot run one git command. It gets .git only, never the repository's working tree: the ignored files its worktree deliberately does not have (.env, node_modules) stay out of reach, and so does your own uncommitted work. A sandboxed sub-agent can therefore read history, run git status and git diff, and cannot commit — which is deliberate, because DGC integrates a sub-task by reading its working tree, never its commits.

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.