[Bug]: /schedule or CronCreate jobs only live inside the Claude process not in a T3code thread#13439

Confirmed. This is still the case on main and in the reported v0.0.42 build. The ProviderSessionReaper file is unchanged since that release. The evidence in the report is a session-scoped CronCreate job (35f28405, one-shot at 00:13), not a cloud routine.

T3 does not start a new Claude process on every message. sendTurn queues into the live SDK query while that session is still open. A new process is started only after the previous one has been stopped, and that start passes the persisted session id as resume:

https://github.com/pingdotgg/t3code/blob/b2b43bef7344/apps/server/src/provider/Layers/ClaudeAdapter.ts#L4944

https://github.com/pingdotgg/t3code/blob/b2b43bef7344/apps/server/src/provider/Layers/ProviderService.ts#L1458-L1509

What stops it is the inactivity reaper. A provider session with no active turn and no tracked background work is stopped 30 minutes after the thread goes idle:

https://github.com/pingdotgg/t3code/blob/b2b43bef7344/apps/server/src/provider/Layers/ProviderSessionReaper.ts#L17-L95

stopSession closes the SDK query and the CLI is signaled. The exemption is only for work T3 already tracks as background liveness: subagent fleets, workflow runs, and Monitor / background-shell watch loops. CronCreate, CronList, and CronDelete are not modeled anywhere in the Claude adapter, so a job waiting to fire does not keep the session alive. background_tasks_changed is ignored on purpose; task lifecycle events are the source of liveness, and a cron never produces one:

https://github.com/pingdotgg/t3code/blob/b2b43bef7344/apps/server/src/provider/Layers/ClaudeAdapter.ts#L3943-L3959

Claude Code only fires these tasks while that process is running and idle, and it does not catch up a fire that passed while the process was gone (scheduled tasks). --resume restores CronCreate jobs except recurring tasks that have expired and one-shots whose time has already passed. An empty CronList at 05:14 for a 00:13 one-shot matches that rule. It does not show that resume failed to restore the job. The job could not fire because the process was already dead.

There is no server log in the report, so this night could also have been a server or desktop exit, or Stop (Stop is a hard session boundary and closes the query). If the server stayed up, the reaper makes the miss inevitable once the scheduling turn has been idle for 30 minutes. provider.session.reaped with reason: "inactivity_threshold" on that thread before 00:13 would confirm it.

Leaving the thread open is not enough. The Claude process has to still be the live session at the fire time, and T3 will have stopped it half an hour after the thread went idle.

https://github.com/pingdotgg/t3code/pull/14013 is a most minimal fix. I understand if you'd prefer something grander, like showing scheduled tasks in T3 code, or waiting for T3's own scheduling features in V2 (looking forward to it!). I implemented this so I could have this working locally. I heavily use scheduled tasks.

Another occurrence, on Windows 11, desktop 0.0.45 (stable). Since #14013 was closed without merging, this is still unfixed for anyone using session-scoped schedules.

What happened (2026-10-09/10, AEST):

• 23:35: a one-shot CronCreate job was scheduled for 01:03, to ping a second thread once its Claude usage limit reset at 01:00.
• 00:07: the scheduling thread was stopped (session.exited, reason Session stopped), 30 minutes after its last turn. The job was lost unfired, and CronList was empty after resume.
• 00:18: the target thread was also reaped, about 50 minutes after it hit the usage limit. Even if the ping had fired, there was no live session to receive it.
• The host never slept: no Kernel-Power sleep/wake events overnight, and AC standby is set to never. So this is the reaper's normal behaviour, not #11805.

Cause, confirmed in the 0.0.45 server bundle: ProviderSessionReaper uses DEFAULT_INACTIVITY_THRESHOLD_MS = 18e5 (30 min) with a 5-min sweep. It only skips threads with an activeTurnId or a non-null backgroundLiveness (agent/monitor tasks, background shells). Session crons, ScheduleWakeup//loop, and a thread waiting out a usage-limit reset don't count.

Requests:

1. Count pending session wakeups as liveness, as #14013 did via the Stop hook's session_crons, or something equivalent. Otherwise CronCreate//schedule//loop silently never fire after 30 idle minutes.
2. Make the inactivity threshold configurable (a setting, or at least an env var), so users who rely on scheduled continuations can raise or disable it.

The current workaround is to have the agent keep a background shell running until the target time, which sets backgroundLiveness. That's capped at 2 h per background command, and nobody would find it without reading the reaper source.

The latest nightlies include a T3-native scheduling mechanism, which I do prefer myself as it works in everything reliably.

I don't think #14013 is really the right fix, anyway.

I don't plan to revive it against OV2. I'd probably want native crons to show up in the T3 UI for monitoring, but I'll let the maintainers figure out the shape they want for this

Partly covered. #28104 merged as 4ac97be. Agents can now ask T3 Code for a one-time run with schedule_task and { type: "once", runAt }. That run lives in the T3 server and survives the Claude process ending. Claude's own CronCreate jobs are still lost when the process ends; #23636 tracks that fix, so this stays open.