fix(server): Claude session crons no longer die with the idle session#23636

Problem

A Claude thread that schedules a session cron (CronCreate, ScheduleWakeup, /loop) loses the job if it fires more than 30 minutes after the thread goes idle. The crons live only inside the Claude CLI process, and ProviderSessionManager.releaseIfStillIdle closes that process after the 30-minute idle timeout, because ClaudeAdapterV2's hasPendingBackgroundWork never counts pending crons. The job never runs, and CronList is empty after the next resume.

Repro on main 8d3b061121 (web dev server, Claude Sonnet 5.5): at 11:43 UTC ask Claude to CronCreate a one-shot job for 12:20 that appends date -u to a file. CronList shows 4e805017 … (one-shot) [session-only], next run 12:20. Leave the thread idle. The provider session went to stopped at 12:13:33 and the CLI exited. The file was never written. A control cron set inside the idle window (11:54) fired and rendered in its thread, so firing works whenever the process is still alive.

Change

• ClaudeAdapterV2 registers an SDK Stop hook. The SDK reports a session's pending crons only through StopHookInput.session_crons. The hook stores that snapshot's length per native thread and returns { continue: true }, so Claude's behaviour and any user Stop hooks from settings are unaffected.
• While any count is above zero, the session runtime's hasPendingBackgroundWork returns true. ProviderSessionManager then defers the idle release the same way it does for background tasks, under its existing maxIdlePinMs cap. Each Stop overwrites the snapshot, so a fired one-shot or a deleted cron drops out at the next Stop.
• The count is cleared only when the CLI process ends or is replaced: in resetBackgroundTaskStateForNativeThreadProcess, and at the top of finalizeActiveTurnAfterQueryExit (interrupt, close, transport error). A result-driven failed turn, such as a usage limit or a 529, keeps the CLI and its crons alive, so it leaves the count alone.
• No other change: per-thread Working/settled state still uses hasPendingBackgroundWorkForThread, which is unchanged. No new setting, contract field or persisted state.

Limits that remain:

• The existing 4-hour maxIdlePinMs cap still applies, so a one-shot set more than about 4 hours ahead with no activity in between is still released.
• A recurring cron that fires resets that budget, so a /loop keeps its CLI alive while it keeps firing.
• Replacing the process (a model or permission-policy change on the next turn) still drops the crons, because they die with the CLI.
• If the turn a one-shot cron fires ends in a failed result, no Stop snapshot follows, so the spent cron keeps the session pinned until the next Stop or the 4-hour cap.

Scope and approval

Fixes #13439 GitCafe: https://git.cafe/pingdotgg/t3code/issues/13439 Triaged bug via the automated issue flow. A maintainer confirmed the cause on the issue: the idle reaper, with session crons not modelled as liveness.

Verification

Focused tests in apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts, each red before its fix:

• ClaudeAdapterV2.test.ts: 210/210 passed.
• ProviderSessionManager.test.ts: 41/41 passed.
• tsc --noEmit for apps/server: clean.
• vp lint and vp fmt --check on the changed files: no new findings.

Runtime check in the real app. This is a server-only fix, so the evidence is the server transcript and the thread itself:

After: the fired turn at 1:08 PM in the scheduling thread.

after-thread.png

Not checked:

• Desktop and mobile clients. The change is in the server's Claude adapter only, so no client code is touched.
• Other providers. Session crons are a Claude CLI feature.
• The runtime check ran on 9fdecd3927. The two later commits change only when the count is cleared after an interrupt or a failed turn, which the unit tests cover.

Claude Opus 5.5 and Claude Sonnet 5.5 in T3 Code via the Claude Code harness.

🤖 Generated with Claude Code

Maintainer review and independent audit (head 7c9fae3066)

Reviews: Claude Sonnet 5.5: VERDICT: MERGE. Claude Opus 5.5: VERDICT: MERGE. Both found that a stale cron count cannot pin a session past maxIdlePinMs: the cap check in ProviderSessionManager.ts (~1133-1167) does not depend on the adapter, and a stale count emits no provider events, so the worst case is about 30 min idle + 4 h. Low-severity follow-ups, not blockers:

• A query replacement (model, mode or MCP change between turns) still closes the CLI and drops crons silently. Same on main: liveProcessRunsBackgroundWork ignores crons.
• The Stop hook writes the count without checking that its query still owns the thread. A late Stop from a closing CLI could re-set the count, which the cap then bounds.
• A failed wake turn, or a CronDelete in a turn that then fails, leaves a positive count until the cap.

The SDK Stop hook returning { continue: true } runs alongside user and plugin Stop hooks and does not override them. Neither reviewer found a semantic conflict with https://git.cafe/pingdotgg/t3code/pulls/23561 or https://git.cafe/pingdotgg/t3code/pulls/22792. Auth, permissions, modes and MCP are not touched.

Audit: VERDICT: SUFFICIENT. Real servers, before = main 8d3b061121 (the PR's merge-base), after = 7c9fae3066. Claude Sonnet 5.5, isolated synthetic --base-dir. The idle timeout is hard-coded at 30 min, so both builds ran in parallel at the real timeout.

Logs: server-before.log, server-after.log, idle spans before / after, session states, everything (redacted).

Drivers (sha256 list):

• start-rows.sh 5954f78be47373e24e24ceefcf4d388965c0c25835a58e022743c8eec9c09465
• r4.sh 5aefe4dfad63f261171f0780bb2e2c1f4dbe3b7985f773a94ebe0b0e628ceb7b
• mcp.sh 9243a937b7fe7ab3896c948f6996faeb9e252e2c9bc54b30b0afc6d9cfa48e89
• issue-mcp-token.ts a5949d598647783f4c969bfc310a637af7501406ba4b08a39422136e8996576a
• capture.sh 5112ea9bd40f62c2eebf6f521786a2cf8ba36fbbbdfc3a8cd5ab055a19684fcf
• sessions.sh 446b173e04035a42252cc1ea630cb2dae48fb611f942a29b3a9d1a08ad9ac904