How to block AI coding agents from force pushing or running destructive commands?

Summary

• Block destructive commands in layers. Put policies between the agent and its shell, add an OS sandbox to limit what a command can touch, and turn on branch protection on your Git host as the backstop.
• In Omnigent, the blast_radius policy always denies catastrophic shell commands such as a force push or rm -rf /, and it asks before recoverable risky ones. The github_policy policy denies force-push flags by default.
• An OS sandbox restricts which directories an agent can write and whether it can reach the network. It doesn't understand Git, and MCP servers run outside it.
• On GitHub, protected branches block force pushes unless you turn on Allow force pushes.
• Omnigent is open source (status alpha). On Databricks, Omnigent is in Beta.

How to block AI coding agents from force pushing or running destructive commands?

Use several layers, because a coding agent with shell access can run destructive commands. The most direct control sits between the agent's decision and the shell: a policy that inspects each command before it runs. An OS sandbox then limits what a command can touch, and branch protection on your Git host makes the remote refuse a force push even if everything else fails.

Which controls stop which commands?

Control	What it stops	Limits
Omnigent blast_radius	Force pushes, deleting a remote branch, rm -rf /, a hard reset to a remote ref	Covers shell tools; ordinary pushes get the risky_action verdict instead
Omnigent github_policy	Pushes outside the repos and branches you allow, plus force flags and deletes by default	Covers GitHub MCP tools and git or gh shell commands
OS sandbox	Writes outside write_paths, and network access when you turn it off	Doesn't understand Git; MCP servers run outside it
Git pre-push hook	A push before it starts	git push --no-verify bypasses it
Host branch protection	Force pushes and deletions on protected branches	Protects only the branches you protect

A pre-commit hook doesn't help here. Git invokes it from git commit, not from git push.

How do you block force pushes in Omnigent?

Policies live in the agent YAML, in the server config for every session, or in a single session. Each returns ALLOW, ASK or DENY, and the session level is checked first.

policies:
  git_guard:
    type: function
    handler: omnigent.policies.builtins.github.github_policy
    factory_params:
      write_repos:
        - myorg/my-repo
      write_branches:
        - "feature/*"
  shell_blast_radius:
    type: function
    handler: omnigent.policies.builtins.orchestration.blast_radius
    factory_params:
      risky_action: ASK

github_policy denies --force, -f, --force-with-lease, --force-if-includes, bundled short flags that contain f (such as -uf) and +refspec prefixes by default, even on allowed repos, until you set deny_force_push to false. Deletes are denied until you set allow_destructive. blast_radius always denies catastrophic commands. For recoverable ones, such as an ordinary git push, it returns risky_action (ASK by default, or DENY) while gate_pushes is true, which is the default. Its docs list coverage for the shell tool in Omnigent, Claude Code and Codex (Bash), Cursor, Pi and Hermes.

How do you limit what an agent can touch?

os_env:
  type: caller_process
  cwd: .
  sandbox:
    write_paths: [./src, ./tests]
    allow_network: false

On hardened backends the working directory is read-only until you opt writes in. Linux uses bubblewrap and macOS uses Seatbelt. With allow_network: false, sandboxed commands have no network access, so a git push over the network can't succeed. If the agent must push, keep the network on and use egress_rules, an HTTP(S) allow-list that is default-deny once set. The sandbox covers the sys_os_* tools and terminals, not MCP servers or the supervisor process, so pair it with policies.

What about review agents and unattended runs?

For an agent that only reviews, the read_only_os policy denies every file-mutating tool, so it can read and run shell but never change code. The Polly example agent delegates work to coding sub-agents in parallel git worktrees and routes each diff to a reviewer from a different vendor than the one that wrote it. You merge.
Scheduled tasks run without anyone at the keyboard, and the docs warn that prompting modes can leave a run waiting for approval. An ASK pauses until someone answers, so for unattended runs set risky_action to DENY and a risky command is refused instead of parked.

How does Databricks approach this?

The open-source project lists "Status: alpha". On Databricks, Omnigent is in Beta. The Databricks docs say the managed service supports the built-in contextual policies and custom policies written in CEL, and not custom Python policies. A Databricks Sandbox host routes model access through Unity Gateway.

FAQs

Can I block git push --force without blocking every push?

Yes. github_policy denies force flags but allows pushes to the repos and branches you list. blast_radius asks before ordinary pushes, and setting gate_pushes to false skips that prompt while still denying catastrophic commands.

What if an agent has a legitimate reason to force push?

Set deny_force_push to false on github_policy and keep the repo and branch allowlists tight. blast_radius never relaxes its denial of catastrophic commands, so leave it off that agent or run the push yourself.

What does the agent see when a policy denies a command?

A DENY blocks the action and the agent receives an error. blast_radius includes your deny_reason text.

Do git hooks stop a force push?

A pre-push hook can abort a push when it exits non-zero, but --no-verify skips it. Branch protection on the host is the stronger backstop.