Skip to content

Claude Code freezes with 100% CPU during multi-agent task JSON serialization #4580

New issue
New issue
Closed as not planned
Closed as not planned
Claude Code freezes with 100% CPU during multi-agent task JSON serialization#4580
Labels
area:toolsbugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:macosIssue specifically occurs on macOS

Description

@duquesnay
duquesnay
opened on Jul 28, 2025

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

  1. Work in a project with an extensive backlog (long .claude/backlog.md file)
  2. Use the Task tool to spawn a sub-agent (the new feature with pre-defined roles in .claude/agents/xxx)
  3. 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::Extend

Multiple 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

  1. Implement circular reference detection before serialization
  2. Add depth limits for object serialization
  3. Use a custom JSON.stringify replacer to handle edge cases
  4. 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

Activity

  1. github-actions
    added
    bugSomething isn't working
    has reproHas detailed reproduction steps
    platform:macosIssue specifically occurs on macOS
    area:tools
    memory
    on Jul 28, 2025

  2. megagon commented on Jul 28, 2025

    @megagon
    megagon
    on Jul 28, 2025

    same here

  3. janreges commented on Jul 29, 2025

    @janreges
    janreges
    on Jul 29, 2025

    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.

  4. Aroton commented on Jul 30, 2025

    @Aroton
    Aroton
    on Jul 30, 2025

    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.

  5. Aroton commented on Jul 30, 2025

    @Aroton
    Aroton
    on Jul 30, 2025

    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.

    aroto@DESKTOP-9JQOS1J:~/SmallBusinessWebsite$ sudo strace -c -p 10625
strace: Process 10625 attached
^Cstrace: Process 10625 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 88.15    1.178026        6266       188           munmap
  4.83    0.064507          12      5360           epoll_pwait
  2.38    0.031773          22      1387        21 futex
  0.72    0.009557          18       525         1 write
  0.58    0.007800          12       616           getpid
  0.55    0.007297          18       391           read
  0.48    0.006413          40       157           openat
  0.46    0.006166          23       257           close
  0.39    0.005200          36       144           mmap
  0.30    0.003987           8       458           setsockopt
  0.29    0.003820          12       303       215 access
  0.28    0.003774        1258         3           clone
  0.17    0.002332           7       309        36 statx
  0.07    0.000975         975         1           fsync
  0.06    0.000822          19        42        42 connect
  0.05    0.000719           8        85         2 epoll_ctl
  0.05    0.000606          14        42           socket
  0.04    0.000573          12        47           mprotect
  0.04    0.000528          11        47           madvise
  0.02    0.000286           6        42           getsockopt
  0.02    0.000251          15        16           rt_sigprocmask
  0.02    0.000206          22         9           ioctl
  0.01    0.000160           4        40           writev
  0.01    0.000139           6        22           io_uring_enter
  0.01    0.000103          25         4           shutdown
  0.01    0.000082           9         9           socketpair
  0.00    0.000053          10         5           rt_sigaction
  0.00    0.000048          48         1           rename
  0.00    0.000046          23         2           wait4
  0.00    0.000044          22         2           rt_sigreturn
  0.00    0.000035           7         5           pread64
  0.00    0.000027           9         3           pipe2
  0.00    0.000021          21         1         1 readlink
  0.00    0.000014          14         1           chmod
------ ----------- ----------- --------- --------- ----------------
100.00    1.336390         126     10524       318 total

    aroto@DESKTOP-9JQOS1J:~/SmallBusinessWebsite$ sudo bpftrace -e 'kprobe:down_write { @[comm] = count(); }'
Attaching 1 probe...
^C

