Hangar, Sep 21-22: can it recover its own stuck tickets?
LunarCrush · Test closed; three tickets still blocked on real requirements
Four tickets blocked after the relaunch, one provider with credit, six real sessions. What a bounded autonomy test found, fixed and still could not close.
After the September relaunch, four tickets sat blocked in Hangar while Linear showed them In Progress. Instead of relaunching them by hand, I used them to answer a more useful question: if I give Hangar exactly one working model provider and the tickets it already failed, how far does it get on its own? This entry covers the audit, the bounded test, what the test itself broke and fixed, and where the line of autonomy actually sits today.
First, read before touching
The audit was read-only: VPS state, Linear tickets and comments, worker artifacts, the CI API and a GET against the delivered prototype. No relaunches, no state changes, no budget changes. Each of the four blocks turned out to have a different real cause. One ticket had done exactly what it was asked (document the absence of a backend signal) and was rejected for not changing code. One had preserved code and commits but an outdated "not deployed" block, while the prototype now answered 200. One had a complete investigation trapped as an uncommitted file, with a review correctly calling its measurement matrix incomplete. And one had a full diagnosis in the provider's final output that the validator rejected as a placeholder, while the real failure was a CI budget that prevented the job from ever starting.
Two recoveries were possible without any model session: fixing the validator so it distinguishes a report's conclusion from the remediation options after it, and publishing the two trapped reports to Linear as comments. Attempt counts stayed; nothing was marked QA. Blocks that reflected reality (zero-cost not demonstrated, CI budget exhausted) stayed blocks, with their reasons corrected.
The bounded test: one provider, no fallback
Then the test. The host manifest was restricted to a single Codex account, no fallback to any other provider, and the sandbox got network access it did not have before. Six real sessions ran across the four tickets. The headline result is honest: Hangar still does not resolve these problems completely without intervention.
| Ticket | What Codex achieved | | --- | --- | | DEV-12794 | Produced a PASS: confirmed 18 tests in the last successful CI run plus 11 local public checks. The flow still ended in waiting_approval; the diagnosis was recovered, autonomous closure was not. | | DEV-12757 | Produced changes and four local tests, source preserved. Could not demonstrate the ticket's zero-cost condition without a verifiably free credential; not published as done. | | DEV-12782 | Ran real browser measurements and passed typecheck. Two reviews rejected the still-incomplete authentication and staging matrix; the session limit stopped the cycle. | | DEV-12748 | No session spent repeating an identical implementation: the prior finding (no backend signal exists) stood. |
Coordination itself held up: no simultaneous executions on the same repositories, and waiting tickets consumed no sessions. The consumption, checked against the provider's own six receipts: 6.56 million input tokens, of which 6.05 million were cache; 509 thousand uncached; 45 thousand output. I did not convert that to money, because how a subscription discounts cache is not something the ledger should guess.
What the test broke and what got fixed
The most instructive failure came from the first session. It finished successfully, but its report mentioned a quota and an expected 503, and the adapter scanned the words of successful reports for exhaustion signals. It falsely marked the only account exhausted for an hour, discarded good output and burned the attempt. The fix limits exhaustion classification to failed runs, with regression tests for both cases. The same pass corrected token accounting (reasoning tokens were being added on top of output that already contained them) and taught the capabilities context that testing credentials for staging already existed on the host, naming variables without exposing values. I had pushed back on that last one during the run, and I was right to: the credentials were installed and usable, the agent just did not know.
A second delivery gave verification reports a real path out: Hangar now publishes finished reports to Linear itself, with deduplication, no Git and no extra model session, and the panel shows Report ready with the report readable in place. Real blocks show Blocked and a reason; deliveries with a URL show Open staging. That closes one of the classes from the September 4 entry, where a finished diagnosis could exist and be invisible.
The continuation, with judgment where the machine stopped
The next day a session picked up the three still-blocked tickets and resolved what needed a decision rather than a retry. The no-backend-signal finding was posted where the ticket asked, with the two options spelled out (ask for a per-window field upstream, or keep the existing client-side rule and close); that decision goes back to me by design. The missing free-tier inference credential turned out to exist already, and was verified against the provider's rate-limit headers without printing it; the one command that installs it was blocked by a safety classifier and handed to me to run. And the investigation that had burned eight sessions was split instead of relaunched: a new ticket carries only the unrun measurement matrix, with the harness and credentials named and partial rows counting as failure.
Where the autonomy line is
The test moved the line but did not erase it. Hangar can now coordinate a single constrained provider, recover trapped diagnoses, publish its own reports and avoid repeating work it already did. What it cannot do is close a loop that requires a judgment call: accepting a finding as final, deciding that a credential condition is satisfied, or choosing to split a task instead of retrying it. Every one of those still came back to a person, and for now that is the correct design: none of the four tickets was marked QA and nothing was promoted anywhere by the machine.
This entry is part of the Hangar case study. The previous entry is what breaks and what changes.