auto resume

---

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5454
2. https://github.com/anthropics/claude-code/issues/3138
3. https://github.com/anthropics/claude-code/issues/1478

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

---

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Some objective facts that hurt user experience:

1. There is a lack of official documentation on the correct way to resume a conversation that has hit the rate limits. Is it a slash command, or should we type a manual request to continue the work?
2. Work quality degrades after the interruption if a user manually asks to continue the work: the agent often messes up where it stopped, skips steps, and finishes the task by cutting corners as quickly as possible.
3. No official slash command exists to resume a rate‑limited conversation.
4. Sub‑agents are interrupted, and the parent agent cannot resume them. This results in wasted time and duplicated effort that must be redone from scratch.

To‑do:

• [ ] Official documentation: document the correct way to resume a rate‑limited conversation.
• [ ] Add an official slash command to resume after the rate limit is reset.
• [ ] Add an option to auto‑resume.
• [ ] Resume sub‑agents: currently, the agent model fails to resume their work after being rate limited.

To maintainers: Could this issue be given a higher priority?

+1 requesting a way to resume. Loss of context is painful

+1

This is still a very real pain point. I've put together a comprehensive proposal that consolidates this request along with the many related issues around network disconnection, session corruption, and resume gaps into a single feature design with an incremental implementation path:

#26729

It covers three layers: stream watchdog (don't hang forever), recovery snapshots (save in-flight state on disconnect), and auto-resume on reconnect — all opt-in and configurable.

Would love to hear thoughts from anyone who's been affected by this.

Need this

Built an external prototype for this: cc-resilient -- wraps the claude CLI with network monitoring, hang detection, and auto-resume on reconnect. See the full design proposal at #26729.

When Claude reaches its session limit (i.e. You've hit your limit · resets 1pm), all background sub‑agents are abruptly interrupted. I’ve noticed that when I ask it to “continue,” in prompt textbox, it restarts the entire workflow from the beginning—rebuilding the plan, relaunching every agent, and acting as if none of the previous work ever happened.

👉 For developers, the most critical missing feature right now is the ability for sub‑agents to resume exactly where they stopped. This could be done through persistent memory markers, checkpointed state, or any mechanism that preserves progress across session resets.

An automatic resume capability would be even better, so we don’t have to manually prompt the system to continue after a session timeout. The current behavior like forgetting completed steps and re‑executing everything makes long‑running agentic workflows unreliable and expensive for us, we are loosing time.

Until a native solution come out, I hacked around a solution that I thought wasn't so hard to bake into the Claude code.

NO tmx, no OS hack, just Claude code native and simple.
https://github.com/softcane/cc-session-recover

I think this fix as native feature in Claude code is not in the best interest of Anthropic income statement. For example, many regular users are currently not utilizing the weekly quota usage and that unused capacity is shared among other who is either enterprise or know how to precisely setup the loops.

Imagine this, if this become a native feature, developers would start scheduling task at 9pm and will continue until they wake up.

Slightly different angle that's been working for me, since these threads are about not losing work to the reset: instead of resuming a blocked session, I queue the next pieces of work during the day and let them run overnight once limits reset, with reports waiting in the morning. Open-sourced it here if useful: https://github.com/rohanprichard/claude-overnight (mine).

If you are using Windows, try https://github.com/kvistgaard/quotawake
And if not, it might still be worth a look -- it will be easy to port.

Since a few people here have shared their own workarounds, here's mine: claude-code-cockpit (MIT) — a statusline with the 5h/7d limit bars + reset times and git/worktree state, plus a StopFailure hook (matcher rate_limit) that waits out the reset and wakes the same session with full context, in the same worktree.

Two things I ran into building it that seem relevant here:

1. resets_at is exposed only to statusline scripts (the rate_limits field). The StopFailure payload carries just session_id, prompt_id, transcript_path, cwd, permission_mode, hook_event_name; there's no CLI command that returns limits; and ~/.claude.json holds only userRateLimitTier. So a hook has no independent source of the reset time — my statusline persists it to ~/.claude/rate-limits.json and the hook reads that. Exposing resets_at to hooks would make this whole class of workaround trivial.
2. The docs describe StopFailure as observational ("output and exit code are ignored"), but in practice exit 2 does wake the session, and the hook's stdout arrives as a system reminder. That's the only reason this works — but it's undocumented behaviour I'd rather not depend on.

Caveats so nobody wastes time: the hook is a PowerShell 7 script, so today it's Windows (porting it = rewriting one file); the statusline is required, since it's the only source of the reset time; the terminal has to stay open, because it's that session doing the waiting. I also burned myself on the obvious failure mode — with no known reset time the hook woke the session every 15 min for three hours, so it now wakes a session only when it knows a concrete resets_at.

Worth noting for anyone landing here: 2.1.234 added a native "Continue automatically at usage limit" in /config, which covers the plain case cross-platform. The plugin is still useful if you want to see the limit windows and reset times, or want the wake-up under your own control.

Should I make a new issue or is this comment sufficient?
Feature request: Auto-continue on usage limit reset for iOS/mobile web
What I want: The "Auto-continue when usage limit resets" option available on mobile (iOS app and mobile web), matching the Desktop app's Code tab behavior.
Why it matters: Users on mobile have no way to enable this convenience feature, requiring manual intervention or switching to desktop but that isn’t generally an option for me right now.
Current behavior: Option only exists in the Desktop app's Code tab session-limit card.
Expected behavior: Same checkbox/toggle available in the iOS app and mobile web interface.

I am entirely armchair vibe coding https://github.com/mixmansoundude/Python_vs_Windows
My workaround has been a watchdog routine with hourly trigger. Works ok for 5 hour window, have to disable for hitting the weekly cap because I am not sure how much it is eating up my usage to trigger every hour for half a week. However, the agent has to make it to tie it to the session, I can’t figure out how to make a session trigger routine myself (on mobile web or app), only general ones that start a new session each time. Is that another issue too or am I missing something.