[Bug]: Auto-settle on PR merge hides a thread that failed before finishing its work#27052
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Observed incident, confirmed through read-only inspection of T3's persisted events. This has not been reproduced with a controlled provider fixture.
- Leave auto-settle on PR merge enabled.
- Ask an agent to implement and deploy a site update.
- The linked PR merges while the agent continues the remaining release work.
- Before finishing that work, the turn fails with:
Selected model is at capacity. Please try a different model. - T3 automatically settles the thread immediately after the failed run.
Expected behavior
A thread whose latest run failed with an unresolved provider error should remain visible as needing attention, even if its linked PR merged. A merged PR does not establish that the requested deployment or verification finished.
Actual behavior
The failed thread moved into Settled and disappeared from the active list despite unfinished work. I noticed that the site had not updated, searched for the task, found it settled, and manually reopened it and sent a follow-up to restart the work.
Impact
Minor bug or occasional failure
The unfinished task becomes easy to miss because the thread is moved out of the active list immediately after the provider failure. In this incident, the work stayed stopped until I checked the unchanged site and found the settled thread.
Version or commit
Server version checked during investigation: 0.1.4-nightly.20261027.3783. The version was read from the running server, not recorded in the failure event itself.
Environment
macOS arm64; Codex provider; GPT-6.1 Sol. Codex CLI version was not collected.
Logs or stack traces
Sanitized summary of persisted records, not a raw log dump. Times are relative to the failed run's completion. Project, account, repository, branch, thread, run and command identifiers, private URLs, local paths, and absolute timestamps are omitted.
| 1 | Approximately 3m48s before failure: |
| 2 | Linked pull request state: merged |
| 3 | |
| 4 | T-2 ms: |
| 5 | Terminal item title: Provider error |
| 6 | failure.class: provider_error |
| 7 | failure.code: serverOverloaded |
| 8 | failure.retryable: null |
| 9 | failure.message: Selected model is at capacity. Please try a different model. |
| 10 | |
| 11 | T+0 ms: |
| 12 | Event: run.updated |
| 13 | status: failed |
| 14 | completedAt: recorded |
| 15 | |
| 16 | T+57 ms: |
| 17 | Event: thread.settled |
| 18 | command_id prefix: server:auto-settle: |
| 19 | settledOverride: settled |
| 20 | settledAt: equal to failed run's completedAt |
| 21 | Linked pull request snapshot state: merged |
| 22 | |
| 23 | Approximately T+1h42m23s: |
| 24 | Event: thread.unsettled |
| 25 | User reopened the thread and sent a follow-up. |
| 26 | Another run started. |
The automatic command confirms server-triggered settlement. The linked PR was already merged, and the timing is consistent with merge-based settlement becoming eligible as soon as the run failed. No code change, automated regression test, or controlled reproduction was performed during this investigation.
Screenshots, recordings, or supporting files
The relevant event fields are included above. The original screenshot and raw records are omitted to avoid exposing private project details.
Workaround
Find the thread in Settled, reopen it, and manually resume the unfinished work.
Related reports
- #26083 covers merge-based settlement racing a Claude background-task wake. This incident instead had a terminal Codex capacity failure.
- #26097 covers repeated settlement of post-merge follow-up runs. This incident concerns the original run failing and being hidden before its requested work finished.
Prepared with Codex, GPT-6.1 Sol, through T3 Code.