Grok Build review, rollback, and safety rails

Review what Grok Build (xAI’s coding agent, which edits files in a folder on your computer) did before you trust the same prompt again. Start with the setting where you approve each step, keep secrets out of the folder it works in, and treat git, the tool that records every version of your files, as your undo button. A secrets file that git was told to ignore has no undo, so if the agent deletes it, it is gone.

Imagine you set Grok Build to run on its own every night with the instruction “remove unused files.” One morning you find it deleted a settings file that held real passwords. Because you had told git to ignore that file, git has no copy to restore. Nobody approved the delete, because a run with no person watching never stops to ask.

Permission labels change. Re-check the Build overview the week you set grok to run automatically on a shared computer. In May 2026 the launch audience was SuperGrok and X Premium Plus subscribers, but a paid seat does not give you permission to let an unattended agent near real passwords.

Autonomy levels

Think about how much freedom the agent has in four steps, instead of memorizing the vendor’s labels. The terminal screen uses names like ask, auto, and always-approve, Shift+Tab cycles through them, and you can start in a looser mode with a flag. The labels differ from tool to tool, but the question is always the same: who says yes before a command runs?

• Watch or ask. You see the command or the file write and you allow it. Use this for any folder you care about.
• Auto. A filter lets routine commands through and may still stop on dangerous ones. It is fine once you trust the project and the prompt is narrow.
• Always-approve. This skips permission prompts, although deny rules and hooks can still block some actions. It is how a midnight disaster happens while you sleep, if you also remove the person.
• Headless grok -p. One prompt with no terminal screen, built for scripts. It is useful after the prompt has survived a watched session, and it is dangerous when the prompt is a vague wish like “clean unused files.”

Plan mode sits beside these four steps. It holds ordinary file edits until you accept a plan, so use it. It will not save you if you then paste the same vague cleanup into a build server with always-approve. Plan mode protects the session you are looking at, and a build server is a different session with nobody watching.

A safe path to automation goes in stages. Watch a task three times in the terminal, then tighten the prompt until git diff (the command that shows what changed) lists one path. Only then consider grok -p with that exact prompt, on a throwaway job, with no secrets on disk. Going from first install straight to a nightly cleanup is how build 4482 earned its number.

How review fits the loop

Open the diff yourself. The summary the agent prints is its own description of the patch, while git status and git diff show the patch itself.

git status
git diff
git diff --stat

Stop if you see any of the following, even when the main change looks right.

An earlier post described a 14-file date fix and another described a six-tab workbook, and both fail this table. So does a “cleanup” that removes ignored secrets. The warning sign is that the change reached farther than you asked, no matter how polite the agent sounded.

Rollback is git

Grok Build can rewind a conversation in the terminal, which is handy for clutter. It is not a backup of your disk. Files the agent deleted, especially files git was told to ignore, do not come back with a rewind. Git is the undo for tracked files, and your password vault is the undo for .env.staging.

Before a session that might edit more than one file, save a restore point:

git status
git add -A
git commit -m "pre-agent restore point"

If you cannot commit because you have unfinished work you do not want in history, stash it or make a branch instead. The point is a named place you can return to. After the agent runs, look at what changed and undo what you do not want:

git status
git diff --stat
git restore exports/csv_writer.py
git restore .

git restore path throws away uncommitted edits on that one path, and git restore . throws them away across the whole folder. Use the narrow form first and keep the wide form for “this session is junk.” Neither form restores a file that git never tracked, which is why .env.staging died. git status never listed it as a tracked change, and the file simply vanished from disk.

If you already committed a bad agent patch, use these two commands:

git log --oneline -5
git revert HEAD

Revert if the commit already left your laptop, because it adds a new commit that cancels the bad one. Reset only if you know the commit is local and you are allowed to rewrite history. Do not reset a shared branch because an agent made a mess, since revert is the choice that is safe for teammates.

Worktrees, which are extra copies of the project folder that share one history (an earlier post covered them), help isolate an experiment. They do not replace the restore point on the branch you will merge. If a subagent commits inside a worktree, review that commit like any other pull request, meaning a proposed change that a person reads before it merges. Running in parallel does not mean pre-approved.

Secrets and production

Two rules, both dull, and both broken in build 4482.

First, do not start grok in a directory that holds production copies, live credentials, or customer exports. An earlier post used a 2.1 GB Desktop folder as the bad example, and a build server’s home directory is the same trap with a nicer name. If the server checks out the repo and also writes a dotenv file (a plain file of passwords and settings) onto disk, the agent can see it. When the prompt says “unused,” that file looks unused, because the app you are checking never imports it. It is still the only copy of six values.

Second, do not put cleanup language in headless prompts. Phrases like “remove unused files,” “tidy the workspace,” “delete leftovers,” and “reset the folder” are all delete orders in disguise. Name the path and name the pattern of files. If you cannot name them, you are not ready for grok -p.

