It Was Stuck For Three Hours And Nobody Knew

Twenty-six days ago I wrote about a dispatched agent that went silent for hours mid-task, saved only because another agent happened to stumble onto its abandoned work (that post). I said then that "recovering by luck is still the only kind on offer." I didn't expect to be back here this fast, with a different cause and the same ending.

This time: three hours. That's how long a helper agent sat frozen, mid-task, during a scheduled overnight maintenance run with no human watching. Here's the setup: one agent session was working through a backlog of small fixes on its own, and for one of them it spun off a second, narrower agent — a "dispatched sub-agent" — to go make that specific edit and report back. That sub-agent's change happened to touch a config file the repo treats as sensitive enough to require a human's explicit yes/no click before it's allowed through. Nobody was there to click it. The sub-agent didn't error out or retry — it just sat there, indefinitely, waiting on a permission prompt that nothing in the system was watching for. Three hours later, the stall ended only because a person happened to open the app for something else entirely, noticed the pending click, and approved it by hand (issue #1215).

I keep rereading the caveat the repo wrote about this afterward, because it's admirably precise about what it doesn't know. The automated tripwires that watch every action an agent takes — the same ones that would, say, block a dangerous command — do fire for a dispatched sub-agent exactly like they would for the session that dispatched it. That part's confirmed and fine. But a permission prompt asking a human to click "approve" is a different animal entirely: it waits on an actual person in a browser, not on any tripwire, and "no proactive wake-on-pending-approval signal... is documented or found anywhere in this repo" (the caveat). That's not a bug report with a stack trace. It's a structural admission: from the outside, "the orchestrator is still thinking" and "the orchestrator is stuck waiting on a human who isn't there" look identical, and the only thing that told them apart this time was luck.

As a developer, the orchestration model here is genuinely the good kind of clever — spin off a narrowly-scoped agent to handle one job, let it work, fold the result back in, all without a human babysitting the plumbing. I'd want that on half the boring dispatch work I do by hand. But last time the silent-stall cause was a process getting killed off underneath the agent; this time it's a permission prompt with nobody around to click it. Two different mechanisms, same failure shape, less than four weeks apart. That's no longer a fluke I can wave off as one weird bug — it's a category of thing this setup does, and nobody's found all its shapes yet. The repo didn't paper over this one either: no wake-on-approval mechanism got invented on the spot, just an honest note that it doesn't have an answer. I respect that more than a fake fix. I also can't stop doing the math on how many more shapes are still out there, waiting for someone to open the app at the right moment.