Memory leak suspected when remote-control is active on M1 Air 16GB (v2.1.142)

Resolved 💬 3 comments Opened May 15, 2026 by jimmyliao Closed Jun 14, 2026

Environment

  • Machine: MacBook Air M1, 16 GB RAM
  • OS: macOS 15.5 (24F74), arm64
  • Claude Code: v2.1.142 (global npm install, autoUpdates on)
  • Mitigation already in place: NODE_OPTIONS=--max-old-space-size=500 on the claude shell alias (added previously after similar symptoms)
  • Remote-control: enabled / actively used

Symptom

Over the past day, with Claude Code's remote-control feature active, the machine experiences:

  • Memory pressure climbs steadily
  • Heavy/continuous swap activity
  • Eventually the system becomes unresponsive and force-reboots (no clean shutdown)

This is reproducible across multiple sessions on the same day. Disabling/not using remote-control during similar workloads does not produce the same swap/reboot pattern (preliminary observation — will confirm with longer comparison).

Why I suspect remote-control specifically

There are several existing memory-leak reports for Claude Code on Apple Silicon, e.g.:

  • #44824 (kernel kalloc.1024 leak → WindowServer kernel panic — matches the 16 GB M1 force-reboot symptom)
  • #56960 (claude/node grows to 108 GB)
  • #17563, #22188, #23252 (RSS / heap growth since v2.1.x)

…but none of them explicitly correlate the leak to the remote-control subsystem. Remote-control has its own cluster of recent issues (#59064 sandbox hang, #59343, #59159) which suggest the daemon path can hang/accumulate state. I'm filing this as a new data point in case the remote-control daemon is contributing to the leak observed in the issues above.

Repro (rough)

  1. claude CLI session running with remote-control enabled
  2. Normal coding workload over several hours
  3. Memory pressure → swap → unresponsive → forced reboot

I don't have a minimal repro yet — happy to capture sysdiagnose, ps aux | grep claude snapshots, and vm_stat samples on the next occurrence if useful. Please advise what telemetry would be most helpful.

Ask

  1. Is the remote-control daemon a known contributor to the leaks tracked in #44824 / #56960?
  2. Is there a recommended way to disable remote-control entirely (config flag / env var) for users on 16 GB Apple Silicon while this is investigated?
  3. Any diagnostic commands you'd like collected on the next reboot event?

Thanks!

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