Version
@pandacss/mcp@1.11.1
Platform: macOS 26.5 (Darwin arm64), Node.js 24.12.0
Description
When panda mcp is launched as a Claude Code MCP server, the process eventually hits an uncaught exception and enters a tight infinite CPU-spinning loop. It never exits and must be killed manually. The process also persists as an orphan after the parent Claude Code session ends (parent becomes PID 1), continuing to burn ~100% CPU until manually killed.
We had 4 simultaneous instances pegged at ~100% CPU each across different worktrees — the oldest had been running for 1h 22min, consuming 79 minutes of CPU time.
Call stack (from macOS sample)
uv__run_check → CheckImmediate → TriggerUncaughtException
→ InspectorConsoleCall (console.log/error inside the error handler)
→ v8::Function::Call → Invoke → TriggerUncaughtException
→ InspectorConsoleCall → ... (tight infinite loop)
The error handler calls console.log/console.error, which triggers further JS execution that re-throws, recursively looping forever. The Node.js event loop never blocks — it spins uv__run_check continuously at 100% CPU.
Steps to reproduce
- Configure
panda mcp as a Claude Code MCP server via .mcp.json:
{ "mcpServers": { "panda": { "command": "npx", "args": ["panda", "mcp"] } } }
- Open a Claude Code session in a workspace using that config.
- After some time (or on any unhandled error inside the MCP server),
panda mcp pegs at 100% CPU.
- Close the Claude Code session — the process is not killed, it becomes orphaned and keeps spinning.
Expected behavior
The MCP server should catch unhandled exceptions, log them, and exit with a non-zero code rather than looping infinitely.
Suggested fix
Add a top-level uncaught exception guard in the MCP server entry point:
process.on('uncaughtException', (err) => {
console.error('[panda mcp] uncaught exception, exiting:', err)
process.exit(1)
})
process.on('unhandledRejection', (reason) => {
console.error('[panda mcp] unhandled rejection, exiting:', reason)
process.exit(1)
})
This prevents the recursive re-entry into the error handler that causes the spin loop, and ensures the process exits cleanly so the MCP host can restart it if needed.
Version
@pandacss/mcp@1.11.1Platform: macOS 26.5 (Darwin arm64), Node.js 24.12.0
Description
When
panda mcpis launched as a Claude Code MCP server, the process eventually hits an uncaught exception and enters a tight infinite CPU-spinning loop. It never exits and must be killed manually. The process also persists as an orphan after the parent Claude Code session ends (parent becomes PID 1), continuing to burn ~100% CPU until manually killed.We had 4 simultaneous instances pegged at ~100% CPU each across different worktrees — the oldest had been running for 1h 22min, consuming 79 minutes of CPU time.
Call stack (from macOS
sample)The error handler calls
console.log/console.error, which triggers further JS execution that re-throws, recursively looping forever. The Node.js event loop never blocks — it spinsuv__run_checkcontinuously at 100% CPU.Steps to reproduce
panda mcpas a Claude Code MCP server via.mcp.json:{ "mcpServers": { "panda": { "command": "npx", "args": ["panda", "mcp"] } } }panda mcppegs at 100% CPU.Expected behavior
The MCP server should catch unhandled exceptions, log them, and exit with a non-zero code rather than looping infinitely.
Suggested fix
Add a top-level uncaught exception guard in the MCP server entry point:
This prevents the recursive re-entry into the error handler that causes the spin loop, and ensures the process exits cleanly so the MCP host can restart it if needed.