Muzzle/Compare/Claude Code and Codex built-in controls

Muzzle vs Claude Code permissions and the Codex sandbox

Claude Code and Codex ship with permission rules and an operating-system sandbox. They control what a command can touch and which hosts it can reach. Muzzle adds a check on what the agent actually sends and reads.

FeatureClaude Code permissions and sandboxCodex sandbox and approvalsMuzzle
What it controlsAllow, ask and deny rules per tool call, plus an optional Seatbelt sandbox for shell commands, off by defaultSandbox modes read-only, workspace-write and danger-full-access, with approval policiesThe content of commands and requests, and what the agent reads
NetworkSandboxed commands reach only a local proxy, which checks the requested hostname against your allowlist. TLS is not inspected by defaultOff by default in workspace-write, enabled with network_access = trueChecks request content for your protected values and secrets
FilesWrites limited to the working directory. Reads are allowed across most of the machine by default, including ~/.ssh, unless you add read rules.git, .codex, .agents and .aws stay read-only inside writable foldersLocks the agent's settings against changes (Free)
Outside its reachBuilt-in tools such as Read and WebFetch, command hooks and local MCP servers run outside the sandboxThe command proxy does not filter web search, MCP connections, browser activity or the client's own model requestsNot a sandbox. It does not confine file access or processes
Pages and files the agent readsNot its jobNot its jobChecked for prompt injection, with alerts (Pro)
Agents coveredClaude CodeCodexClaude Code in Free; Codex in Pro
PriceIncluded with Claude CodeIncluded with CodexFree, or Pro at $19 a month

What the built-in controls do well

Both sandboxes are enforced by the operating system, so a command stays inside its limits whatever the model decided to run. Claude Code's permission rules decide whether each tool call runs at all, and managed settings let an organisation enforce them.

What they leave to something else

A hostname allowlist cannot tell a harmless request to an allowed host from one that carries your API key. Claude Code's documentation notes that its Read tool and WebFetch run outside the sandbox, and that deny rules on shell commands match the command text and are not a security boundary.

Muzzle checks what the agent sends, in its tool calls and in the commands it runs, and blocks anything carrying a protected email, phone number, name, key or token. It keeps one list of protected values for both agents.

Using both

Turn on the sandbox and keep your permission rules tight. Add Muzzle for the part they do not look at: what is inside the requests that your allowlist lets through, and what the agent reads from the web.

Which to use

Use the built-in controls if

  • You want operating-system limits on files and network
  • You want per-tool approval rules your team can check in
  • You manage settings centrally across an organisation
  • You use only one agent

Add Muzzle if

  • You run both Claude Code and Codex
  • You want a key or address blocked even when the host is allowed
  • You want alerts on injected instructions in pages and files
  • You want one protected-values list and a git commit check

Questions

Is the Claude Code sandbox on by default?

No. It is off by default and is turned on with /sandbox or a setting.

Does the Codex sandbox allow network access?

Not by default. In workspace-write mode network access is off until you enable it in configuration.

Does Muzzle replace the sandbox?

No. The sandbox limits what a command can touch. Muzzle checks what the agent sends and reads. They cover different things.

Muzzle Free costs $0 and covers Claude Code hooks, git commit checks, project scans and the settings lock. Pro is $19 a month or $96 a year and adds Codex checks, injection alerts, and checks on the requests your agents' scripts make and the instruction files they load. Apple silicon, macOS 12 or later.

Download Muzzle