Plan mode and session limits
Bug Description
Title: Stop/save request is queued behind a running subagent, and all planning work is lost when the 5-hour limit hits
Summary
During a long planning task that used a subagent, I asked Claude to stop and write its findings so far to a partial file, because I was at 92% of my 5-hour usage limit. Claude agreed, but never wrote the file, because it was waiting for the planning subagent to finish. The limit ran out first. All the planning work was lost, and the usage spent on it was wasted.
Steps to reproduce
Start a long planning task in Claude Code that launches a subagent.
While the subagent is running and usage is near the 5-hour limit, type a message asking Claude to stop and save progress to a file.
Claude replies that it will create the file.
The usage limit is reached before the subagent returns.
Expected behavior
A stop/save request should be able to interrupt or checkpoint a running subagent.
Claude should not agree to "create the file" when it cannot act until the subagent returns. It should tell the user to press Esc instead.
Some usage should be reserved so a session can write a final checkpoint before a hard cutoff.
Actual behavior
The message was queued. Claude said it would save, but couldn't. The subagent's findings existed only in its own context and were discarded when the limit hit. Nothing was written to disk.
Impact
Hours of planning work and a full 5-hour usage window were lost. I couldn't continue on another machine as intended. Long tasks with subagents are risky near the limit, and nothing in the UI warns about this.
Suggested fixes
Let subagents save partial results incrementally, or return them when interrupted or cut off.
Show clearly when a user message is queued behind a running subagent.
Add a built-in "checkpoint/handoff" action that works even near the limit, or reserve a small buffer for it.
Warn before launching a subagent when usage is high.
Environment
Claude Code version: [run claude --version]
OS: [Windows / macOS / Linux]
Plan: [Pro / Max]Title: Stop/save request is queued behind a running subagent, and all planning work is lost when the 5-hour limit hits
Summary
During a long planning task that used a subagent, I asked Claude to stop and write its findings so far to a partial file, because I was at 92% of my 5-hour usage limit. Claude agreed, but never wrote the file, because it was waiting for the planning subagent to finish. The limit ran out first. All the planning work was lost, and the usage spent on it was wasted.
Steps to reproduce
Start a long planning task in Claude Code that launches a subagent.
While the subagent is running and usage is near the 5-hour limit, type a message asking Claude to stop and save progress to a file.
Claude replies that it will create the file.
The usage limit is reached before the subagent returns.
Expected behavior
A stop/save request should be able to interrupt or checkpoint a running subagent.
Claude should not agree to "create the file" when it cannot act until the subagent returns. It should tell the user to press Esc instead.
Some usage should be reserved so a session can write a final checkpoint before a hard cutoff.
Actual behavior
The message was queued. Claude said it would save, but couldn't. The subagent's findings existed only in its own context and were discarded when the limit hit. Nothing was written to disk.
Impact
Hours of planning work and a full 5-hour usage window were lost. I couldn't continue on another machine as intended. Long tasks with subagents are risky near the limit, and nothing in the UI warns about this.
Suggested fixes
Let subagents save partial results incrementally, or return them when interrupted or cut off.
Show clearly when a user message is queued behind a running subagent.
Add a built-in "checkpoint/handoff" action that works even near the limit, or reserve a small buffer for it.
Warn before launching a subagent when usage is high.
Environment
Claude Code version: [run claude --version]
OS: [Windows / macOS / Linux]
Plan: [Pro / Max]
Environment Info
- Platform: win32
- Terminal: null
- Version: 2.1.272
- Feedback ID: 4e8b3165-1f69-4da1-8527-4c6656874280
Errors
[]