[Bug]: auto-resume is cancelled as "user-took-over" by any user message — including one that was itself rejected by a limit

[eddy-curly]

Area

apps/server

Steps to reproduce

1. Run a Claude thread until a five_hour usage limit rejects it. Auto-resume arms, and the timeline shows:
   Usage limit reached (five_hour). Auto-resume scheduled in ~247 min.
2. Send any message in that thread while the resume is pending. Real example:
   "I am going to bed now, ensure you keep going through till you get done with the work that is expected"
3. That message is itself rejected — in this case by a different limit:
   "You've hit your org's monthly spend limit · run /usage-credits to ask your admin for a higher limit"
4. Wait for the scheduled resume time.

Expected behavior

The resume fires. The user asked for continuation and did not turn auto-resume off in the overlay. Per the feature's own contract, only the per-thread toggle should stop a resume.

Actual behavior

Auto-resume cancelled: user-took-over.

The thread is left with no pending resume and never wakes. Confirmed in t3x-auto-resume.json: thread 1b4dacbe-f598-4ffc-9247-df01bbd86a2d ("Cross-check PM and Installer inventories") holds pending: null, with only the previous day's fire in firedAtMs. The arm created at 06:34 is simply gone.

Observed 2026-07-31: armed 06:34:38Z, cancelled 10:41:20Z.

Root cause

Two defects that compound into a permanently stranded thread.

1. Any user message cancels the resume. apps/server/src/t3x/autoResume/guards.ts:132:

if (newestUserMessageId(thread) !== baseline.newestUserMessageId) return "user-took-over";

The baseline is snapshotted when the resume is scheduled, so any user message arriving afterward kills it. The guard infers "the human is driving now" from a message whose literal content was "I am going to bed."

2. Nothing can re-arm while a resume is pending. apps/server/src/t3x/autoResume/decide.ts:62:

if (hasPending) return { kind: "skip", reason: "already-pending" };

So the fresh rejection triggered by the user's message is dropped, and the wake tick then destroys the pre-existing arm. Net pending count afterward: zero. Nothing is left to wake the thread.

Additionally: the org monthly spend limit cannot arm auto-resume at all. Detection requires an account.rate-limits.updated runtime event (Reactor.ts:128), which ClaudeAdapter.ts:2908 emits only for SDK rate_limit_event messages, and classifyRateLimit requires a status field. Grepping the repo for spend-limit / usage-credits handling returns nothing. This may warrant a separate issue — and note a monthly cap should probably not be retried on the backoff ladder at all, since it will not reset for days or weeks. At minimum it must not silently destroy a valid five_hour arm.

Proposed fix

Re-arm rather than cancel. Drop the user-took-over branch and re-baseline onto the newest user message, keeping the pending resume alive.

The remaining guards already cover the cases this one was reaching for:

• progressing prevents double-dispatch while a turn is running or starting.
• awaiting-input still blocks firing into an open approval or user-input prompt.
• thread-gone still handles deleted / archived / settled threads.

Also narrow already-pending so that a rejection whose computed resume time is later than the current pending one re-schedules instead of being dropped.

Only the per-thread overlay toggle (enabled: false, already honoured at Reactor.ts:193) should cancel a pending resume.

This is the sibling of #6

#6 fixed thread-advanced false-cancellation by requiring positive evidence before cancelling — see the comment at guards.ts:135-140. The user-took-over branch directly above it never got the same treatment.

Measured across this install's 46 auto-resume timeline events: 23 armed, 13 fired, 10 cancelled. Six cancellations were the pre-#6 thread-advanced bug (all on 2026-07-25). The other four are user-took-over — 2026-07-27 ×3 and 2026-07-31 ×1. Since #6 shipped, roughly 24% of armed resumes (4 of 17) have been lost to this guard.

Impact

Major degradation or frequent failure. This defeats the entire purpose of auto-resume for overnight work: the moment a user leaves instructions before going to bed, the resume they were relying on is destroyed.

Version or commit

main @ 0a23554

Environment

Windows 11 Pro 26200, desktop app, Claude provider (claudeAgent).

Logs or stack traces

2026-07-31T06:34:38.710Z t3x.auto-resume.scheduled Usage limit reached (five_hour). Auto-resume scheduled in ~247 min.
2026-07-31T10:41:20.068Z t3x.auto-resume.cancelled Auto-resume cancelled: user-took-over.

All four occurrences of this failure in the local timeline:

2026-07-27T00:11:20.295Z Auto-resume cancelled: user-took-over.
2026-07-27T17:51:29.395Z Auto-resume cancelled: user-took-over.
2026-07-27T23:14:20.755Z Auto-resume cancelled: user-took-over.
2026-07-31T10:41:20.068Z Auto-resume cancelled: user-took-over.

Workaround

Do not type anything in a thread that has a pending resume. Not viable in practice, since the usage-limit banner is exactly the moment a user wants to leave instructions before stepping away.

[radroid]

Priority triage — 2026-08-07: Rank 2 / 11 — Tier 1 (active reliability bug)

Highest-priority bug. This silently defeats the headline overnight-autonomy feature: a "keep going" message that is itself rejected by a limit cancels the pending resume as user-took-over, and the thread never wakes. Contained fix in the fork seam, high value. Land after the #49 sync.

[radroid]

Triage 2026-08-07 — P1, and it is the one item on the board that does not have to wait for the sync

Two properties put this first among the things that can start today:

1. It is the only open issue describing a currently-active, measured loss. Everything else on the board is either a design (#38, #42, #44, #45, #46), a cleanup of code that already works (#40), or infrastructure (#41, #47, #49, #51). This one has a rate attached: 4 of 17 armed resumes lost since #6 shipped, ≈24%.

2. It is sync-independent. git log 30c962280..upstream/main -- apps/server/src/t3x/ is empty — upstream has made zero commits inside the fork seam across the 103-commit backlog. guards.ts and decide.ts are fork-owned, so a fix landed now carries no rebase cost through #49 and can proceed in parallel with it.

Verified in the tree: guards.ts:132 is still

if (newestUserMessageId(thread) !== baseline.newestUserMessageId) return "user-took-over";

sitting directly above the #6 comment block that documents why advancement was changed to require positive evidence. The asymmetry the issue describes is real and unchanged.

One sequencing note

#44's implement path inherits this bug (that issue flags it itself, under Risks). Long unattended implement turns are exactly what hits a usage limit, so #44 should not be built until this is closed.

Scope caution

The issue proposes three changes: drop the user-took-over branch and re-baseline; narrow already-pending so a later-computed resume re-schedules; and handle the org monthly spend limit. The third is a genuinely separate feature — spend-limit detection does not exist anywhere in the repo (no account.rate-limits.updated path reaches it), and the issue itself notes a monthly cap probably should not ride the backoff ladder at all. Recommend splitting it out and shipping the first two, which are the ones that stop the loss.