claude-code - 💡(How to fix) Fix [DOCS] Scheduled tasks docs omit `--resume`/`--continue` restoration [1 participants]

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…
GitHub stats
anthropics/claude-code#48858Fetched 2026-04-16 06:49:01
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
labeled ×3
RAW_BUFFERClick to expand / collapse

Documentation Type

Incorrect/outdated documentation

Documentation Location

https://code.claude.com/docs/en/scheduled-tasks

Section/Topic

Run prompts on a schedule — especially the "Compare scheduling options," "How scheduled tasks run," and "Limitations" sections for session-scoped /loop and reminder tasks, plus the resume docs that explain what claude --resume and claude --continue restore.

Current Documentation

The docs currently say:

"Tasks are session-scoped: they live in the current Claude Code process and are gone when you exit. For durable scheduling that survives restarts, use Routines, Desktop scheduled tasks, or GitHub Actions."

"No persistence across restarts. Restarting Claude Code clears all session-scoped tasks."

And the workflow comparison says:

"/loop ... Quick polling while a session is open. Tasks are cancelled when you exit."

What's Wrong or Missing?

Changelog v2.1.110 says:

--resume/--continue now resurrects unexpired scheduled tasks

That changes the documented behavior for session-scoped scheduled tasks. The current docs describe exit/restart as an unconditional end state, but unexpired tasks can now come back when the same session is resumed with claude --resume or claude --continue.

A. The current persistence guidance is now too absolute

The scheduled-tasks docs still say tasks are "gone when you exit" and that restarting Claude Code clears all session-scoped tasks. That no longer describes the full behavior once resume/continue can restore still-valid tasks.

B. The resume docs omit restored task state

Users reading the resume/continue docs are told that conversation history is restored, but not that unexpired scheduled tasks can also be restored when they reopen the same session.

Suggested Improvement

Update the scheduled-task and resume documentation to distinguish between starting a fresh session and resuming an existing one.

Suggested wording direction:

Session-scoped scheduled tasks are still tied to a specific session, but unexpired tasks can be restored when you reopen that session with claude --resume or claude --continue. Expired recurring tasks, already-fired one-shot tasks, and tasks from unrelated sessions are not restored.

Concrete doc updates:

  1. Replace unconditional phrases like "gone when you exit" and "Restarting Claude Code clears all session-scoped tasks" with wording that mentions resume/continue restoration.
  2. Update the scheduling comparison tables so /loop is not described as simply cancelled on exit without qualification.
  3. Add a note to the resume documentation explaining that reopening a session can also bring back that session's unexpired scheduled tasks.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:

PageContext
https://code.claude.com/docs/en/scheduled-tasksPrimary /loop documentation currently says tasks are gone when you exit and do not persist across restarts
https://code.claude.com/docs/en/common-workflows"Run Claude on a schedule" table says /loop tasks are cancelled when you exit
https://code.claude.com/docs/en/how-claude-code-worksResume section explains what --resume/--continue restore but does not mention scheduled-task restoration
https://code.claude.com/docs/en/desktop-scheduled-tasksShared scheduling comparison table says /loop is not persistent across restarts and now needs clarification

Total scope: 4 pages affected

Source: Changelog v2.1.110

Changelog entry: --resume/--continue now resurrects unexpired scheduled tasks

extent analysis

TL;DR

Update the scheduled-task and resume documentation to reflect that unexpired session-scoped tasks can be restored when a session is reopened with claude --resume or claude --continue.

Guidance

  • Review the affected pages (scheduled-tasks, common-workflows, how-claude-code-works, desktop-scheduled-tasks) and update the documentation to distinguish between starting a fresh session and resuming an existing one.
  • Replace unconditional phrases like "gone when you exit" and "Restarting Claude Code clears all session-scoped tasks" with wording that mentions resume/continue restoration.
  • Add a note to the resume documentation explaining that reopening a session can also bring back that session's unexpired scheduled tasks.
  • Update the scheduling comparison tables to qualify the cancellation of /loop tasks on exit.

Example

The suggested wording direction is:

Session-scoped scheduled tasks are still tied to a specific session, but unexpired tasks can be restored when you reopen that session with claude --resume or claude --continue.

Notes

The updates should be made to the four affected pages to ensure consistency and accuracy in the documentation.

Recommendation

Apply workaround: Update the documentation to reflect the correct behavior of session-scoped tasks and their restoration when a session is reopened. This will improve the understanding of the feature and its usage.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING