Set sandbox boundaries
此内容尚不支持你的语言。
A model instruction is not a sandbox. Enforcement belongs to the tool, host process, container, operating system, or remote service that performs the action.
How do I restrict the exposed tool set?
Section titled “How do I restrict the exposed tool set?”Start with --no-tools or an explicit --tools allow-list when a run needs only conversation. Disable Model Context Protocol (MCP) and extensions separately because they can register additional capabilities. Review custom tool and hook code with the same care as any locally executed module.
How do I constrain files and processes?
Section titled “How do I constrain files and processes?”Filesystem-aware tools resolve paths against their configured workspace boundary. The Bash runtime applies its sandbox and output limits before returning a result; large output may spill to an artifact instead of remaining inline. Containers add process and filesystem isolation, but mounted credentials and sockets still cross that boundary.
Where does remote authority differ from local authority?
Section titled “Where does remote authority differ from local authority?”Browser, editor, Office, and remote-service integrations enforce different permission models. Confirm the active host, account, context, namespace, and target immediately before a mutation. A successful read proves connectivity, not authorization for a write.
Sandboxing constrains the local tool implementation; it does not grant remote authority and it cannot retract a side effect already accepted by an external service. Begin with no tools, add the minimum file or process capability, and test an allowed path plus a denied path. Verify denial at the tool boundary and inspect the filesystem or process table for absence of change. Restore the narrower configuration after the test.