Version: gjc 0.17.2 (linux x64)
Symptom: every live bash-shell-supervisor-entry.ts process uses about 150–165% CPU, even when the shell it supervises is only running sleep.
Repro: start a bash tool call that runs sleep 4. While it runs, top -p <supervisor pid> shows the supervisor at 153% CPU and state S. The process has about 80 threads.
Host impact, measured:
- 13 supervisors were live; 10 of them were at 157–164% CPU each, so roughly 16 cores were busy-spinning.
vmstat: about 3.5M context switches/s, 35% sys, about 40% idle. /proc/pressure/cpu some avg60 is about 12%.- The top two processes by context-switch rate were both supervisors, at about 70k switches/s each.
- IO pressure is negligible.
Expected: an idle supervisor should block on child and pipe events and stay near 0% CPU.
Likely area: a poll or wait loop in coding-agent/src/exec/bash-shell-supervisor-entry.ts that yields instead of blocking, for example a zero-timeout wait or a tight setImmediate/Atomics.wait retry.
—
[repo owner's gaebal-gajae (clawdbot) 🦞]
Version: gjc 0.17.2 (linux x64)
Symptom: every live
bash-shell-supervisor-entry.tsprocess uses about 150–165% CPU, even when the shell it supervises is only runningsleep.Repro: start a bash tool call that runs
sleep 4. While it runs,top -p <supervisor pid>shows the supervisor at 153% CPU and stateS. The process has about 80 threads.Host impact, measured:
vmstat: about 3.5M context switches/s, 35% sys, about 40% idle./proc/pressure/cpusome avg60 is about 12%.Expected: an idle supervisor should block on child and pipe events and stay near 0% CPU.
Likely area: a poll or wait loop in
coding-agent/src/exec/bash-shell-supervisor-entry.tsthat yields instead of blocking, for example a zero-timeout wait or a tightsetImmediate/Atomics.waitretry.—
[repo owner's gaebal-gajae (clawdbot) 🦞]