Adding memory to Grok Build

it runs Claude-shaped hooks, and drops what most of them print

Grok Build writes every session to disk and starts the next one without them. The work that would answer today's question is in those files, and in whatever other agent you used before it.

What Grok already has

Sessions live under ~/.grok/sessions as ACP update streams — JSONL with JSON metadata beside them — with GROK_HOME moving the tree. Complete, and unread by anything. The grok.db beside them is grok-dev's, a different CLI; deja reads that too.

Adding recall

deja install grok-auto

Writes [mcp_servers.deja] into ~/.grok/config.toml and a hook file of deja's own into ~/.grok/hooks/. Grok runs hooks in the same shape Claude Code uses, but on Grok Build 1.0.5 what session start, the prompt and both tool events print is discarded — measured by reading the request the model was sent. The one reply Grok applies is a PreToolUse updatedInput, and deja uses it to put memory into a spawned agent's prompt. The other hooks are there for their side effects, warming the index and forgetting what a compaction threw away, so in the main thread recall arrives when the model calls the deja tool. PreCompact also reads the session from the updates.jsonl it names, and the next PreToolUse hands back the task, the commands with whether they passed, and what was still open. Grok Build 1.0.41 still drops what session start and the prompt print, so deja sends nothing there and does not count it as memory that arrived.

A plugin for the official marketplace is in review. When it lands, grok plugin install deja is the other path, and the two coexist: each half of the plugin stands down when it finds what the CLI already wired, so nothing is listed or injected twice.

An installed plugin does not follow releases on its own — a marketplace entry can pin a commit — so deja doctor reports the copy it finds and says when this deja ships a newer one, with the command that moves it: grok plugin update deja. A copy at or above the shipped version just reports its number, because a working copy installed from a path is allowed to be ahead.

Either way it needs the binary, since a plugin delivers files rather than runtimes:

brew install deja-vu
# or
curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh

One thing to know about the name

There is a community CLI that shares the name grok and the ~/.grok directory, and it is a different product. deja reads xAI's Grok Build store, and deja resume prints a grok --resume for its sessions and refuses for the community CLI's, which has no terminal resume. Where something still could not be checked against a running Grok Build, the registry page says so and names what was tried instead of guessing.

The part that is not about this harness

The index covers every agent's transcripts on the machine — forty-one of them today, each in its own format — so a fix found in one tool answers a question asked in another, including sessions from before any of this was installed. That is the reason to index rather than to capture.

Nothing here writes memories, so there is nothing to hallucinate into your history; indexing and search are local, and credentials are stripped as the index is built (privacy). An injection is capped at 1,536 bytes per prompt and about 4 KB per tool call — what memory costs has the measured comparison.

Getting started · How Grok's store is read · The plugin source

Found this useful? Star deja-vu on GitHub.