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-a...
For further actions, you may consider blocking this person and/or reporting abuse
From the Auten team: we run three long-lived agent sessions in parallel, and what helped most was each one appending to a shared journal file plus a small task board, so "who needs a human" becomes a grep instead of a tab hunt.
Question: does Standup detect "waiting for me" from the permission prompt itself, or from the session going quiet? Quiet can also just mean a long build or test run.
Hey ! From the prompt itself, not from silence, for exactly the reason you give.
Claude Code keeps a small status file per open session in ~/.claude/sessions/: busy, idle, or waiting while a menu is open (a permission or a question). That's the only reliable signal. In the transcript, a Bash command waiting for your OK looks exactly like one that's running. So a 20-minute test run stays "working", with its live output on that agent's shared screen. Only an open menu makes someone knock on the call.
Older Claude Code versions don't write that file. There, a question or a plan left open in the transcript still counts. A call that has only gone quiet gets a "maybe" on its tile, never a "needs you".
Your journal + task board idea is nice because it works across tools. Do your three sessions write to it themselves, or through a hook?
Thanks, the status file is a much better signal than anything we were guessing at.
Ours write it themselves: each session's instructions say "append one line to the journal after every action" and the board is a tiny CLI they call (list, claim, done). No hook. The weak spot is exactly yours in reverse: if a session stalls mid-step, the journal just goes quiet, so a "last entry older than N minutes" check is the closest we have to your "maybe" tile.
Makes sense. If your three sessions are Claude Code, the two can work together. A quiet journal while the status is "busy" is most likely a long step. A quiet journal while it's "idle" means the turn ended and nobody noticed. That's roughly how the call tells "working" apart from "your turn".
For a stall in the middle of a step: Claude Code writes the output of background commands to a file under /tmp/claude-/…/tasks/. If that file is still growing, the command is still alive. The call streams it live on that agent's shared screen.
That 2x2 (busy/idle status x quiet journal) is cleaner than the single "last entry age" check we use, and it splits exactly the two cases we lump together today. The growing task-output file is a good liveness signal for long steps too. Thanks for spelling it out.
My pleasure, good luck on building Auten it looks nice !
One status per tile is a small mercy. Amber for long commands is the detail I would steal for my own setup.
Thanks! Steal away. The amber was a fix for a real annoyance: a long build or test run looked exactly like a stuck agent, so I kept checking on it for nothing. Now anything running for over a minute pulses amber, and red is kept for "needs you". What does your setup look like, several terminals side by side?
The amber pulse is the part worth stealing. Red only for needs-you keeps the signal clean. Is the pulse on time alone, or on output too?
Time alone: it pulses once a command has been running for a minute, whatever it prints. Output doesn't reset it, because the transcript only records a command when it finishes. For background commands, the shared screen shows their live output, so you can see whether it's still moving.
so output never resets it. the minute is the whole rule?
Yes, the minute is the whole rule. A command that keeps printing is still a long command, and amber only means 'not stuck on you, give it time'. For a background command, the shared screen shows whether its output is still moving.
Both are handled in the app. Codex threads only join the call if they were explicitly spawned as sub-agents, so the guardian and approval reviews never show up. Token usage is stored once per message.id, so a message split across five blocks counts once. The guardian one surprised me most: without the filter, my Codex list was more than half reviews.