[FEATURE] Allow agent to pick up where it was when interrupted

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13354
2. https://github.com/anthropics/claude-code/issues/15522
3. https://github.com/anthropics/claude-code/issues/6254

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

Found 3 possible duplicate issues: 1. [[FEATURE] Continue when the session limit reached #13354](https://github.com/anthropics/claude-code/issues/13354) 2. [[Feature Request] Auto-resume on rate limit with configurable retry behavior #15522](https://github.com/anthropics/claude-code/issues/15522) 3. auto resume #6254 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

I dont think this is a dupe of those. Those suggest auto-continue, I propose a manual /continue command, which would be helpful for situations other than usage limit reached, such as network drop.

This is especially bad if you launched a few sub agents. All the work of those sub agents gets missing and you just wasted a bunch of tokens.

This feature gap is something I run into frequently — especially on unreliable WiFi or during power cuts mid-task. I've written up a detailed proposal that builds on this idea with a concrete technical design:

#26729

It proposes recovery snapshots that capture exactly what Claude was doing at the moment of interruption (active tool calls, partial response, pending todos, file checkpoint), so that on resume, Claude has full awareness of where it left off — no manual re-explaining needed.

The proposal also covers the upstream problems (CLI hanging indefinitely, conversation corruption from orphaned tool_use blocks) that make the current --resume experience unreliable.

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.

+1. FWIW you can sort of work around this today if you route through the Workflow tool''s journal — finished agents can pick back up via resumeFromRunId for free. The bit nobody can fix from userspace is when an agent gets interrupted mid-flight — that context is just gone.

just lost 10% of my session tokens in two parallel thinking processes that got interrupted by token limit -.-

CLI version 2.1.177. The model thought for 4.5 minutes before hitting a rate limit error (HTTP 429).

Because the request terminated with an error code rather than a successful max_tokens cutoff, absolutely none of the streamed thinking reasoning was saved. Inspecting the local project session log (~/.claude/projects/.../<session-id>.jsonl) showed that the client just wrote a synthetic errormessage:

"error": "rate_limit",  
"isApiErrorMessage": true,  
"apiErrorStatus": 429,  
"content": [{"type": "text", "text": "You've hit your session limit · resets 4:30pm(Europe/Berlin)"}]

Losing nearly 5–10 minutes of wait time and session quota because the CLI doesn't flush/preserve thealready-streamed thinking tokens on an error response is incredibly frustrating. The CLI should writeany partially streamed tokens to the local log/cache even when the final HTTP request fails.

For the specific "limit hit → resets at X → resume where I left off" case, I put together an open-source tool that handles this today, on both the desktop app and the CLI.

On the desktop app it clicks the real "Continue" button via Windows UI Automation / the macOS Accessibility API as soon as the quota resets. This matters here because Claude doesn't emit a Stop event when credits run out, so a normal hook can't catch that moment — hence the UI-Automation approach. On the CLI, a Bash wrapper reads the output, recognizes the limit message, waits for the reset, and relaunches with --continue. Three modes: one click, opt-in auto-resume, or the terminal wrapper.

It's MIT, has no telemetry, opens no ports, and never spends money — it only clicks the resume buttons.

Repo: https://github.com/blackstardigitalstudio/claude-auto-continue

For the specific "limit hit → resets at X → resume where I left off" case, I put together an open-source tool that handles this today, on both the desktop app and the CLI. On the desktop app it clicks the real "Continue" button via Windows UI Automation / the macOS Accessibility API as soon as the quota resets. This matters here because Claude doesn't emit a Stop event when credits run out, so a normal hook can't catch that moment — hence the UI-Automation approach. On the CLI, a Bash wrapper reads the output, recognizes the limit message, waits for the reset, and relaunches with --continue. Three modes: one click, opt-in auto-resume, or the terminal wrapper. It's MIT, has no telemetry, opens no ports, and never spends money — it only clicks the resume buttons. Repo: https://github.com/blackstardigitalstudio/claude-auto-continue

I don't think this what this issue is about.
You're talking about resuming automatically.
This issue is about lost anthropic server side progress.
That's how I understand it, I might be wrong.

Fair point — you're right that the OP's request and the server-side token loss you described are a different problem from auto-resuming. I read the thread's broader "resume after the limit" theme and chimed in on that; apologies if it was off-target for your specific case. I'll leave it there.

Maybe another quick and easy way is to create a /continue skill command yourself, which simply invokes the prompt:
You were interrupted mid-process unintentionally. Pick up and proceed/continue the task(s) you were doing from where you left off.