Harness sandboxes
Configure the harness's restrictions when agents run directly under your account.
On this page
A harness sandbox limits particular tools while the Companion runs under your account. It is level 2 in Agent access.
These settings apply to your own sessions as well as Cabane's agents using that account and configuration. Use a separate environment when the two need different access.
What a sandbox does and doesn't cover
Claude Code's sandbox wraps shell commands. Codex applies its configured filesystem policy to commands and file edits. Neither encloses the whole Companion and every hook or MCP server it can start. By default, broad file reads remain possible.
Writes restricted; default reads remain broad.
Cabane does not wait for tool approvals. A prompt is not a second line of protection: use restrictions that refuse the action or run the whole environment separately.
Claude Code
In the account running the Companion, merge this into ~/.claude/settings.json:
{
"sandbox": {
"enabled": true,
"allowUnsandboxedCommands": false,
"failIfUnavailable": true
}
}
The sandbox supports macOS, Linux and WSL2. On Ubuntu or Debian, install its dependencies:
sudo apt-get update
sudo apt-get install bubblewrap socat
allowUnsandboxedCommands: false prevents a blocked command being retried outside the sandbox. failIfUnavailable: true refuses to start when sandboxing is unavailable. Native Windows is unsupported.
Shell writes are limited to the working directory, temporary space and permitted paths; network access follows the configured hosts. Reads remain broad unless restricted. Excluded commands can run outside the sandbox. File tools, hooks and MCP servers need separate restrictions. See Claude Code sandboxing before adding exceptions.
Codex
Configure Codex for the account that runs the Companion. Open ~/.codex/config.toml, or $CODEX_HOME/config.toml if you use a custom location. Set this at the top level, before any table:
sandbox_mode = "workspace-write"
Cabane honors that top-level setting. If it is absent, Cabane runs Codex with danger-full-access; a setting inside a profile alone does not select that profile for Cabane.
On native Windows, also configure the Windows sandbox in the same config.toml by following OpenAI’s Windows sandbox instructions before relying on the sandbox.
workspace-write limits writes to the working and temporary directories and any additional writable roots you configure, with protected subpaths. General reads remain available. Command networking is off by default. Actions requiring approval fail because Cabane disables approvals.
To deliberately enable command networking, add:
[sandbox_workspace_write]
network_access = true
On Linux, processes left behind by a sandboxed command are stopped when that command ends. This can affect development servers and background builds, including inside a container. See Codex sandbox and approvals.
OpenCode
OpenCode has tool permission rules, including explicit denials. They are not an operating-system sandbox. Cabane approves the permission requests an OpenCode session raises, so an ask rule will not wait for you.
Run the Companion and OpenCode server together in their own environment when they need a boundary around files, commands and other processes.