Permissions & Safety
Three safety layers, in plain English: how often Grok asks, allow/deny rules, and the OS sandbox.
Permission mode, allow/deny rules, and the OS sandbox are three different layers. Mix them up and you get either false safety or constant popups. Learn them as a stack.
Three safety layers (memorize this)
Permission mode
How often Grok asks you before tools run (Ask / Auto / Always-approve).
Allow / deny rules
Hard policy: some tools or patterns never run (deny always wins).
Sandbox
Extra OS limits on read/write/network—even after you say yes to a tool.
Always-approve skips most popups, but deny rules still apply, and a sandbox can still block writes outside the project.
Permission modes
| Mode | Plain English | When |
|---|---|---|
| Ask (default) | Often pauses before edits and shell | Learning; untrusted folders |
| Auto | Grok auto-allows safer actions and still asks for riskier ones | When you want fewer prompts but not full auto. If /auto is missing from your menu, stay on Ask |
| Always-approve | Skips ordinary prompts | Trusted machine + project + good git/tests |
| acceptEdits (advanced) | Edits freer; shell may still ask | Heavy local refactors you’ll review in git |
How to change: Shift+Tab cycles Normal → Plan → Always-approve (watch the UI indicator). Also: /always-approve, /auto (only if that feature appears in your menu), Ctrl+O (toggle always-approve), /settings, or launch with grok --always-approve / --yolo (CLI flags—not a /yolo slash command).
Stay on Ask until you finish a ship walkthrough. Never Always-approve on folders with production secrets or untrusted downloads.
Allow / deny rules
Rules are patterns that force allow or deny for tools regardless of mode. Deny wins ties. Configure via settings UI, project .grok/config.toml permission sections, or CLI flags such as:
grok --deny '…' --allow '…'Use deny as a permanent seatbelt for dangerous shell patterns—even when always-approve is on for trusted automation (scripts/CI you control).
Sandbox (separate from permissions)
Off by default. An extra OS safety net that limits what Grok’s process (and child commands) may read, write, or use on the network—even after you approve a tool. On Linux this uses Landlock; on macOS it uses Seatbelt (the OS’s built-in sandbox tech). You usually pick a profile instead of typing those names.
# Sandbox is OFF by default. Profiles (install docs):
grok --sandbox workspace # write CWD + temp + ~/.grok; read everywhere
grok --sandbox read-only # no project writes (only ~/.grok + temp)
grok --sandbox strict # untrusted code; tighter reads + writes
# Also: off (default), devbox (disposable VMs). Network child limits are Linux-focused.
# also: GROK_SANDBOX=workspace or [sandbox] profile in config| Profile | Idea |
|---|---|
| workspace | Read broadly; write mainly CWD + temp + Grok home |
| read-only | Analyze; don’t change project files |
| strict | Least privilege for untrusted trees |
| devbox | Disposable VM style (broader writes) |
Some network limits work differently by operating system. Do not depend on sandbox alone for network safety until you check in-product /docs for your version.
Practice
- In Ask mode, request a harmless file edit and read the permission dialog before accepting.
- Deliberately deny one prompt, then ask Grok to explain what it wanted to run.
- Say out loud which of the three layers you just used (mode, rule, or sandbox).
You can explain: “Always-approve is not invincible—deny and sandbox still matter.”