Claude Code freezes with 100% CPU during multi-agent task JSON serialization
Description
Claude Code CLI becomes unresponsive with 100% CPU usage when using the Task tool to spawn sub-agents. The freeze occurs during JSON serialization of the response object, likely when processing large/complex data from a project with an extensive backlog.
To be clear: this is the new agents introduced in 1.0.60
Environment
- OS: macOS 15.5 (24F74)
- Claude Code: v1.0.61
- Node Version: v20.19.1
- Working Directory: Single MCP server project with large backlog file
Steps to Reproduce
- Work in a project with an extensive backlog (long .claude/backlog.md file)
- Use the Task tool to spawn a sub-agent (the new feature with pre-defined roles in .claude/agents/xxx)
- Process freezes during response serialization
Expected Behavior
Task tool sub-agent spawning should complete and return results without freezing.
Actual Behavior
- Process uses 100%+ CPU indefinitely
- Session becomes unresponsive
- Must force kill process (PID)
Technical Details
Process sampling reveals the freeze occurs in V8's JSON serialization:
v8::internal::JsonStringifier::Serialize_<false> (2000+ recursive calls)
v8::internal::JsonStringifier::SerializeArrayLikeSlow
v8::internal::IncrementalStringBuilder::ExtendMultiple garbage collection cycles are triggered, indicating memory pressure from expanding strings.
Root Cause
The issue appears to be caused by attempting to serialize an object containing project context (likely including the large backlog file) with:
- Circular references in the context data
- Extremely deep nesting in project metadata
- Large backlog/project data being included in serialization
Suggested Fix
- Implement circular reference detection before serialization
- Add depth limits for object serialization
- Use a custom JSON.stringify replacer to handle edge cases
- Add timeouts for serialization operations
Impact
This bug makes the Task tool unusable for sub-agent spawning, particularly in projects with large context files.
Additional Information
- Reproducible across multiple attempts
- Specifically affects projects with large .claude/backlog.md files
- No error messages logged before freeze
- Process working directory:
/Users/guillaume/dev/tools/mcp/obsidian-mcp-resources - Full process sample and stack trace available if needed
---
Labels to add: bug, performance, multi-agent
38 Comments
same here
In my case, the same with version 1.0.62. After a few minutes of parallel work of several subagents, the CPU is 100% (single-core with claude process) and it is practically impossible to stop CC in any way other than by killing the process.
I'm seeing this too. I'm on wsl2/ubuntu. I actually started seeing this with the task tool a couple releases ago. I used to be able to run 10x tasks in parallel and merge back in now issues. Now after 2-3 sub agent tasks in serial, my timers even lag out, and I can't type anything into the input box.
I am on node 22 and recently cleared out all claude config files and reinstalled claude fresh.
Did a little bit more digging. And this seems to be munmap related. I do have 2 instances of claude running. And it seems like its getting a ton of write locks relative to everything else.
Ok clearly something wrong with statsig
Ok so. I think i've disabled statsig with env variables and the issue persists. This is during a CPU spike:
Looks like its doing some memory thrashing:
Watching the RES memory in HTOP it constantly goes to 1gig of memory down to 278M, on repeat at 100% cpu
Edit 2:
Alright, I asked claude to optimize memory settings based on large JSON files and it seems to be working very well. Claude Code is running significantly faster than it was and i'm not seeing the memory thrashing anymore. The downside is it's using more memory overall (quite a bit more).
Here are the settings:
EDIT:
It did not fix it. It may have something to do with having 2 claude instances going at the same time. I'll test more tomorrow. But now my munmaps are ungodly slow.
-----
Ok. I may have found a workaround to the memory issue. Basically, tweak the memory stack settings with env variables. Nowall my munmaps are executing much faster.
@Aroton interesting result. I know mine happened when I used a sub agent to coordinate the work, so I guess that works as the 2 agents situation. The first analysis from Claude suspected about a loop between the main agent monitoring the sub agent output... which would trigger more output somehow, so an infinite loop of increasing output (my words and general idea). It got slightly better when asking the coordinator agent to provide shortened output, but not for long.
I finally removed my coordinator agent and it doesn't happen anymore. The main agent coordinates directly the other sub agents (developer, architect, etc) and I didn't have a freeze. I'm not too sure what I'm doing right to circumvent the previous bug to be honest
I'm in a similar situation at the moment. I ask Claude Code to develop something with the help of various sub-agents (fullstack, designer, git-commiter, etc.) and after a some time, nothing more happen, it seems Claude Code is stuck. I have to
kill -9it.At first I tought it was my CLAUDE.md file to heavy (5k lines) but even with lightweight CLAUDE.md file the problem subsist.
I don't think this adds much to the thread, but I encounter the same problem running an alpine linux VM with orbstack on OSX. I am using node v22.15.1. The subagent starts working on the problem and never stops (before using a subagent on the task it might take ~5 seconds to do the work). As soon as I hit escape to terminate the work, the orbstack helper shoots up to 100% and the VM becomes unresponsive. Eventually it terminates with the output:
Thanks guys... yes I just narrowed my problem down to multiple windows and subagents...
No more complete freezes with my last config! Running two instances (3GB and 1GB RAM) doing heavy TDD in sub agents without complete lockups. I'm still seeing performance degradation over time though. Starts very fast but gradually slows down - not just a memory/GC issue.
Working config:
Huge improvement from before. Max freeze is now just a few seconds during GC vs complete lockups. The gradual slowdown suggests there's more to optimize beyond JSON payload handling.
On my side, I still have problems with sub-agents, even after testing Aroton's config.
<img width="1068" height="240" alt="Image" src="https://github.com/user-attachments/assets/3c244566-81fc-4ea9-9502-674bd4b37af1" />
In my screenshot, nothing happen, only the timer is running, but no new tokens, nothing happens.
I'm not sure if it's the same root cause as others, but the problem seems the same. At least the sub-agent and Claude Code are staying in a state where it seems still running and working but nothing they happen.
And if I hit "ESC" to stop it, Claude Code froze, and I had to kill it with
kill -9.My setup :
I still have the issue too. Deleting most of my agents and my claude.md telling them what to do seems to have fixed it but I have not identified where the breaking point is.
@KrustyHack Do you use agents to call tasks? I think there are some bugs. The agents don't seem very well developed yet, and there are some strange bugs. I didn't dare to try it that way, worried it might cause an infinite loop lockup. It's better to coordinate using the main session. I coordinate with slash commands, and it works well. I've hit my 5-hour limit recently; I'll try the memory solution tomorrow, it looks feasible.
What helped me - I asked system to add prompt of sub agents to ask sub agent to not spawn another subagent.
After that I did not have any freezes/agent loops
Ay yes but it seems fixed now in the latest version 1.0.64. I updated Claude Code and now I don't have any more bug.
@megagon Make me thinking of "Yo dawg, I heard you like sub-agents in your sub-agents, so I asked the system to add a prompt to your sub-agents to ask your sub-agents not to spawn another sub-agent, so your sub-agents can tell your sub-agents not to create sub-agents while your sub-agents are preventing sub-agents from making more sub-agents!" :p
So has this problem been resolved with version 1.0.64 for you guys? For me it’s a bit better but still very very slow. Also I notice with 1.0.60 with top, Claude was slowing maxing out 1 CPU core at 100%, but now it’s split with a claude process and a node process.
1.0.64 absolutely NOT SOLVED for nested subagents freezing claude.
Early testing of 1.0.65 seems good so far, it seems like a hack -- the Task() tool in subagents returns a 'bash command not found' despite not being a bash() command. Whatever, so far no hangs.
I'm getting constant but unpredictable freezing of the UI. It's rendered claude effectively unusable for me.
I feel Ike 1.0.65 has fixed the problem for me
Still happening with 1.0.68 for me.
just updated to 1.0.69 this morning and I suddenly started encountering this problem. Claude writes out its todos then stops. I prompted it to continue which it very briefly before stopping again.
edit: downgrading to 1.0.53 (the point from which I updated) got things working again
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Bump, had this happen 3x today. Super annoying
The exports at the end of https://github.com/anthropics/claude-code/issues/4580#issuecomment-3134954202 seem to help for my environment
Even just Claude testing an agent TodoWrite tool instantly freezes UI (looks exactly like on the screenshot below) and after several minutes of high CPU usage and growing memory usage (in my case ~25GB for Claude process) it's automatically killed and FATAL ERROR is displayed. (Claude v. 1.0.88)
<img width="1252" height="725" alt="Image" src="https://github.com/user-attachments/assets/dc591c49-07ec-4ff7-bedf-11ae9d4f43d2" />
+1 claude code CLI has been almost unusable, mac M2.
+1
same error with multi agents
I've experienced this issue on Mac for a long time with even a single session. My issue has been resolved so far after uninstalling:
npm uninstall -g @anthropic-ai/claude-codeand reinstall via the recommended method currently for Mac:curl -fsSL https://claude.ai/install.sh | bash. If you also installed via npm, this may help.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.
same issue
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at https://github.com/anthropics/claude-code/issues/16497. Please upvote that issue, so maybe it gets noticed.
Still experiencing this issue in v2.1.12 on macOS 26.3 (Apple Silicon).
Symptoms:
kill -9the process from another terminalProcess diagnostics:
sampleshowed main thread stuck in tight loop (JS engine churning)UI state when frozen:
The status bar showed
-- INSERT -- ‖ plan mode onbut input was completely blocked.This appears to be the same root cause — subagent/Task tool causing infinite loop with no way to interrupt.
Confirming this issue - v2.1.12, macOS Sequoia
Environment
Symptoms
kill -9)Diagnostic Data
CPU Sample (via
sample <pid> 1):???(JIT code, no symbols)Process state:
Session file trigger:
The project (a Swift iOS app) had accumulated 16 session files over 20MB each, with the active session reaching 78.6MB. Total session directory was 867MB.
Reproduction
Workaround Applied
This reduced the session directory from 867MB to 187MB and restored normal operation.
Suggestion
Consider:
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.