Grok Build CLI: Sandbox and Permissions

@GrokInsider· Jun 6, 2026

Listen0:00 / 2:34

There are two independent layers that keep Grok safe: permissions control what the model is allowed to request, and the sandbox controls what the process can actually do, enforced by the OS kernel. Stack them and you can run the agent on untrusted code with confidence.

New here? Start with Grok Build CLI: Zero to Hero (Start Here).

The sandbox is a hard boundary

Sandbox mode restricts filesystem and network access using kernel primitives, Landlock on Linux and Seatbelt on macOS. It applies to the entire Grok process at startup and is irreversible at runtime, so the model cannot talk its way out. Three built-in profiles cover most needs.

workspace is the everyday choice: read anything, write only to your project, /tmp, and ~/.grok. read-only is for reviewing code you do not trust. strict is maximum isolation for untrusted third-party code. Sensitive paths like ~/.ssh and ~/.aws are always write-protected regardless of profile, and the overhead is negligible because it is a kernel policy check, not a VM.

Permissions gate every tool call

Permissions decide whether a requested tool runs, is denied, or needs your confirmation. The mode sets the baseline behavior.

For automation, dontAsk is the key: it silently denies anything without an explicit allow rule. Combine it with narrow allow rules so the agent gets exactly the privileges it needs and nothing more.

Rules use a Tool(pattern) syntax. *Bash(git ) is far safer than a blanket Bash allow. Deny rules always beat allow rules, and read-only tools plus a curated list of safe shell commands never prompt at all.

Hooks are the strongest control

For a true allow-list, a PreToolUse hook runs before the permission system and can hard-deny anything. The classic example permits only git and gh commands and rejects everything else, the tightest practical shell policy.

Stack the layers

For untrusted code, the recommended setup is dontAsk plus narrow allow rules or a restrictive hook, plus --sandbox strict, plus careful review of any project hooks before you trust them. Permissions decide what gets requested, the sandbox decides what can happen even if a command slips through.

The safe-bash list is a convenience, not a security boundary. For dangerous environments, rely on the sandbox and explicit rules, not the defaults.

Continue the series

The full series