Summary
On context-mode v1.0.103 (current latest), MCP server processes orphaned by closed Claude Code sessions remain alive in R (running) state and pin a CPU core each (~87–96% CPU) until manually kill -9'd. This appears to be the same root cause referenced in the resolution comment of #311:
The remaining root cause (vendored MCP SDK missing stdin end handler causing the CPU spin) is tracked separately and requires coordination with the SDK constraints from #236.
#311 is closed but this underlying CPU spin behavior is still occurring in v1.0.103.
Environment
- context-mode: 1.0.103 (npx-launched)
- Claude Code: 2.1.123
- Node: v20.18.1
- npm: 10.8.2
- OS: macOS 15.7.4 (arm64)
- Launch path:
~/.npm/_npx/<hash>/node_modules/.bin/context-mode
Symptoms
Six orphaned context-mode processes were found, oldest had been running 8 days since the originating Claude Code session was closed:
| PID |
%CPU |
Started |
Cumulative CPU time |
| 86511 |
91.0 |
Apr 23 |
4787 min (~80 h) |
| 11364 |
90.4 |
Fri |
4693 min |
| 58997 |
91.3 |
Mon |
2714 min |
| 10044 |
87.3 |
Tue |
1993 min |
| 52281 |
96.2 |
Tue |
1648 min |
| 46306 |
90.6 |
Today |
68 min |
All processes were in R state (busy-looping, not sleeping). Each had a corresponding npm exec context-mode parent that was also orphaned.
Reproduction
Not deterministic, but observed across multiple closed Claude Code sessions over ~10 days. The processes accumulate one per closed session.
Behavior on shutdown
pkill -TERM -f context-mode → no effect, processes keep spinningpkill -KILL -f context-mode → required to stop them
This matches the hypothesis that the busy loop is happening in a tight read loop on stdin without an end handler — a stuck SIGTERM handler or absence of one would explain why only SIGKILL works.
Relation to prior fixes
Suggested next step
Patch the vendored MCP SDK to register a stdin end/close listener that triggers process.exit(0) (with a short grace period to avoid the false-positive issue described in #236). Alternatively, a periodic ppid poll that also checks if stdin is still readable would catch this case.
Happy to provide more diagnostics (e.g., sample output showing the busy loop) on request.
Summary
On context-mode v1.0.103 (current latest), MCP server processes orphaned by closed Claude Code sessions remain alive in
R(running) state and pin a CPU core each (~87–96% CPU) until manuallykill -9'd. This appears to be the same root cause referenced in the resolution comment of #311:#311 is closed but this underlying CPU spin behavior is still occurring in v1.0.103.
Environment
~/.npm/_npx/<hash>/node_modules/.bin/context-modeSymptoms
Six orphaned
context-modeprocesses were found, oldest had been running 8 days since the originating Claude Code session was closed:All processes were in
Rstate (busy-looping, not sleeping). Each had a correspondingnpm exec context-modeparent that was also orphaned.Reproduction
Not deterministic, but observed across multiple closed Claude Code sessions over ~10 days. The processes accumulate one per closed session.
Behavior on shutdown
pkill -TERM -f context-mode→ no effect, processes keep spinningpkill -KILL -f context-mode→ required to stop themThis matches the hypothesis that the busy loop is happening in a tight read loop on stdin without an
endhandler — a stuck SIGTERM handler or absence of one would explain why only SIGKILL works.Relation to prior fixes
endhandler in the vendored SDK is the dual problem and apparently still presentSuggested next step
Patch the vendored MCP SDK to register a stdin
end/closelistener that triggersprocess.exit(0)(with a short grace period to avoid the false-positive issue described in #236). Alternatively, a periodic ppid poll that also checks if stdin is still readable would catch this case.Happy to provide more diagnostics (e.g.,
sampleoutput showing the busy loop) on request.