Mindwalk: the Creator of Air Now Lets You See Where Your Agent Went
If you’ve been writing Go for more than a few months, you’ve probably run air without a second thought — it’s the live-reload tool that half the Go community uses during development. The person behind it, cosmtrek, just launched something in a completely different lane: a tool to see what your coding agent actually did to your repo.
It’s called Mindwalk, and the pitch is refreshingly narrow. It doesn’t manage your agents, it doesn’t add hooks to your workflow, it doesn’t live in your terminal as a status bar. It reads a session log after the fact and shows you the shape of what happened.
The problem it solves
A session log tells you what the agent did — what tool calls, what files, in what order. It doesn’t tell you how it understood the task. Did it treat the right parts of the repo as relevant? Did it wander around before finding the real problem? Did its footprint match the scope you had in mind, or did it touch three times more surface than it needed to?
Reading a raw JSONL line by line doesn’t answer any of that. You’d have to reconstruct the shape of the session in your head.
The idea: a night map
Mindwalk draws your repository as a dark map and replays the session as light moving across it. Where the agent searched, read, or edited, that part of the map lights up. The rest stays dark. Each file holds its deepest touch state — seen (moss green), read (moon white), edited (warm amber) — so you get at a glance the real shape of where the agent’s attention went, not just a list of paths.
The HUD adds a layer of friction on top: error rate, which files churned repeatedly, edits that happened after the last verify. A timeline marks context compactions, subagent launches, and user turns as click-to-jump points, and a playback deck lets you scrub the session over a grouped histogram — observation stays in cool tones, mutation glows warm, so edit phases jump out at a glance without reading a single line of log.
It’s built exactly for this: a single Go binary that reads session logs from Claude Code and Codex, all local — no session data leaves your machine.
Getting it running
curl -fsSL https://raw.githubusercontent.com/cosmtrek/mindwalk/master/scripts/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
mindwalk
With no arguments, it scans ~/.claude/projects and ~/.codex/sessions, spins up a local server, and opens your browser. You can also point it at a specific session (mindwalk open <session.jsonl>), or generate the underlying data yourself: mindwalk build <repo> writes your repo layout as JSON, mindwalk trace <session> writes the normalized event stream. The installer verifies against a checksum file, so you’re not piping a binary blindly into your PATH.
Underneath, the design is deliberately split into two pieces: a trace (the session log normalized into touch events per file, one adapter per agent format) and a citymap (a deterministic layout of your repo — the same tree always produces the same map, so sessions are comparable across runs). A local Go server joins both pieces and serves a React/Three.js frontend. Clean separation, easy to see where you’d add support for a third agent format if you wanted to.
Why this is a different shape from what we’ve covered before
We’ve written about a few tools in the “what is my agent doing” space — AgentsView’s local dashboard, Claude HUD’s live status bar, Laminar’s observability platform. They’re all built for a different moment: they want you watching while the agent works, or comparing costs and traces across many runs.
Mindwalk isn’t competing there. It’s a post-mortem tool. You run it when the session is already done, the same way you’d open a PR diff instead of looking over someone’s shoulder while they type. It’s a different use case — less “is my agent stuck right now?”, more “did this session earn my trust, and where should I start looking before I merge its work?”.
The honest boundary
A replay shows you where the agent went, not whether what it did there was right. Seeing that an agent touched three files tells you where to look — it doesn’t tell you if the edits were correct. And it’s worth noting that the README doesn’t yet say anything about how the map behaves in a very large monorepo, or whether you can diff two runs of the same task against each other. That’s the obvious feature it’s missing for anyone who wants to use this to evaluate agent quality over time, not just inspect a single session.
It’s worth mentioning that a comment in the Show HN thread came from someone building their own memory tool for a different coding agent, and their read was that the value isn’t in the visualization itself — it’s in being able to quickly tell whether a change you made to your agent’s configuration actually made it smarter or not. That’s probably the most durable use case beyond what the demo screenshots suggest.
Install it or not?
If you run Claude Code or Codex sessions regularly and ever finished a task wondering exactly what it did to get there — this is a five-minute install that answers that question visually instead of by scrolling a transcript. It’s MIT-licensed, it’s completely local, and the install path is a single verified binary.
Has anyone tried it on a large repo yet? I’m curious whether the map becomes unreadable past a certain size, or if it holds up well.