@[systemd-timesyn]: 3
@[DnsServer]: 7
@[tokio-runtime-w]: 10
@[main2]: 57
@[kworker/u32:45]: 87
@[systemd-udevd]: 96
@[kworker/u32:42]: 134
@[(udev-worker)]: 179
@[locale-check]: 186
@[locale]: 186
@[libuv-worker]: 198
@[grep]: 239
@[init]: 282
@[uv]: 405
@[python3]: 1082
@[base64]: 1116
@[git]: 1645
@[GnsPortTracker]: 3708
@[bash]: 5883
@[claude]: 16619

  6. Aroton commented on Jul 30, 2025

    @Aroton
    Aroton
    on Jul 30, 2025

    Ok clearly something wrong with statsig

    aroto@DESKTOP-9JQOS1J:~/AroMCP$ sudo strace -p 160477  -e trace=open,openat,stat,lstat 2>&1 | head -50
strace: Process 160477 attached
openat(AT_FDCWD, "/home/aroto/.claude.json", O_RDONLY|O_CLOEXEC) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/SmallBusinessWebsite/src/app/(signup)/signup/organization/__tests__/page.test.tsx", O_RDONLY|O_CLOEXEC) = 24
openat(AT_FDCWD, "/home/aroto/SmallBusinessWebsite/src/app/(signup)/signup/organization/__tests__/page.test.tsx", O_RDONLY|O_CLOEXEC) = 24
openat(AT_FDCWD, "/home/aroto/SmallBusinessWebsite/src/app/(signup)/signup/organization/__tests__/page.test.tsx", O_RDONLY|O_CLOEXEC) = 24
openat(AT_FDCWD, "/home/aroto/SmallBusinessWebsite/src/app/(signup)/signup/organization/__tests__/page.test.tsx", O_RDONLY|O_CLOEXEC) = 24
openat(AT_FDCWD, "/home/aroto/SmallBusinessWebsite/src/app/(signup)/signup/organization/__tests__/page.test.tsx.tmp.160477.1753852103956", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 34
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 34
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 34
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 34
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 34
openat(AT_FDCWD, "/dev/null", O_RDONLY|O_CLOEXEC) = 40
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=161968, si_uid=1000, si_status=127, si_utime=0, si_stime=0} ---
openat(AT_FDCWD, "/mnt/c/Users", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 34
openat(AT_FDCWD, "/home/aroto/.claude/ide", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 34
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 24
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=161969, si_uid=1000, si_status=0, si_utime=13 /* 0.13 s */, si_stime=2 /* 0.02 s */} ---
openat(AT_FDCWD, "/home/aroto/.claude.json", O_RDONLY|O_CLOEXEC) = 38
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38
openat(AT_FDCWD, "/home/aroto/.claude/statsig/statsig.session_id.2656274335", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38

  7. Aroton commented on Jul 30, 2025

    @Aroton
    Aroton
    on Jul 30, 2025

    Ok so. I think i've disabled statsig with env variables and the issue persists. This is during a CPU spike:

    % time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 98.18    1.010657        2096       482           munmap
  0.87    0.008924          21       416           futex
  0.42    0.004315          10       413           mmap
  0.23    0.002402           7       306       204 access
  0.08    0.000784          11        69           mprotect
  0.07    0.000736           7       102           statx
  0.07    0.000727          10        69           madvise
  0.06    0.000653           9        69           getpid
  0.02    0.000175          10        17           write
------ ----------- ----------- --------- --------- ----------------
100.00    1.029373         529      1943       204 total

    Looks like its doing some memory thrashing:

    aroto@DESKTOP-9JQOS1J:~/AroMCP$ sudo strace -p $CLAUDE_PID -e trace=mmap -v 2>&1 | grep -E "MAP_ANON|MAP_PRIVATE" | head -10
mmap(0x3322b1300000, 270086144, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3322b1300000
mmap(NULL, 404729856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b4fe05000
mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x70830cffd000
mmap(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b63fff000
mmap(NULL, 134221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b5bffe000
mmap(NULL, 268439552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b4bffd000
mmap(NULL, 536875008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b2bffc000
mmap(0x3ed369f80000, 272736256, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3ed369f80000
mmap(NULL, 408711168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x707b4fa39000
mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x70830cffd000

    Watching the RES memory in HTOP it constantly goes to 1gig of memory down to 278M, on repeat at 100% cpu

  8. Aroton commented on Jul 30, 2025

    @Aroton
    Aroton
    on Jul 30, 2025

    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:

    export MALLOC_MMAP_THRESHOLD_=268435456  # Don't mmap until 256MB
export NODE_OPTIONS="--max-old-space-size=8192 --max-semi-space-size=512"
export V8_FLAGS="--thin-strings --lazy"

    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.

     87.64    0.406046       10685        38           munmap

    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.

    aroto@DESKTOP-9JQOS1J:~/AroMCP$ sudo strace -c -p $CLAUDE_PID
strace: Process 170944 attached
^Cstrace: Process 170944 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 38.59    0.033858           9      3612           epoll_pwait
 27.19    0.023857          38       619        15 futex
 16.48    0.014457         262        55           munmap
  4.25    0.003728          17       219         1 write
  3.07    0.002692          10       269           read
  3.01    0.002640          12       216       123 access
  2.19    0.001926          10       176           statx
  2.04    0.001789        1789         1           writev
  0.75    0.000662           8        74           getpid
  0.52    0.000457          16        28           mmap
  0.36    0.000316          11        28           mprotect
  0.35    0.000305          10        28           madvise
  0.31    0.000276          13        21           openat
  0.29    0.000256          11        22           close
  0.14    0.000127           5        22           setsockopt
  0.13    0.000112          11        10           pread64
  0.10    0.000086          43         2           fsync
  0.08    0.000068          34         2           rename
  0.07    0.000063           5        12           io_uring_enter
  0.04    0.000031          15         2           chmod
  0.02    0.000021          10         2         2 readlink
  0.01    0.000008           4         2           getsockopt
  0.01    0.000006           3         2         2 connect
  0.00    0.000004           4         1           epoll_ctl
  0.00    0.000000           0         2           socket
------ ----------- ----------- --------- --------- ----------------
100.00    0.087745          16      5427       143 total

    export MALLOC_TRIM_THRESHOLD_=-1
export MALLOC_MMAP_THRESHOLD_=134217728
export MALLOC_ARENA_MAX=4
export NODE_OPTIONS="--max-old-space-size=4096"

  9. duquesnay commented on Jul 30, 2025

    @duquesnay
    duquesnay
    on Jul 30, 2025
    Author

    @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

  10. KrustyHack commented on Jul 30, 2025

    @KrustyHack
    KrustyHack
    on Jul 30, 2025

    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.

    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 -9 it.

    At first I tought it was my CLAUDE.md file to heavy (5k lines) but even with lightweight CLAUDE.md file the problem subsist.

  11. toddsundsted commented on Jul 30, 2025

    @toddsundsted
    toddsundsted
    on Jul 30, 2025

    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:

    <--- Last few GCs --->

[122267:0xffff7ece0000]   605769 ms: Mark-Compact 4012.3 (4113.8) -> 3995.9 (4098.1) MB, pooled: 0 MB, 917.29 / 0.03 ms  (average mu = 0.093, current mu = 0.035) allocation failure; scavenge might not succeed
[122267:0xffff7ece0000]   606786 ms: Mark-Compact 4012.6 (4114.3) -> 3996.2 (4098.3) MB, pooled: 0 MB, 987.02 / 0.03 ms  (average mu = 0.061, current mu = 0.029) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

Aborted

  12. 17 remaining items

  13. fullofcaffeine commented on Aug 30, 2025

    @fullofcaffeine
    fullofcaffeine
    on Aug 30, 2025

    +1 claude code CLI has been almost unusable, mac M2.

  14. damianmikla commented on Sep 11, 2025

    @damianmikla
    damianmikla
    on Sep 11, 2025

    +1

  15. shreefentsar commented on Sep 28, 2025

    @shreefentsar
    shreefentsar
    on Sep 28, 2025

    same error with multi agents

  16. Srules commented on Oct 1, 2025

    @Srules
    Srules
    on Oct 1, 2025

    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-code and 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.

  17. github-actions commented on Dec 6, 2025

    @github-actions
    github-actionsBot
    on Dec 6, 2025 – with GitHub Actions

    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.

  18. github-actions
    added
    autocloseIssue will be closed automatically
    on Dec 6, 2025

  19. rmonsurate commented on Dec 18, 2025

    @rmonsurate
    rmonsurate
    on Dec 18, 2025

    same issue

  20. github-actions
    removed
    autocloseIssue will be closed automatically
    on Dec 18, 2025

  21. github-actions commented on Jan 18, 2026

    @github-actions
    github-actionsBot
    on Jan 18, 2026 – with GitHub Actions

    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.

  22. github-actions
    closed this as not plannedon Jan 18, 2026

  23. marcindulak commented on Jan 18, 2026

    @marcindulak
    marcindulak
    on Jan 18, 2026

    This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at #16497. Please upvote that issue, so maybe it gets noticed.

  24. shoelessrob commented on Jan 18, 2026

    @shoelessrob
    shoelessrob
    on Jan 18, 2026

    Still experiencing this issue in v2.1.12 on macOS 26.3 (Apple Silicon).

    Symptoms:

    • Explore subagent task ("Analyze V2 Ruler data sources") became completely unresponsive
    • 100% CPU sustained for 20+ minutes
    • Session frozen — no keyboard input accepted
    • Ctrl+C and Ctrl+\ had no effect
    • Had to kill -9 the process from another terminal

    Process diagnostics:

    • Memory: 3.6GB (peak 3.9GB)
    • sample showed main thread stuck in tight loop (JS engine churning)

    UI state when frozen:

    Explore(Analyze V2 Ruler data sources)
  Waiting...-lh /Users/.../cloudformation_script/re...
  +5 more tool uses (ctrl+o to expand)
· Fiddle-faddling... (ctrl+c to interrupt · 45s · ↓ 2.1k tokens)

    The status bar showed -- INSERT -- ‖ plan mode on but input was completely blocked.

    This appears to be the same root cause — subagent/Task tool causing infinite loop with no way to interrupt.

  25. jmhunter83 commented on Jan 19, 2026

    @jmhunter83
    jmhunter83
    on Jan 19, 2026

    Confirming this issue - v2.1.12, macOS Sequoia

    Environment

    • Claude Code: 2.1.12
    • OS: macOS 26.2 (Darwin 25.2.0, Sequoia)
    • Hardware: MacBook Pro 14" M1 Pro

    Symptoms

    • Process hung at 98.9% CPU, 3.7GB memory (peak 4.0GB)
    • Main thread 100% active for 25+ minutes
    • Process completely unresponsive (required kill -9)
    • Active session file grew to 78.6MB

    Diagnostic Data

    CPU Sample (via sample <pid> 1):

    • 806/806 samples in main thread spinning
    • Thread labels show Bun runtime: "Bun Pool", "JavaScriptCore libpas scavenger"
    • All JS stack frames show as ??? (JIT code, no symbols)

    Process state:

    STAT      TIME ELAPSED
R+    10:35.84   25:21

    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

    1. Use Claude Code extensively in a project over multiple sessions
    2. Allow session files to accumulate (especially if using multi-agent Task tool)
    3. Session files grow past ~40-50MB threshold
    4. Process hangs during JSON serialization/parsing of large context

    Workaround Applied

    # Identify and remove bloated session files
find ~/.claude/projects/<project-path>/ -name "*.jsonl" -size +20M -delete

    This reduced the session directory from 867MB to 187MB and restored normal operation.

    Suggestion

    Consider:

    1. Session file size limits with automatic rotation/compaction
    2. Streaming JSON handling for large contexts
    3. Warning when session files exceed a threshold (e.g., 30MB)

  26. github-actions commented on Jan 26, 2026

    @github-actions
    github-actionsBot
    on Jan 26, 2026 – with GitHub Actions

    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.

  27. github-actions
    locked as resolved and limited conversation to collaborators on Jan 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:toolsbugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions