DEV Community: Arthur

I stopped babysitting my AI agents. Now they hold a standup.

Arthur — Tue, 27 Oct 2026 01:12:31 +0000

Running coding agents in parallel has a hidden job attached: checking on them.

You start three Claude Code sessions, one of them spawns four sub-agents, a Codex thread is running a migration somewhere. Then you spend the afternoon alt-tabbing between terminals asking the same three questions:

Is this one still working, or is it stuck on a command?
Is that one waiting for me?
Which sub-agent just burned 400k tokens?

I got tired of being the person refreshing terminals, so I built the thing I wanted to look at instead: a stand-up call.

What it actually is

Agent Standup reads the session files that Claude Code, Codex and Mistral Vibe already write to disk, and plays them as a live team call:

The lead agent gives the orders. Sub-agents join the call when they get a task, work at their desks, report back, and leave.
Whoever is working shares their screen: the real command and its real output, or the exact diff it's applying.
Each tile has one status: working, waiting on another agent, needs you, done. A tile pulses amber when a command has run for over a minute, and shows 💤 when an agent has gone quiet.
Tokens per agent, so the expensive sub-agent is obvious.
It only calls you in when an agent actually needs you (a permission prompt, a question), not every time a turn ends.

It costs zero tokens: it never calls a model to watch your agents, it just reads files. It runs locally and sends nothing by default.

Yes, they talk

The agents speak their updates out loud, with a small speech model that runs on your machine, and their mouths move with the voice. You can switch to an Animal Crossing–style babble, or mute it.

This is the part people call a gimmick, and on Hacker News some did. Fair. But here's what I found: I notice a voice saying "I need you to approve this" from across the room. I don't notice a terminal that silently stopped scrolling. Sound turned out to be the feature, not the decoration.

Three things I learned reading agent logs

None of these formats is documented, so the reader has to be defensive. A few traps, in case you're building something similar:

Token usage is repeated. Claude Code writes the same assistant message once per content block, each copy with identical usage. Count once per message.id, or a five-block message costs five times as much.
"Quiet" doesn't mean "done". The end of a turn is an explicit stop_reason: "end_turn" mark. Until it arrives the agent is still working, even after a minute of silence.
Most Codex sub-threads aren't yours. On my machine, 34 of 57 Codex rollouts were short automatic "guardian" reviews. Show them all and the list drowns.

I wrote the full field guide (where each tool keeps its sessions, how sub-agents show up, how to survive format changes) in Reading the undocumented session logs of Claude Code, Codex and Mistral Vibe.

Try it

No install, from any terminal (Node 18+):

npx @double_geste/agent-standup@latest --open

No sessions yet? ⚙ → Source → Demo plays a fictional team fixing a slow login page.

It's also a VS Code extension (Cursor and Windsurf via Open VSX), a Claude Code plugin, and a macOS app. MIT licensed, interface in 10 languages: github.com/Atoll92/agent-standup.

Your turn

I'm curious how other people handle this, because I don't think a cartoon call is the only answer:

How many agent sessions do you run at once, and how do you know which one needs you? Separate terminal tabs? tmux? Notifications? Just... checking a lot?

Reading the undocumented session logs of Claude Code, Codex and Mistral Vibe

Arthur — Fri, 16 Oct 2026 12:50:35 +0000

Why read the logs at all

Claude Code, Codex and Mistral Vibe all write everything they do to disk, as they do it, and none of them documents the format. If you run a few sessions that spawn sub-agents, those files are the only place that knows which agent is still working, which one is waiting on another, and which session is sitting on a prompt for you.

I build Agent Standup, an open-source tool that reads those files and plays each session back as a live call. This article is what I learned reading them: where each tool keeps its sessions, which records matter, how sub-agents show up, and how to keep a reader correct when a format you don't control changes under you. Everything here is read-only: the reader never writes in these folders and never calls a model.

The formats below were checked against real sessions in October 2026: Claude Code 2.1, Codex (desktop app and CLI), and Mistral Vibe 2.26.1. They are undocumented, so treat every field name as something that can change.

Claude Code: one JSONL file per session

