Resume Thread is offered while a pending approval makes continuation ineligible#26699
What happened
After stopping a Claude run with a command approval pending, T3 Code still offered Resume Thread. Clicking it returned:
| 1 | This thread can no longer be resumed from that run. |
The approval was still pending on an interrupted run. The client presented Resume as available even though the server's eligibility check rejects that state. The error did not identify the pending request as the blocker.
Diagnosis
Confirmed in v0.1.3, commit d2c440312e5f39d59827ed466838a623516454d6:
- The client selects the latest interrupted run as resumable without checking pending runtime requests. ChatView.tsx.
- The composer and primary-action controls do not add an approval eligibility check. ChatComposer.tsx, ComposerPrimaryActions.tsx.
- The handler sends
manualContinuationOfRunId. The server rejects that continuation when any runtime request in the thread is pending. useComposerResume.ts, Orchestrator.ts.
A local check extracted and evaluated the actual client and server predicates from those source files, using one interrupted run and varying only the request status:
| Request status | Client offers Resume | Server rejects continuation |
|---|---|---|
| pending | yes | yes |
| cancelled | yes | no |
| resolved | yes | no |
This verifies the predicate mismatch. It is not a full React, RPC, or provider integration test.
The same mismatch remains in main inspected at 886d8f681234e3d88e30e0fd803fe9ccb13b0daf: client eligibility, server validation.
Expected behavior: client and server agree on continuation eligibility. When a pending request prevents continuation, the UI should explain that current blocker rather than offer an action guaranteed to fail. The server must still validate eligibility because state can change between rendering and clicking. Fixing the UI must not bypass legitimate approvals.
Steps to reproduce
Observed user sequence:
- In a Claude thread, reach a pending command approval.
- Press Stop.
- If the approval remains pending after the run becomes interrupted, click Resume Thread.
- Observe the generic rejection above.
Step 3 depends on the stale-approval state tracked in #21935; this triage did not establish its frequency. For a deterministic client regression, seed an interrupted latest run with a pending runtime request and compare the offered action with the server's validation. Repeat with resolved and cancelled requests as controls.
Version
0.1.3, reported by the affected local server. Source review pinned to release commit d2c440312e5f39d59827ed466838a623516454d6. The CLI used to start triage was 0.1.2-nightly.20261022.3541; it is not the affected server version.
Environment
Windows 11, build 10.0.26200. T3 desktop connected to its local server. Claude Agent SDK provider, Claude Opus 5.5.
Evidence
| 1 | 2026-10-28T17:34:36.078Z provider turn: interrupted |
| 2 | 2026-10-28T17:34:36.088Z run 12: interrupted |
| 3 | Approval request: pending; approval node/item: waiting |
| 4 | 2026-10-28T17:34:36.626Z message.dispatch rejected: |
| 5 | This thread can no longer be resumed from that run. |
| 6 | 2026-10-28T17:37:38.460Z same rejection on another attempt |
| 7 | |
| 8 | The supplied screenshot shows the interrupted run and stale approval controls. The Resume error is user-reported and independently recorded in the server trace. |
Related issues
#21935 tracks failure to withdraw approvals after interruption, and #22023 proposes the lifecycle fix. This report concerns a separate client/server eligibility mismatch and its unhelpful error presentation. It does not request removal of the server's pending-request guard.
Fix applied or workaround
None. Triage used read-only state inspection and source review. No repair, restart, or database modification was performed.
Filed by
Prepared by Codex, GPT-6, via t3 triage, with review by 10 dedicated agents.