Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix CronCreate session-scoped jobs never fire even when REPL is idle (2.1.111 desktop app)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Workaround

None found that fires in the current session. mcp__scheduled-tasks__create_scheduled_task works but spawns a new session instead of firing in the current one - not a substitute for in-session scheduling.

Code Example

{
  "cron": "5 20 23 4 *",
  "prompt": "ping",
  "recurring": false
}
RAW_BUFFERClick to expand / collapse

Bug

Session-scoped CronCreate jobs (default durable: false) do not fire within the active session, even when the REPL is idle.

The tool schema documents: "Jobs only fire while the REPL is idle (not mid-query)" - but empirical evidence shows jobs never fire even across long idle periods (session waiting for user, no active work, no pending tool calls).

Reproduction

  1. Open Claude Code desktop app (2.1.111 on Windows 11)
  2. Call CronCreate with a near-future one-shot:
{
  "cron": "5 20 23 4 *",
  "prompt": "ping",
  "recurring": false
}
  1. Tool returns "Session-only (not written to disk, dies when Claude exits)" - expected for durable: false
  2. Leave session idle (no prompts, no tool calls) past the scheduled time
  3. Job never fires - no output, no notification, nothing appears in the session

Expected

At the scheduled time, while REPL is idle, the scheduled prompt should fire and produce model output in the current session (per documented CronCreate behavior).

Additional observations

  • .claude/scheduled_tasks.lock is created when CronCreate is called
  • .claude/scheduled_tasks.json is never written, even with durable: true (see #40228)
  • Issue persists for ~7 days across many sessions
  • Desktop app reports "You are running the latest version" at 2.1.111 (CLI is already 2.1.114)
  • Problem affects both durable: false (this issue) and durable: true (#40228)

Environment

  • Claude Code desktop app 2.1.111
  • Windows 11
  • Model: Claude Opus 4.7 (1M context)
  • Multiple CWDs tested (gadki + programming sessions)

Related

  • #40228 - durable: true flag ignored, scheduled_tasks.json never written
  • #44128 - desktop app lifecycle blocking scheduled tasks

Workaround

None found that fires in the current session. mcp__scheduled-tasks__create_scheduled_task works but spawns a new session instead of firing in the current one - not a substitute for in-session scheduling.

extent analysis

TL;DR

The issue can be potentially resolved by investigating the desktop app's lifecycle and its impact on scheduled tasks, as hinted by the related issue #44128.

Guidance

  • Investigate the desktop app's lifecycle and how it interacts with scheduled tasks to understand why jobs are not firing even when the REPL is idle.
  • Review the related issue #44128 to see if there are any insights or potential fixes that could apply to this problem.
  • Consider testing the CronCreate functionality in a different environment or version to isolate if the issue is specific to the desktop app or Windows 11.
  • Look into the role of the .claude/scheduled_tasks.lock file and why .claude/scheduled_tasks.json is never written, even with durable: true, as this might be related to the scheduling issue.

Example

No code snippet is provided as the issue seems to be related to the desktop app's behavior and scheduling mechanism rather than a specific code problem.

Notes

The issue seems to be complex and might require a deeper understanding of the desktop app's internals and how it handles scheduled tasks. The fact that mcp__scheduled-tasks__create_scheduled_task works but spawns a new session instead of firing in the current one suggests there might be a fundamental issue with how sessions are handled.

Recommendation

Apply workaround: Investigate and potentially address the desktop app lifecycle issue as mentioned in #44128, as it seems to be a crucial factor in why scheduled tasks are not firing as expected. This is chosen because directly addressing the lifecycle issue might resolve both this problem and the related issue #44128.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#ISR setup#authentication setup#request error#file not found#serialization error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING