[BUG] Usage-limit stop leaves background processes running with no warning (17 hours, about 59k API calls); $2K in unexpected charges
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
What happened: A Claude Code session started verification tests as background processes. When the session hit its usage limit, the session stopped, but the processes it had started kept running and kept calling the Bedrock API for about 17 hours, until the session resumed and ended them. There was no message about running processes at the cutoff, and no way to stop them from the session.
3_PUBLIC_Claude_Code_bug_report_2026-09-21.pdf
What Should Happen?
Expected: When the session stops at a limit, background processes it started are stopped or paused, or the user is clearly told they are still running.
Also: The test loop had no cap on turns or calls, so nothing bounded the usage.
Steps to reproduce: Start a long-running background process from a session (shell &), then reach the usage limit. The process continues while the session shows only the limit notice.
Impact: 59,235 API calls and roughly $2,000 of usage in 17 hours, 88% of it after the cutoff.
Suggestion: Stop or pause child processes at the limit, or show a banner listing them. Add a default turn or call cap for test loops.
Environment: Claude Code version 2.1.197 (Claude Code), macOS, Claude models via Amazon Bedrock.
Error Messages/Logs
Steps to Reproduce
Start a Claude Code session in a scratch directory.
1) Ask the assistant to run a harmless long-lived job through its shell tool, detached with a shell &:
( while true; do date >> /tmp/bgtest.log; sleep 5; done & )
2) Confirm the job survives the shell call: pgrep -f bgtest shows a process, and /tmp/bgtest.log keeps growing. The tool result carries no notice that anything is still running.
3)Keep working in the session until it hits its usage limit (or let it run into one).
4)After the limit stops the session, check again with pgrep -f bgtest.
5) Clean up: pkill -f bgtest; rm /tmp/bgtest.log
Observed: In steps 2–3 the job keeps running after the call returns, and no notice appears in the tool result. I have not been able to test step 4 (the usage-limit cutoff) myself.
Expected: When a session is stopped at a limit, either the processes it started are stopped, or the user is told which ones are still running.
Per FIN AI:
Steps to reproduce (paste into the form)
Start a Claude Code session in a scratch directory.
Ask the assistant to run a harmless long-lived job through its shell tool, detached with a shell &:
( while true; do date >> /tmp/bgtest.log; sleep 5; done & )
Confirm the job survives the shell call: pgrep -f bgtest shows a process, and /tmp/bgtest.log keeps growing. The tool result carries no notice that anything is still running.
Keep working in the session until it hits its usage limit (or let it run into one).
After the limit stops the session, check again with pgrep -f bgtest.
Clean up: pkill -f bgtest; rm /tmp/bgtest.log
Observed: In steps 2–3 the job keeps running after the call returns, and no notice appears in the tool result. I have not been able to test step 4 (the usage-limit cutoff) myself.
Expected: When a session is stopped at a limit, either the processes it started are stopped, or the user is told which ones are still running.
Claude Model
Other
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.197 (Claude Code)
Platform
AWS Bedrock
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Hello, we are requesting a refund of $2k due to this bug in Claude. Please advise and escalate this. Is there someone that can help advise?
PER FIN AI -
Regarding the Claude Code behavior you've described: when a Claude Code thread reaches your plan's usage limit, it's designed to wait and resume automatically when the limit resets.[[2]](https://code.claude.com/docs/en/claude-projects) However, the scenario you've documented—where background processes continued making Bedrock API calls during the waiting period—represents a gap between that intended behavior and what actually occurred in your session.