OpenCockpitOpenCockpit
← Back to blog

Review What Your AI Actually Changed — One Tool Call at a Time

Published July 9, 2026 · 5 min read

Cockpit now snapshots your project after every file-touching tool call. Open any reply and read its changes like git history: one entry per Edit, Write, Bash or MCP call, each with the real on-disk diff — in order.

An agent turn ends. The reply says "done — refactored the module, updated the callers, fixed the test." Fifteen tool calls scrolled past. Now the only question that matters: what exactly changed?

Until now the honest answer was "sort of". You could expand each tool call and read its parameters, but that had real blind spots:

  • Bash was invisible. A sed -i, a code generator, an npm install that patches files — the tool call showed you the command, never the resulting file changes. Same for MCP tools and Task subagents.
  • Parameters aren't disk truth. When the AI edits the same file three times, replaying old_string → new_string in your head drifts from what actually landed.
  • git status shows the sum, not the story. By the end of a long turn you get one big flattened diff — the order in which the change was built, which call introduced which line, is gone.

One commit per tool call

Cockpit now takes a project snapshot after every file-touching tool call, on every engine — Claude, Codex, DeepSeek, Kimi, Ollama. Click the file-diff icon on any reply and you get a git-history-style timeline:

  • Left: the sequence. One entry per tool call, in execution order — [Write] nebula/codes.py, [Bash] npm run build, each with a short hash and timestamp.
  • Right: the real diff. File tree with per-file +/− counts, split diff view, compact mode that folds unchanged stretches. What you see is what the disk said — including everything Bash did.

This is the difference between "trust me, I changed it" and being able to replay the edit narrative: first it wrote the new module, then it rewired the callers one by one, then the test. When call #7 is where things went sideways, you see it — isolated, not smeared into a 400-line final diff.

Why this cuts review cost

Reviewing AI output is quickly becoming the actual job. Two things make it expensive: volume (agents produce a lot of diff per prompt) and loss of intent (a flattened diff hides why each hunk exists). Per-call snapshots attack the second one:

  • Each step is small and self-explaining — a tool call has a stated purpose, and its diff either matches it or it doesn't.
  • The sequence carries intent. "Why is this import here?" is answered by which step added it.
  • Changes nobody claimed stand out: files modified in the same window by another session or an external process get a concurrent-change marker instead of silently blending in.

You still review the final state in the Explorer's Changes tab before committing. But when something looks off, you now have the intermediate frames, not just the last one.

Zero setup, fully local, self-cleaning

There's nothing to configure:

  • Snapshots live in a shadow git repo under ~/.cockpit/snapshots/ — your project's own .git is never touched, and your .gitignore is honored (plus built-in excludes for .env*, keys, and other secrets).
  • Everything stays on your machine. Nothing is uploaded anywhere.
  • History keeps itself small: 7 days of snapshots per project, whole repos evicted after 30 idle days, oversized files skipped. A 13 GB monorepo costs about 74 MB of shadow storage; each subsequent snapshot is ~80 ms.
  • Old sessions work too — reopen last week's conversation and the diffs are still there (within the retention window).

Update to the latest release, ask your agent to change something, and click the file-diff icon on the reply. Details in the docs.