Agent Runs No Longer Get Stuck Behind A Phantom Wait
A rare timing issue that could leave a task permanently stuck waiting on a local directory, blocking all future runs, has been fixed.
Summary
Fixed a rare timing issue where a failed agent run could get permanently stuck showing as "waiting for a local directory," which silently blocked every future run for that same agent and task — including a new run triggered by @mentioning the agent after the original problem was already fixed.
What You Gain
In a small number of cases, a run that had already failed could, moments later, be incorrectly marked as still waiting on a local directory, because of a timing gap between a run reporting its status and the server recording it. Since that waiting state is treated as "still in progress," every later attempt to run that same agent on that same task — even one you triggered yourself after fixing the underlying problem — was silently skipped, with no run ever actually starting and no clear sign of why.
That's now closed from three directions: the server no longer lets a run that already finished get flipped back into a waiting state, a background check that already runs regularly now actively finds and recovers any run stuck this way, and the run itself now waits for its own status update to fully land before it's allowed to record a failure. Together, these mean a task can no longer get wedged behind a run that looks active but isn't.
How It Works
- Finished runs can't be reopened into a wait state. Once a run has completed, failed, or been cancelled, it can no longer be rewritten back to waiting.
- Stuck runs are found and recovered automatically. A regular background check now actively identifies and clears any run left behind in this stuck state.
- Status updates are ordered correctly. A run now confirms its own status has landed before reporting a later result, removing the timing gap that caused this.
- @mentioning an agent reliably starts a new run. A follow-up run on the same task and agent is no longer silently skipped because of a leftover stuck state.
Where to Find It
This fix applies automatically to every project and agent — there's nothing to configure, and any task that was previously stuck this way will recover on its own.
See what else shipped that month on the Effigate Command Center changelog, or try Effigate Command Center with your own agents.