[BUG] Scheduled-task session clock reads stale "now" after multi-day permission-approval wait, causing skills' elapsed-time caps to fire immediately

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Not a duplicate of
#47899 — zombie scheduled tasks that dispatch but never execute. Different: in this bug the task does execute; the failure is that its in-session notion of "now" is badly stale.
#51173 — stale filesystem mount in Cowork scheduled tasks. Different: #51173 is about the sandbox seeing frozen file contents. This bug is about the session's own clock/elapsed tracking being wrong by days when the session spent time in a permission-approval queue between cron spawn and first tool call.
Same subsystem family (Windows + Cowork + scheduled tasks), distinct root cause, needs its own fix.

Summary
A scheduled task dispatched Friday evening via cron was held in the permission-approval queue over the weekend and finally ran Monday morning. When the session's skill attempted an elapsed-time calculation (15-minute hard cap on work duration), the "start" timestamp captured at session spawn was ~3 days earlier than the "now" timestamp from the first real tool call. The cap fired immediately on the first tool call, causing the skill to truncate all meaningful work before doing any of it.

The skill is now defensively coded against this by deferring start_time capture until after the first successful tool call, but the underlying platform behavior — scheduled-task session spawns can be separated from first-turn execution by days, with no clock adjustment in between — will bite any skill that reads "now" against spawn time.

Symptoms
Scheduled task with cronExpression: "2,17,32,47 " (Art Queue dashboard refresh, every 15 min) fires on schedule Friday night.
No work happens until Monday morning (approval queue).
When work finally begins, the skill's first tool call's elapsed-time check against the session-start timestamp returns ~72 hours.
Skill's 15-minute hard cap fires on the first tool call; remaining work is truncated before it starts.
Resulting dashboard HTML is a degraded partial render, written with "Session clock advanced from 2026-04-17 to 2026-04-20" in the operator-visible notes bucket.

What we think is happening
Two possibilities, not yet distinguished:

Session wall-clock actually jumped. The session process was spawned Friday, paused on permission-prompt input, and the OS wall clock genuinely did advance 3 days while the process slept. Any Get-Date / date -u call at first-tool-call time returns Monday. If anything in the session captured "now" at spawn time, it's stale by the wall-clock delta. This matches the observed symptom.
Scheduler delivered a "fire time" that didn't match real time. The task's fireAt metadata said Friday, and something downstream compared fireAt to real now and surfaced the delta. Less likely given our symptom format, but possible.

What Should Happen?

Either way, the product behavior users should expect — "scheduled task fires when scheduled, runs promptly" — is not what happens in practice when the session needs permission prompts it can't get approval for until the user next interacts with Cowork.

Error Messages/Logs

Symptoms
Scheduled task with cronExpression: "2,17,32,47 * * * *" (Art Queue dashboard refresh, every 15 min) fires on schedule Friday night.
No work happens until Monday morning (approval queue).
When work finally begins, the skill's first tool call's elapsed-time check against the session-start timestamp returns ~72 hours.
Skill's 15-minute hard cap fires on the first tool call; remaining work is truncated before it starts.
Resulting dashboard HTML is a degraded partial render, written with "Session clock advanced from 2026-04-17 to 2026-04-20" in the operator-visible notes bucket.

What we think is happening
Two possibilities, not yet distinguished:

Session wall-clock actually jumped. The session process was spawned Friday, paused on permission-prompt input, and the OS wall clock genuinely did advance 3 days while the process slept. Any Get-Date / date -u call at first-tool-call time returns Monday. If anything in the session captured "now" at spawn time, it's stale by the wall-clock delta. This matches the observed symptom.
Scheduler delivered a "fire time" that didn't match real time. The task's fireAt metadata said Friday, and something downstream compared fireAt to real now and surfaced the delta. Less likely given our symptom format, but possible.

Steps to Reproduce

Symptoms
Scheduled task with cronExpression: "2,17,32,47 " (Art Queue dashboard refresh, every 15 min) fires on schedule Friday night.
No work happens until Monday morning (approval queue).
When work finally begins, the skill's first tool call's elapsed-time check against the session-start timestamp returns ~72 hours.
Skill's 15-minute hard cap fires on the first tool call; remaining work is truncated before it starts.
Resulting dashboard HTML is a degraded partial render, written with "Session clock advanced from 2026-04-17 to 2026-04-20" in the operator-visible notes bucket.

What we think is happening
Two possibilities, not yet distinguished:

Session wall-clock actually jumped. The session process was spawned Friday, paused on permission-prompt input, and the OS wall clock genuinely did advance 3 days while the process slept. Any Get-Date / date -u call at first-tool-call time returns Monday. If anything in the session captured "now" at spawn time, it's stale by the wall-clock delta. This matches the observed symptom.
Scheduler delivered a "fire time" that didn't match real time. The task's fireAt metadata said Friday, and something downstream compared fireAt to real now and surfaced the delta. Less likely given our symptom format, but possible.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 1.3109.0 (35cbf6)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

What would help most
Confirmation that scheduled-task sessions can indeed sit in the approval queue across wall-clock days, or clarification of the actual mechanism if this framing is wrong.
A platform convention for "session-effective start time" distinct from "session-spawn time," documented so skills can rely on it.
Longer term: dispatch-side behavior that either delays spawn until approvals are ready, or cancels long-queued spawns and re-fires fresh on the next cron tick.