How to Stop Grok From Running Dangerous Commands

rm -rf doesn't care which model proposed it. What stops a destructive command from actually running is whichever layer sits between the model's output and your shell — and for Grok, that layer's existence depends entirely on how you're running it. xAI's own CLI, Grok Build, has a real permission and sandbox system. Grok the model, plugged into Cline, Roo Code, or a hand-rolled agent loop via the xAI API, has none of its own — it's a text generator behind an HTTP endpoint, and the harness is doing all the deciding.

This guide covers both paths: what Grok Build's documented safety controls actually do, why they don't travel with the model into other harnesses, and what to lock down either way.

TL;DR

The two ways developers actually run Grok

1. Grok Build — xAI's own terminal agent

Grok Build is xAI's terminal-native coding CLI: it reads a codebase, edits files, runs shell commands, and can spawn up to eight parallel subagents in isolated git worktrees, per x.ai's launch announcement. It launched in beta on May 14, 2026 for SuperGrok Heavy subscribers, expanded to all SuperGrok and X Premium+ subscribers on May 25, 2026, and left beta at v1.0 on August 7, 2026 as an Apache 2.0 open-source project defaulting to the Grok 4.6 model.

That timeline matters for a safety-focused post: Grok Build's permission system is newer and has had far less public scrutiny than Claude Code's or Codex CLI's, which were already in wide daily use by the time Grok Build shipped.

2. grok-code-fast-1 (or successors) via API, inside someone else's harness

Most developers who say they're "using Grok to code" are not running Grok Build at all. They're pointing a third-party harness at the xAI API. Cline, Roo Code, and opencode all support custom API endpoints and work with grok-code-fast-1 directly; xAI has also run promotions with GitHub Copilot, Cursor, Kilo Code, and Windsurf offering the model for free through their own agent loops, per xAI's grok-code-fast-1 announcement.

In this setup, Grok is exactly as safe as the harness around it — and no safer. The model returns a proposed shell command as text; whether that command gets a confirmation prompt, a sandbox, or a denylist check depends entirely on Cline's settings, Roo Code's auto-approve toggles, or however the custom agent loop was written. Grok itself has no opinion and no built-in gate. This is the single most important framing point in this post: don't assume Grok-specific safety features exist just because you're using a Grok model — verify what your specific harness does, because the model isn't the layer doing the deciding.

For a deeper look at how harnesses in general structure this decision, see what are agent harnesses.

Locking down Grok Build's own permission system

Grok Build's permission and sandbox layers are separate and stack, per xAI's permissions-and-safety docs and settings docs.

Run modes

• Auto mode — a classifier auto-approves tool calls it judges safe; commands it judges dangerous still prompt for confirmation.
• Always-approve — skips the normal confirmation prompt entirely for tool calls. Deny rules, ask rules, and hooks still apply underneath it — it removes friction, not the underlying guardrails.
• Plan mode — recommended for risky work. Grok drafts a structured plan; you approve, comment on individual steps, or rewrite it before any execution starts. Plan mode blocks write tools other than the session plan file until you're ready.

Allow/deny rules

Rules live in .grok/config.toml (and can be set with --allow/--deny flags):

[permission]
allow = [
  "Bash(git *)",
  "Bash(npm test*)",
  "Read(src/**)",
]
deny = [
  "Bash(rm -rf *)",
  "Read(**/.env)",
  "Edit(**/.env)",
]

Deny rules take precedence over allow and ask rules regardless of which config file they're defined in. An "ask" rule forces a prompt even for a command that would otherwise auto-approve — useful for narrowing Auto mode's classifier judgment on a specific pattern you don't trust it with.

PreToolUse hooks

