September 17 update: Grok Build keeps Markdown memory across sessions
Update, September 17, 2026: xAI has added persistent memory to Grok Build. The system records durable conventions, decisions and project facts after completed turns, then stores them as Markdown topics for a project or as global preferences. The /memory command opens saved material, while /dream organizes it.
| Memory behavior | What xAI says | What to test |
|---|---|---|
| Capture timing | Begins after the first completed turn in a new session | Confirm incomplete work is not saved as a durable rule |
| Scope | Project topics plus global preferences | Check that one project’s conventions do not leak into another |
| Precedence | Current conversation instructions override saved notes | Create a direct conflict and inspect which instruction wins |
| Exclusions | Task state, tentative conclusions, secrets and repository-documented facts should be excluded | Plant a fake secret and an outdated conclusion, then inspect memory |
Persistent memory needs a stale-note and secret-leak test
xAI’s exclusions are design claims, not independent proof that every sensitive or incorrect detail will be filtered. Before enabling the feature on a real repository, save a harmless convention, revise it in the next session, place a fake credential in a task, and confirm that the current instruction wins while the credential never appears in /memory. Review global topics separately because their blast radius is wider than one project.
Read xAI’s persistent memory announcement. The original open-source and coding-agent analysis continues below.
An AI agent that can read, edit, and run your code is powerful, and a little terrifying, because you’re trusting it with the keys to your project. So when xAI open-sourced Grok Build, it wasn’t just a nice gesture. Given what happened right before it, it was close to a necessity. Here’s the full picture.
What actually happened
In mid-July 2026, xAI open-sourced Grok Build (its coding agent) publishing the source on GitHub (at xai-org/grok-build) under the permissive Apache 2.0 license. That means developers can read exactly how it works, extend it, and run their own modified version.
Grok Build itself is a terminal coding agent: a text-based interface that lets you read, edit, search, and run code with Grok’s AI doing the heavy lifting. It runs on Grok 4.5 (xAI’s coding-focused model) and includes niceties like a subagent view, a Plan Mode, mouse support, and a full-screen terminal UI. The open-source release ships the whole thing, the core agent loop, all the code-interaction tools, the interface, and the extension system.
The part the press release underplays
Now here’s the context that makes this more than a feel-good story, and I’d be doing you a disservice to skip it. Shortly before the open-sourcing, security researchers discovered that Grok Build had been uploading portions of users’ code repositories to Google Cloud. In response, xAI said it would delete the previously uploaded data, and the open-source release looks, at least in part, like a move to rebuild trust after that.
I’m not telling you this to dunk on xAI. I’m telling you because it’s exactly the kind of thing you need to know about any tool that touches your code. “It’s from a big lab” is not a security model. What happened here is a reminder that even well-resourced tools can quietly do things you didn’t sign up for.
Why open source is the right answer to that
This is precisely where open-sourcing earns its keep. For a tool that has access to your files, the ability to verify what it actually does (not what the marketing claims) is the whole ballgame. With the code public, the community can audit exactly what gets sent where, catch the next problem faster, and you can run a version you’ve inspected yourself.
Transparency doesn’t guarantee safety, but opacity almost guarantees you’ll find out about problems last. Open beats “trust us” for anything reaching into your work.
What this means for you
So how should you actually treat this? A few practical takeaways.
- If you code: a capable, open, local-first agent running on a strong model is genuinely worth trying, and you can vet it before you run it.
- If you’re not technical: the lesson still applies. Prefer tools that are transparent about what they do with your data, and be wary of any agent that wants broad access without a clear explanation.
- Either way: start on a non-sensitive project, watch what it does, and keep secrets out of it until you trust it.
Coding agents did just get more interesting, not only because Grok Build is open, but because this whole episode shows why “open” is becoming a real requirement, not a bonus, for tools we hand our work to.
How to check what a code tool actually sends
The Grok Build episode is a reminder to verify, not trust, any tool that touches your code. If you’re technical, watch its network activity or read the now-open source to see exactly what leaves your machine. If you’re not, apply the non-coder version: prefer tools that are transparent about data handling, never point one at a private repo with secrets until you understand its policy, and keep credentials in environment variables the tool can’t quietly upload. Open source doesn’t guarantee safety, but it means someone can catch the next problem, and so can you.
Does open-sourcing a tool make you more likely to trust it with your code, or does the privacy scare stick with you? Tell me where you land in the comments.
Verification sources and related guides
Primary reference: SpaceXAI announcement that Grok Build is open source. This is an official provider source. Treat performance, adoption, and product claims as company-reported unless the article identifies an independent check.
