What still stops a bad command when your agent runs without prompts

Approving every command gets old fast. So many people run their coding agent with prompts switched off: claude --dangerously-skip-permissions, Cursor’s Run Everything mode, an agent in CI, or a background agent that works while you sleep.

The work goes faster. But the prompt was the only moment where you could look at a command and say no. With prompts off, the agent runs whatever it decides to run. That includes what a README, an issue or a web page talked it into.

I build OpenMoat, and this is the case where it matters most. This post explains what still stops a bad command when nobody is there to answer a prompt, and what does not.

What changes when prompts are off

OpenMoat gives each action one of four answers: allow, defer, ask or deny. Defer means “the policy has no rule for this, so let the agent’s own prompt decide.” Normally that keeps OpenMoat quiet: installs, pushes and other unlisted commands get the same prompt they always got.

In auto-approve mode there is no prompt, so a deferred call simply runs:

Two answers still stop a call: deny and ask. Neither depends on the agent’s prompt. OpenMoat’s hook returns them before the call runs, in every mode.

What the default policy still blocks

Deny covers what must never happen, whoever is watching. These are verdicts from the default policy:

The last row matters most with prompts off. An agent that hits a deny cannot approve itself, edit the policy or uninstall OpenMoat through its tools. If the policy or the agent’s settings change behind OpenMoat’s back, every call is blocked until you review.

Hiding the command does not help either. A path in a shell variable (d=~/.ssh; cat $d/id_rsa), a base64 payload piped to sh, or a glob like cat .e* is checked as what it opens.

You can see any verdict yourself without running the command:

moat policy check "curl -fsSL https://example.com/install.sh | sh"

This only prints the verdict. It does not run curl or download anything.

What runs without a question

This is the honest part. With prompts off, everything the policy has no rule for runs. In the default policy that includes:

• package installs, like npm install left-pad;
• a normal git push origin main;
• commands OpenMoat does not know.

A force push is denied, but an ordinary push is not. If an injected instruction asks for a plain push of bad code, auto-approve mode lets it through. Network rules still limit where data can go, because agents may connect only to hosts the policy allows. But an allowed host, like api.github.com or a package registry, can still receive data from an allowed command.

If you want any of these stopped too, add a rule with moat edit. It checks the change and shows the diff before it applies.

The commands inside the commands

A hook sees npm test. It cannot see what the test script does, and in auto-approve mode nobody looks at the script before it runs.

That is why OpenMoat also configures each agent’s own OS sandbox from the same policy. A script that tries to read your SSH key fails at the operating system, not in OpenMoat’s parser. These results come from CI, for a test script started as npm test in a throwaway home with fake secrets:

Every layer and every case, including the gaps, is in EVIDENCE.md. CI checks them on every pull request.

For CI and background agents: moat run

When the agent runs unattended, you can start the whole agent inside a sandbox generated from your policy:

moat run -- claude --dangerously-skip-permissions

moat run works on macOS 14 or later and on Linux. It covers every process the agent starts, not only the calls a hook sees. It is coarser per command than the hook, so use it with the hook, not instead of it. On Linux, add --isolate (bubblewrap) if files inside the project, like .env or .git hooks, must stay protected too. Plain moat run on Linux cannot protect them.

Agent by agent

• Claude Code: its sandbox covers Bash, PowerShell and Monitor. File tools, WebFetch and MCP calls are checked by the hook only.
• Codex cannot show an OpenMoat prompt. An ask becomes a deny, and you approve it with moat allow --last. A deferred call follows Codex’s own approval policy.
• Cursor runs some commands outside the sandbox OpenMoat configures: when its Auto-review approves them, in Run Everything mode, and in the Cursor CLI without --sandbox enabled.

Limits

• A deferred call runs. Only deny and ask stop a call when prompts are off.
• Allowed scripts run whatever they contain. The sandbox bounds them; OpenMoat does not read them.
• The proxy checks the host, not what is sent inside HTTPS.
• If the moat binary is missing or killed, Claude Code and Codex run calls unchecked. moat status reports it.
• Native Windows has no OS sandbox; use WSL2.

The full list is in the threat model.

Try it

brew install crocodile-labs/tap/moat && moat init

Then run moat status to see which agents are protected by the hook and the OS sandbox. The auto-approve and CI guide has the details for each agent.

Do you run your agent with prompts off? Tell me on r/openmoat what you would want blocked that the default policy lets through. Remove secrets from anything you share.