What happened
xAI added persistent memory to Grok Build, its command-line coding agent. Grok Build is xAI’s tool for writing, editing, and running code by chatting with it in a terminal (a text-only window for typing commands directly to your computer), in the same category as tools like Claude Code or Codex.
The feature carries durable context between sessions, including how tests run, project conventions and reasons behind earlier decisions. It can reduce repeated explanations when that information is not already in the repository.
With memory, Grok Build now writes notes on that context in the background after each turn (one back-and-forth exchange between you and the agent) finishes. According to xAI, it records conventions, decisions, and project facts, while deliberately leaving out details specific to whatever task was underway, half-formed conclusions, secrets, and anything already documented in the repository (the stored folder holding your project’s code and its history). Later sessions read those notes before touching related code.
Why it matters
The notes are stored as plain markdown files, organized by scope. Project-level notes live in topic files, like one for testing and one for code style, scoped to that specific project. A separate global scope holds preferences meant to apply everywhere you use Grok Build.
The feature applies to new sessions: run /new or start a fresh grok. Two commands manage the notes. /memory opens a read-only view of every stored note, grouped by scope, so you can see exactly what Grok Build has written down about your project. /dream reorganizes recent notes into the right topic files, and also runs periodically on its own in the background.
Before using memory for team or client work, check where the notes are saved and who can read them. Review both project-level notes and global preferences.
Who should care
This is most useful if you already use Grok Build for a project that spans more than one sitting, where you’d otherwise repeat the same context every session. If you only use Grok Build for quick, one-off edits, there’s less here for you, since memory mainly pays off across repeated sessions on the same codebase.
It’s also worth a look if you’re evaluating coding agents generally. Persistent, file-based project memory is becoming a common pattern across this category, not something unique to one vendor, and it’s worth understanding how each tool you use handles it.
What builders should do next
Run /memory after a few sessions on a project and read what it captured. Confirm the notes are accurate and contain no sensitive details, despite xAI’s stated exclusions. Use the displayed file path to correct a wrong topic note; current conversation instructions take precedence.
If you want to see whether memory is actually saving you time, compare it directly. Pick a task that uses remembered conventions, like adding a new API endpoint (one specific address your app responds to, such as the one that handles a signup form) that follows an existing pattern in your codebase. Do it once in a session where you manually re-explain your conventions, and once in a session where Grok Build’s memory already has that context from prior sessions.
Compare two things: how many times you had to correct or re-explain something the agent got wrong, and how many turns it took to reach a version you’d actually ship. If the same corrections keep recurring, inspect the relevant note and whether the session read it. A single comparison cannot establish how well memory works across the project.
End of article