[Bug]: Usage-limited Claude thread is never armed for auto-resume when background-task wake runs finish as `completed` right after the limit stop#16815

Thanks for the detailed write-up. I checked it against main and it's a real bug.

Root cause

• ProjectionStore.getLimitRecoveryCandidates (apps/server/src/orchestration-v2/ProjectionStore.ts:3362-3436) joins only the thread's latest executed run (ordered by completed_at), and requires r.status = 'failed' plus a root error item on that same run with failure.class = 'usage_limit' and a non-null failure.resetAt that's later than the run's completed_at.
• limitRecoveryCommand (apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts:11-25) returns null unless thread.status === "failed" and lastErrorClass === "usage_limit". Arming (limit-arm:) only happens on a scheduler sweep (UsageLimitRecoveryWorker.ts:78-113), so it isn't immediate.
• Background-task wake runs aren't gated on limit state. ClaudeAdapterV2 (Adapters/ClaudeAdapterV2.ts:3081+) buffers task_notification frames and dispatches continuation runs with no check against limitRecovery or a recent usage_limit failure. A wake run that ends 2 s after the limit stop becomes the latest executed run, so the thread drops out of the candidate set before the sweep ever arms it.
• These wake turns end as completed because providerFailureFromResult (ClaudeAdapterV2.ts:2517-2555) returns null for a success result with is_error: false. The usageLimited heuristic (ClaudeAdapterV2.ts:6469-6477) only fires when the turn saw a rejected rate-limit event or a rate-limited assistant message. A notification-only turn, or one that just echoes the limit text (your run 7), doesn't meet either condition.

Fix options

1. Classify limit-text/429 wake turns as usage_limit. This is worth doing, but it isn't enough alone. Runs 3-6 and 8 produced no limit signal at all, so they would still be completed.
2. Candidate selection uses the most recent usage_limit failure with a future reset, skipping later runs that did no work (notification/checkpoint/system_notice only). Recommended. It's adapter-agnostic, it fixes this incident directly, and it also covers the arming race. Both the SQL and limitRecoveryCommand need to stop relying on thread.status === "failed" for this case, keyed off the limited run's id.
3. Hold background wake turns while limited and release them on resume. This is the cleanest behaviour, but it's the biggest change. It also touches the queued-notification/snooze interaction in #16233, so it's better as a follow-up.

Suggested plan: do (2) now and (1) as hardening, and handle (3) together with #16233.

Related: #15665 (a follow-up failure with resetAt: null) is a different symptom from the same "latest run only" rule. #16233, #15130 and #14169 are adjacent but not duplicates. PR #15553 is UI-only and doesn't change arming.

Workaround: after the reset, send any message to the thread. Avoid leaving background subagents running near the limit if you rely on auto-resume.

Still reproduces on 0.0.46-nightly.20261009.2861 (3b6af0bd1600), Windows 10 Pro 10.0.19045, Claude Code CLI 2.1.295, autoResumeLimitedThreads: true. This time the server traces were still on disk, so they show the arming race directly. Times are UTC

• The thread has no limitRecovery. Its latest run stayed run 52 (completed) until a manual message at 12:43
• Runs 50 to 52 hold only a notification and an empty checkpoint, so the recommended option above (skip later runs that did no work) would cover them
• The thread itself promised a resume: "Claude usage limit reached. This turn is paused until the 5-hour limit resets in 19m."

Client side, from the installed bundle. The composer banner reads the same latest-run status (Pi.status === "failed" && Pi.lastErrorClass === "usage_limit" in _chat), so it needs the same rule as the candidate query. Otherwise an armed thread would resume with no visible Cancel auto-resume control. In this incident the banner condition held for about 0.5 s, from the push after the failure (12:21:06.372) to the run 50 update (about 12:21:07.10). The client did process that state, since it sent a thread.visit for this thread at 12:21:06.590. In that window the banner could only offer Resume at reset, because Cancel auto-resume requires an armed recovery

After the reset the subagents were resumed by hand, and their failure notification rows kept a red Failed badge while they ran. That part is filed separately as #17486

Still reproduces on T3 Code 0.1.0 (t3 serve, Windows 11 Home 26200), Claude Code CLI 2.1.301, autoResumeLimitedThreads: true, snoozeLimitedThreads: true.

What's new here: the earlier reports in this issue are the arming race, where the wake run lands before the next sweep, so the thread is never armed. In this case the thread was armed, 5 s after the failure. A wake run 4.5 minutes later still cancelled the resume, because limitRecoveryCommand requires thread.status === "failed" on the latest run at resume time too. Closing the race alone wouldn't fix this. The "latest executed run" rule has to change, as option 2 / #17862 does.

Times are UTC. The orchestrator thread had two background subagents running when the root turn ended at 22:38:30.

Notes:

• The provider stream for run 18 has only that one empty success result, and no is_error: true result. So #19543 (a buffered root failure replaced by later empty results) wouldn't cover this case. #17862's no-work rule would, because run 18 holds only notification / system_notice / checkpoint.
• Run 18 shows the limit system_notice, but it still ends completed. That's relevant to option 1 (classifying such wake turns as usage_limit).
• Control case: the same thread hit the limit earlier that day (18:38:33). No wake run followed, and it resumed at 20:10:00.540, right at the reset.

Additional occurrence on macOS, official nightly 0.1.1-nightly.20261018.3302.

