[BUG] Claude Code process spins at 100% CPU indefinitely when idle — libuv uv_backend_timeout() stuck at 0 (bg-pty-host, ACP stdio, post-hibernate)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The --bg-pty-host background process spins at 95–100% CPU indefinitely after a background session goes idle. The process never exits and silently burns a full CPU core until manually killed. In my case it ran undetected for 2+ days (since Saturday 10AM, discovered Monday evening).

What Should Happen?

When a background session has no activity and the PTY slave side is idle/closed, the bg-pty-host process should either exit cleanly or drop to ~0% CPU while properly blocking on kevent64 waiting for real I/O events.

Error Messages/Logs

No error messages, no crash reports, no log entries — completely silent. The only indication is Activity Monitor / `ps aux` showing ~95% CPU.

`sample` output (5 seconds) — main thread 100% stuck, never yields:

Call graph (8276/8276 samples = 100% main thread):
  start → +0xc82634 → +0xc83ac4 → +0xfd81d8 (event loop)
    → +0x685d50 (dispatcher)
      → +0x1014a94  [60% of samples — CPU spin, NO blocking syscall at leaf]
      → +0x85e344 → kevent64  [40% — correctly blocking]

Both processes in the pair show identical offsets (different ASLR base), confirming same code path.

Steps to Reproduce

1. Start a Claude Code session in a project with background mode and computer-use tools enabled
2. Have an active conversation (session reaches a point where Claude asks a question and waits for your reply)
3. Stop responding / walk away — do not close the terminal
4. Wait several hours (or until the session naturally goes idle)
5. Check Activity Monitor or run: ps aux | grep 2.1.150
6. Observe: the --bg-pty-host process is at ~95–100% CPU despite no activity

Process command line that's spinning:
/Users/<you>/.local/share/claude/versions/2.1.150 \
--bg-pty-host /tmp/cc-daemon-501/.../pty/<session-id>.sock 162 40 \
-- /Users/<you>/.local/share/claude/versions/2.1.150 \
--session-id <id> --fork-session --resume <project>/<session>.jsonl \
--allowed-tools mcp__computer-use__* --effort medium

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.150

Platform

Other

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Root cause hypothesis from disassembly:
The hot function at binary offset +0x1014081c8 is the PTY terminal data
processor (handles \r/\n, memcpy in 2–4 byte chunks). When the PTY slave
side goes idle, the master fd signals POLLHUP/EIO, causing kevent64 to
return immediately on every call. The code never detects EOF — it just
re-enters the processor loop indefinitely: kevent64 fires → read 0 bytes
→ loop back → kevent64 fires → repeat.

This is distinct from:

• #36729 (JIT code spin after MCP response — different trigger, different code path)
• #23590 (closed — context compression near 128K tokens — JIT code, not native)

The spin is in native compiled code at fixed offsets, not JIT.
Both the --bg-pty-host process AND the companion claude daemon run
process spin identically (same offsets, different ASLR base = same code).
Total CPU burned: ~200% (two processes) for 48+ hours before discovery.