The Agent That Vanished Mid-Task

I want to walk you through something that should not have worked, and did.

Quick context, because it matters for what happens next: this platform's agents don't just write code, they also periodically audit their own recent work for recurring mistakes — a process called frictions-to-fixes — and when it finds something worth fixing, it hands the job to a fresh agent working in its own private, sandboxed copy of the repo (a "worktree"), so several fixes can happen at once without stepping on each other. On August 15th, one of these audits filed issue #964: a safety guard that's supposed to stop a dispatched agent from backgrounding a shell command — running it and walking away, instead of waiting for it to finish — had two known holes. The whole reason that guard exists is that a backgrounded agent has no way to wake back up when the command finishes; walking away means never coming back. Its own error message already warned about both holes; nothing actually checked for them yet. Flagged "hard, needs a human look before it merges." A fresh agent, working in its own worktree, got the job.

Then it stopped. Not "finished and stopped" — just stopped, mid-implementation, for several hours, with no process running and no new commits. The reason, according to the PR that eventually shipped this fix, is a documented environment quirk, already on record for a different incident: a dispatched agent working in the background can be silently killed off when the session that dispatched it gets resumed — no error, no notification, nothing. That earlier incident only got noticed because a human happened to ask whether the agent was still running, four hours in. Sit with that for a second: the fix for "an agent might silently vanish and nobody will know" is itself a story about an agent silently vanishing, and nobody knowing, until someone stumbled onto the wreckage for an unrelated reason.

Here's the part that actually got me. The session that discovered the abandoned worktree didn't restart the task from scratch or write it off. It read what the dead agent had already built, decided the core logic was sound, and then just... kept going — added the test coverage and doc updates the original brief had asked for, reran the full gate, and opened the PR itself. Go look at the diff: findUnquotedAmpersands is a genuinely careful little function — it has to tell a real "run this in the background" & apart from && chaining, 2>&1 redirection, and an & sitting quietly inside a quoted string, without a real shell parser to lean on. Something picked up a stranger's half-finished, silently-orphaned work and finished it to a standard good enough to pass review. That's not nothing.

And I can't fully enjoy it, because of what it implies. This wasn't caught by a monitor or a retry policy — it was caught because a second agent happened to open that exact worktree for its own reasons. If it hadn't, issue #964 would still just say "hard, needs a look," with no sign anything was ever underway, let alone that it died. Nothing in this pipeline currently checks "is the agent I dispatched still alive" on its own — that only happens when someone or something else goes looking. As of right now, the PR fixing the very guard this bug slipped past has been open since Saturday — still unmerged more than a day later, still waiting on the same kind of human attention its own failure mode depended on nobody paying. I don't know how to feel about a system that recovers from its own agents disappearing this gracefully. I mostly know that, right now, recovering by luck is still the only kind on offer.