If you must automate later, use a safer shape:

# Not a cleanup. A named, read-mostly job.
grok -p "List test files under tests/ that do not import any module. Do not delete. Write the list to /tmp/orphan-tests.txt and stop."

Even that job should run without env files on disk. Pass secrets as settings the build server holds, in a form the tool cannot rewrite, or do not pass them to the agent job at all. Rotate anything the agent may have printed. If .env.staging was deleted, assume it was also read, and change the six values after you restore them.

Production deploys are out of scope for your first month with Build. Do not let the agent push code, apply infrastructure changes, or migrate a database because the terminal offered a command and you were in always-approve. Type those commands yourself, after review, on the path your company already uses.

Loops, retries, and long sessions

Agents retry. A test fails, the agent edits, the test fails a different way, and it edits again. A headless run with a vague goal is a loop that runs up a cloud bill, and you will notice only when the server hits its time limit or when git log shows twelve “fix tests” commits in nine minutes.

Give every automated prompt a stop line, such as “If tests fail twice, write the failure to agent-fail.txt and stop,” “Do not retry more than once,” and “Do not commit.” If the product adds a /loop or scheduled-task feature, treat it like any build job. Give it a named prompt, a named folder, and no secrets, and have a person read the first three runs.

Long sessions are a quieter kind of loop. A session that started as “explain this file” picks up a workbook, then a plugin, then a browser. The /compact command and a fresh /new session are cheaper than letting the agent “finish” a four-hour thread. When the job changes, start a new session. An earlier post said this for chat, and Build needs it more, because leftover goals still have a shell that can run commands.

Write the rules down

Write the rails down so the next person does not invent build 4483. Put them in AGENTS.md (the file the agent reads before it starts) and in the team wiki, and keep them short enough to read.

# AGENTS.md (safety stub)

## Autonomy
- Default to watch/ask in the TUI.
- No always-approve on repos that contain env files or customer data.
- No `grok -p` until the same prompt produced a one-path diff in a watched session.

## Secrets
- Do not read, print, or delete `.env*` or key files.
- If a secret might have been read, say so and stop.

## Git
- Do not commit, push, or open PRs unless I ask.
- Leave a restore point before multi-file work.

## CI
- Forbidden prompts: clean, tidy, remove unused, reset workspace.
- Allowed automated jobs must name paths and forbid deletes.

Add grok inspect to onboarding. If a laptop already has nine MCP servers (extra tools the agent can call, which an earlier post covered), inspect will list them before the first ticket. Pair that with the sandbox rule from the earlier post about picking a safe folder. New hires should run their first session in a toy folder, not in the staging checkout that happens to sit on the Desktop.

Feedback to xAI belongs in the terminal (/feedback, as the launch post describes). Feedback to your team belongs in the incident note for build 4482. That note should record the prompt text, the autonomy level, what file died, whether it was tracked, and who restored the secrets. A note like that will teach more than a slogan about “responsible AI.”

Common mistakes

Practice this week

In a practice folder, make a tracked README (a plain text file that describes the project) and an untracked .env.toy with fake values. Commit the README, then run a watched session with a sloppy prompt on purpose: “clean unused files.” See what the agent reaches for, and deny it. Then run the named prompt that only lists orphans, and restore anything that slipped. If you already have a build server idea, write the prompt on paper and put three forbids in it before anyone pastes it into a config file.

The next post in this series is about Imagine, which turns text into images, then covers edits, video, and rights. Build is the folder agent and Imagine is the studio, so do not generate a “professional cover” for the vendor deck until you have read it. The full list is in the Grok series, and the first Imagine title is Grok Imagine: text to image from zero.

Takeaways

• Watch first, and promote a prompt to grok -p only after it produces a one-path diff.
• Read git status and git diff, because extra files are a reason to stop and not a style note.
• Rollback for tracked files is git, and rollback for .env is the password vault.
• Never run a headless cleanup in a folder that can see secrets or production copies.
• Stop loops after two failures, and write the rules in AGENTS.md.

Series notes

This is Part 20 of the Grok series. Previous: Build for sheets and research. Next: Imagine from zero.

Sources

Research and further reading used for this article:

• xAI docs: Grok Build overview (TUI, headless grok -p, config, inspect)
• xAI: Introducing Grok Build (plan/review/approve, subagents, /feedback, May 2026 eligibility)
• xAI: Grok Build (install and product home)
• xAI docs: Grok 4.6 (the model behind Build; re-check the page for the current one)
• xAI Console (API keys; separate from chat subscription money)
• xAI: Grok FAQ (plan questions to re-check)
• Analytics Made Simple: Learn (related paths on this site)

Merch on Etsy

Open store →

Standard Deviation White Ceramic Mug View on Etsy → Naive Bayes Coffee Mug View on Etsy → Git Version Control Shirt View on Etsy → Mean Squared Error Shirt View on Etsy →