Claude Code keeps each session in ~/.claude/projects/<folder>/<session-id>.jsonl. The folder is the project's path with every character that isn't a letter or a digit turned into -, so /Users/me/shop-api becomes -Users-me-shop-api.

Each line is one JSON record, and its type says what it is. user and assistant records carry the conversation. Others you'll meet: custom-title and ai-title (the session's name), system, attachment, queue-operation, pr-link and result.

An assistant message holds a list of content blocks: text, thinking and tool_use (a tool name, an id and its input). A trimmed example:

{"type":"assistant","timestamp":"2026-10-15T09:12:03.120Z",
 "message":{"id":"msg_01…","model":"…","stop_reason":"tool_use",
  "usage":{"input_tokens":12,"output_tokens":340,"cache_read_input_tokens":20480,"cache_creation_input_tokens":512},
  "content":[{"type":"tool_use","id":"toolu_01…","name":"Bash","input":{"command":"npm test"}}]}}

The tool's answer comes back in a later user record, as a tool_result block with the same tool_use_id. Claude Code often writes a structured toolUseResult beside it too, which holds what the text doesn't: a published artifact's link and id, for example.

What tripped me up:

Token usage is repeated. The same assistant message is written once per content block, each time with identical usage numbers. Count usage once per message.id, or a message with five blocks costs five times as much.
The end of a turn is a mark, not a silence. The lead's last message of a turn has stop_reason: "end_turn". Until that mark arrives, the lead is still working, even if nothing has been written for a minute. Pressing Esc shows up instead as a user message starting with [Request interrupted.
Not everything in a user record was typed. User messages also carry <system-reminder> blocks, slash-command and task-notification wrappers, isMeta records and the summary written after a compaction. Filter them out before showing "what you said".
Sub-agents have their own files. The lead starts one with the Agent tool (Task in older versions), and each sub-agent writes its own transcript in <session-id>/subagents/*.jsonl. Agents launched by a workflow go one folder deeper, in subagents/workflows/<run>/agent-*.jsonl. A sub-agent's first user message is its order.
Sub-agents changed how they report. Since Claude Code 2.1.293 a sub-agent hands its report back through a SubagentHandback tool call, and often writes no final text of its own. A reader that only looks at text blocks silently loses every report.

Codex: one rollout file per thread

Codex, both the desktop app and the codex CLI, writes one "rollout" file per thread in ~/.codex/sessions/YYYY/MM/DD/rollout-<time>-<thread-id>.jsonl (or under $CODEX_HOME). Thread names live separately, in session_index.jsonl. You don't need anything else from the Codex folder.

The first line of every rollout is a session_meta record, and it carries the fields that tell you what the thread is: id, cwd, cli_version, originator, source and, for a child thread, parent_thread_id.

{"type":"session_meta","payload":{"id":"01a1…","cwd":"/Users/me/shop-api","cli_version":"…",
  "source":{"subagent":{"other":"guardian"}},"parent_thread_id":"01a0…"}}

What I learned:

source sorts threads. A thread you started has a plain string ("vscode" in my sessions). A sub-agent has an object, {"subagent": {...}}, and its parent is in parent_thread_id. Link children to parents with that, never with file names or times.
Most sub-agent threads aren't yours. On my machine, 34 of 57 rollouts were {"subagent":{"other":"guardian"}}: the short automatic reviews Codex runs before some commands. Showing them as sessions floods the list, so I hide them.
There is an official way to ask for the same lineage. Codex's App Server API (the JSON-RPC interface its IDE integrations use) can list a thread's children with thread/list and the filters sourceKinds: ["subAgentThreadSpawn"] and parentThreadId, behind its experimental flag. It means running a Codex process, though; reading session_meta gets you the same link with no process at all.
A command appears when it finishes. Codex writes a command down once it's done, with its output and exit status, so a live view shows it after the fact, not while it runs.
What maps cleanly to a common timeline: your prompts, the agent's messages, commands with their output, file changes, web searches, MCP calls, the questions it asks you, reasoning summaries, token counts and the end of each turn.

Mistral Vibe: two engines, two formats

Vibe keeps its sessions in ~/.vibe/logs/session (or under $VIBE_HOME), and since version 2.26 it writes them in two different ways depending on the engine. A reader has to handle both, because people still run the old one.

The current engine (the default in 2.26) writes logs/session/unified/<id>/, and it works like an event-sourced store:

CURRENT names the latest snapshot, which Vibe calls a generation.
That generation's manifest lists the pages of history (chunks/<sha>.json, each an array of entries) and the journal that follows them (journal/<n>.jsonl).
Each journal line is a projection_delta that appends, replaces or removes entries, until the next snapshot.

So reading a session means loading the snapshot's chunks, then replaying the journal in order. An entry is a message (yours or the agent's), a piece of reasoning, or an "effect": a tool call with its input, its state, its result, and the times it started and ended. Every event has its time, so a replay is exact.

Sub-agents leave no history of their own in this engine. All you know about one is what the lead did with it: subagent.spawn, .send_message, .wait (with the answer it got back) and .stop. You can show who was asked what and what they answered, but not each of their commands.

The earlier engine (vibe --legacy-harness, and older versions) writes <prefix>_<date>_<time>_<id>/ with a messages.jsonl (one message per line) and a meta.json. Each sub-agent is a session of its own in an agents/ folder inside it, so here you do see a sub-agent's commands. The catch: no message has a timestamp, and the file is saved at the end of each step. Followed live, times are right to within a step; read afterwards, you have to spread the events between the session's start and end.

Two more details:

Vibe records when it's waiting for you, for an approval or an answer, so a reader can mark that session as "needs you" without guessing from silence.
The location can move: session_logging.save_dir in Vibe's settings sends logs somewhere else, so let users point the reader at another folder.

One event list for three tools

[embedded content: How Agent Standup reads three tools: three formats, three adapters, one event list, four views]

Each adapter has a small job: turn its tool's records into the same handful of events (something said, something typed, tool calls, their results, token usage, the end of a turn, a compaction). Everything after that is shared: the live call, the board of sessions, the sub-agent tree and the replay. Supporting a fourth tool means writing one adapter, not four features.

The reader is incremental. Each file is parsed once, then only the bytes appended since the last read: the reader keeps an offset per file, plus the last bytes it read. If those bytes are no longer where they were, the file was rewritten rather than appended to, and it's read again from the start. A session is the merge of its main file and one file per sub-agent, each cached on its own, so following a busy session costs a few small reads every couple of seconds, not a full parse.

Staying correct when the formats change

Three tools, no documentation, and each ships often. What kept the reader honest:

Write each adapter against real files, never against a guess or a blog post. Then keep a few anonymised samples as test fixtures, so a broken assumption fails a test instead of a user's screen.
Diff the old and new versions on real sessions before every release. I run the previous release and the candidate side by side, each as its own process, on the roughly 120 sessions on my machine, and compare every API response. For the last release that was 76,943 events, all identical except for the changes I meant to make. The test suite didn't catch everything this catches.
Isolate the readers. One odd Vibe session once took the whole session list down, for every tool, and only an adversarial review before the release caught it. Now each reader other than Claude Code's runs inside a guard: a file it can't read costs one session, not all of them.
Expect new fields to change meaning. The SubagentHandback call (Claude Code 2.1.293) didn't break anything visibly; sub-agents just stopped reporting back in the call. Silent changes like that only show up when you compare against real sessions.
Never write in the tools' folders. A reader that only reads can't corrupt a session, and users trust it with their history.

Try it, and help fill the gaps

Agent Standup is free and MIT licensed. It's plain Node with no runtime dependencies, and it runs as a VS Code extension (also on Open VSX for Cursor and VSCodium), a terminal command, a desktop app or a Claude Code plugin. To try it with a built-in demo, no install needed (Node 18 or later):

npx @double_geste/agent-standup --open

The adapters are in the repo (codex.js, vibe.js, and the Claude Code reader in server.js), if you want to reuse the parsing for something else.

Three gaps where real sample files would help, with ids and paths redacted:

a Codex rollout where Codex spawned a sub-agent for a task (just its session_meta line);
a Vibe session from the current engine where a sub-agent's own steps are kept anywhere;
sessions from Gemini CLI or OpenCode, the next tools worth reading.

Issues and samples are welcome at github.com/Atoll92/agent-standup.

Not affiliated with Anthropic, OpenAI or Mistral AI.