Hooks are checked before permission rules — a hook can deny a tool call outright, before Grok Build even evaluates its allow/deny list. Hooks load from ~/.grok/hooks/*.json (always trusted) and project-level .grok/hooks/*.json (only behind folder trust), which is the mechanism to plug in your own scripted validation of proposed shell commands.

Sandbox profiles

xAI explicitly separates permissions (what the model may request) from the sandbox (what an approved process can actually reach). Five profiles — off (default), workspace, devbox, read-only, strict — are enforced by Landlock on Linux and Seatbelt on macOS, with custom sandbox.toml profiles and per-path deny globs for finer control. Even a command that clears permission checks is still constrained by whichever sandbox profile is active.

The honest caveat: this system has already been tested and found leaky

Within a day of Grok Build's open-source release, security researchers at SlowMist reported two zero-day exploit chains — arbitrary code execution via a cargo check command misclassification, and a bypassPermissions full-permission bypass — the latter triggered because Grok Build automatically traverses and injects an untrusted AGENTS.md file into the system prompt without validating its origin, per SlowMist's writeup. xAI's HackerOne response reportedly marked the client-side report "out of scope." A documented permission model is not the same claim as a hardened one — treat Grok Build's deny rules and sandbox as a real but young control, not a guarantee.

Locking down Grok when the harness is the real gatekeeper

If you're calling grok-code-fast-1 through Cline, Roo Code, opencode, or a custom agent loop, the mitigations below apply regardless of which model is behind the API — this is the same advice that applies to any model plugged into a third-party harness. See how to stop Claude Code from running dangerous commands and how to stop Codex from running dangerous commands for the same pattern with other models.

Run inside a sandboxed environment

Give the harness a container or VM instead of your real filesystem and network. If a destructive command does execute, it only touches a disposable environment. This is the single highest-leverage mitigation because it doesn't depend on the harness's own approval logic being correct.

Set command allowlists/denylists at the harness level

Most harnesses that support custom API models (Cline, Roo Code) have their own auto-approve settings and command pattern lists, independent of anything Grok provides. Configure denylists for rm -rf, force pushes (git push --force), curl | sh / curl | bash patterns, and database-drop statements at the harness layer — since Grok won't refuse them for you.

Require human-in-the-loop approval for shell execution

Turn off blanket auto-approve for shell/terminal tools specifically, even if file edits are auto-approved. A command that deletes, force-pushes, or exfiltrates is a different risk class from a command that edits a file, and most harnesses let you split approval policy by tool type.

Restrict filesystem and network scope

Scope the agent's working directory narrowly and, where the harness supports it, restrict outbound network access so a compromised or misled agent can't exfiltrate credentials even if a command does run.

Where Beam fits

Beam is a local-first observability and heuristic-scanning tool for AI coding agent activity — it watches, it doesn't block. Per apps/sentinel-collector/README.md, "Sentinel v1 does not implement blocking," and that's true regardless of which model or harness generated the command.

What's documented today:

• A direct hook, but only for Claude Code. The collector accepts a Claude PreToolUse/PostToolUse JSON payload on stdin via bun .../cli.ts hook claude-code. There is no equivalent Grok Build or Grok-harness-specific hook documented in the README.
• A general ingest path for any normalized event. POST /ingest accepts normalized JSON/NDJSON (up to 2 MB / 2,000 records) with fields like source_agent, tool_name, command, and session_id — so a Grok Build session or a Cline/Roo Code session driving Grok could, in principle, be wired in by forwarding its own tool-call events, but this isn't a shipped integration; it's a documented API surface you'd need to connect yourself.
• Numbat coverage for agents other than Claude Code. The README points to Numbat for other agents: "For another agent, follow the matching upstream coverage/deployment instructions." Whether Numbat has Grok Build coverage is a question for Numbat's own docs, not something Beam adds on top.
• Skill and MCP scanning, model-agnostic by design. bun run --cwd apps/sentinel-collector cli scan /path/to/SKILL.md runs 11 heuristic patterns plus an MCP version-pin check against credential delivery, deletion, downloaded/encoded execution, reverse shells, and instruction-override patterns. This doesn't care which model is driving the agent that would run the skill — it inspects the skill file's text before anything executes.
• Local storage, redaction before persistence. Data lands under apps/sentinel-collector/.data (directory mode 0700, files 0600). Known credential formats, auth headers, and URL query params are redacted before persistence; detection runs on the raw text first.

The honest summary: Beam's value for a Grok-driven setup today is harness-level and OS-level — inspect skills/MCP configs before you run them, forward whatever tool-call events your harness will emit, and rely on the sandbox/denylist mitigations above for the command itself. There's no Grok-specific integration to claim, and claiming one wouldn't be accurate as of this writing.

Limitations, stated plainly

• Beam does not block anything in v1 — it flags and records, it doesn't intercept.
• The skill/MCP scanner is heuristic pattern matching (11 patterns + an MCP version-pin check), not semantic malware analysis — it catches known shapes, not novel ones.
• No documented Grok Build or grok-code-fast-1-specific hook exists in apps/sentinel-collector/README.md as of this writing; any Grok coverage today would be self-wired through /ingest, OTLP /v1/logs, or Numbat's own upstream support.
• Pairing is single-user and local — not fleet management, not SSO, not enforcement, per the README's own "future work" list.
• Grok Build's permission/sandbox system is real but young: it shipped in 2026 and had a reported exploit chain within a day of going open source. Treat its deny rules as a control worth configuring, not a guarantee against prompt-injection-driven bypass.

Summary

Whether Grok can run a dangerous command comes down to which of two situations you're in. Inside Grok Build, xAI ships a real permission model — Auto/Always-approve/Plan modes, .grok/config.toml deny rules, PreToolUse hooks, and sandbox profiles — but it's new tooling with at least one publicly reported bypass. Outside Grok Build, when grok-code-fast-1 is just a model behind an API call in Cline, Roo Code, or a custom harness, none of that travels with it — the harness's own sandbox, allowlist, and human-approval settings are the only thing standing between a bad command and your shell. Beam adds a local, model-agnostic layer on top of either case: scan skills and MCP configs before running them, and forward whatever tool-call events your harness produces so there's a local, inspectable record of what actually ran.

Related reading: how to stop Claude Code from running dangerous commands, how to stop Cursor from running dangerous commands, what are agent harnesses, and Cursor vs Claude Code vs Copilot: agent safety compared.

Grok Build's permission model, sandbox profiles, and the SlowMist findings referenced above reflect publicly documented behavior as of this writing (September 2026); xAI's own docs and the Grok Build repository are the source of truth for any changes since. Beam's own capabilities are accurate as of Sentinel collector v0.1 — a local prototype, per apps/sentinel-collector/README.md.