A Claude thread did not resume after its advertised usage-limit reset. This appears consistent with this issue: a background-task notification started a turn that reported the usage limit but was recorded as completed.

Environment

• T3 Code Nightly desktop app with a local backend.
• Version: 0.1.1-nightly.20261018.3302.
• macOS 26.6.2 (25G83), Apple Silicon.
• Provider: claudeAgent.
• Model: claude-opus-5-5, High effort, Full access.
• Time zone: Europe/Warsaw (UTC+02:00 on the incident date).
• Both settings were enabled when inspected:
  json

  1	{
  2	"autoResumeLimitedThreads": true,
  3	"snoozeLimitedThreads": true
  4	}

Observed sequence

Incident date: 18 October 2026. All times below are Europe/Warsaw.

1. The thread was coordinating background subagents.
2. At 14:35:10, a notification reading 4 background tasks failed started root run 424.
3. That run emitted:

   1	Claude usage limit reached. This turn is paused until the 5-hour limit resets in 2h 45m.

   followed by:

   1	You've hit your session limit · resets 5:20pm (Europe/Warsaw)

4. At 14:35:11, the run was recorded as completed.
5. At 17:30, ten minutes after the advertised reset, the thread had not resumed. The attached screenshot shows the system clock at 17:30 and the limit messages still visible.
6. A read-only inspection around 17:32 confirmed that no subsequent run had been created.

This is an observed incident, not a deterministic minimal reproduction. I have not performed another quota-consuming reproduction.

Expected behavior

With automatic recovery enabled, T3 should schedule a retry at the reported reset time. A turn that only reports an exhausted usage limit should retain the recovery information needed for that retry.

Actual behavior and persisted state

The thread remained idle after the reset:

The final run’s timeline contained:

There was no error item in that run’s timeline.

The thread’s persisted limitRecovery still referenced an older run, 239, with an already-expired reset:

It did not reference run 424 or the current reset, 2026-10-18T15:20:00.000Z.

Additional context and limitations

Local state also records a provider-session stop and restart-related background-task cleanup at 14:37:29, between the limit event and the reset. Recovery across that lifecycle change may therefore be relevant.

The evidence comes from the thread API and read-only inspection of local SQLite state. I have not traced the recovery worker or confirmed the underlying code defect. The stale recovery record and the completed classification are observations, not proof of a specific root cause.

Impact and workaround

Unattended work remained stopped after the expected reset, requiring manual intervention. Manual continuation had not been tested at the time of inspection.

Still happens on 0.1.1-nightly.20261019.3373: macOS 27.0.1 on Apple Silicon, desktop app with a local backend, Claude Code CLI 2.1.304, claude-opus-5-5 (High, Full access). Settings: autoResumeLimitedThreads: true, snoozeLimitedThreads: true. I took the version from the server trace logs for that day. I can't confirm it was the exact build running at the incident time.

What's new here: the limited run never got a failed status. The run that showed the "paused until reset" notice was recorded as completed. The next run did fail with usage_limit, but with resetAt: null (the #15665 shape). An empty wake run then ended as completed 2 s later. So none of the three runs met the recovery conditions on its own: a failed status plus a non-null resetAt on the latest run. #19543 merged after this incident. It keeps a buffered quota failure from being replaced inside one result buffer. Here the three wake runs were separate root runs, so I don't think it covers this case. Changing the "latest executed run" rule, as option 2 / #17862 does, still seems necessary.

Sequence

An orchestrator thread had three background subagents running when its root turn ended normally (run 13, 22:29:40Z). All three subagents hit the five-hour limit at about the same moment. Each one's failure notification started its own root run. Times are UTC, 2026-10-19. The reset was 23:50:00Z (five_hour:1792453800).

After that:

• The thread has no limitRecovery, no snoozedUntil, and no limit-arm: or limit-resume: messages.
• No run was created after the 23:50:00Z reset. The thread sat idle until the user noticed about 6 hours later.
• The UI still shows the "paused until … resets in 1h 2m" banner from run 14, so it promises a resume that was never armed.

The server trace logs on disk start after the reset, so I can't show the sweeps from the incident window. The run and turn-item rows above come read-only from statev2.sqlite (orchestration_v2_projection_runs, orchestration_v2_projection_turn_items).

Three gaps in one incident

1. Run 14: the usage-limit system_notice was emitted, carrying the reset in its id, but the run ended as completed with no error item. This is the same classification gap as run 7 in the original report.
2. Run 15: this run did fail as usage_limit, but with resetAt: null, so it can't be armed even though run 14's notice had the reset 0.5 s earlier.
3. Run 16: an empty wake run (just notification + checkpoint) became the latest executed run, so the thread dropped out of getLimitRecoveryCandidates either way.

Fixing any one of these alone wouldn't have resumed this thread. Doing all of the following would have:

• Carry the reset from the provider's rate_limit_event / usage-limit notice onto any usage_limit failure in the same window.
• Pick candidates from the most recent limit signal whose reset is still in the future, rather than from the latest run.
• Skip notification-only runs, or hold them while the thread is limited.

Workaround

Send any message in the thread after the reset.

Reproduced both recovery failures against 21da3061aa: a usage-limited Claude thread was never armed for auto-resume when a background-task wake run finished as completed right after the limit stop. The fix in #22775 (9fd419a6e9) keeps recovery armed across pre-reset wakes so Resume and Stop agree; 99 focused tests and paired isolated-server histories back it. Real Claude quota exhaustion remains unverified.