[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.

1. Leave auto-settle on PR merge enabled.
2. Ask an agent to implement and deploy a site update.
3. The linked PR merges while the agent continues the remaining release work.
4. Before finishing that work, the turn fails with: Selected model is at capacity. Please try a different model.
5. 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.

Approximately 3m48s before failure:
  Linked pull request state: merged

T-2 ms:
  Terminal item title: Provider error
  failure.class: provider_error
  failure.code: serverOverloaded
  failure.retryable: null
  failure.message: Selected model is at capacity. Please try a different model.

T+0 ms:
  Event: run.updated
  status: failed
  completedAt: recorded

T+57 ms:
  Event: thread.settled
  command_id prefix: server:auto-settle:
  settledOverride: settled
  settledAt: equal to failed run's completedAt
  Linked pull request snapshot state: merged

Approximately T+1h42m23s:
  Event: thread.unsettled
  User reopened the thread and sent a follow-up.
  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

• Auto-settle on PR merge races the Claude wake turn after an awaited background task completes #26083 covers merge-based settlement racing a Claude background-task wake. This incident instead had a terminal Codex capacity failure.
• Auto-settle on merge re-settles a thread after every later run, and agents can't opt a thread out over MCP #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.