Skip to content

URL: https://mkdocs.justinsforge.com/memory/handoffs/console-instability-2026-05-03/

Handoff: Console Instability, 2026-05-03

What Justin reported

  • Console rebooted multiple times this morning
  • VS Code input felt slow / VS Code "just crashes"
  • /spawn opus 4.7 failed: BOOT FAILED, '❯' prompt never appeared. Check auth / API key.
  • Spawn output also said summary: 23 alive, 0 swept (homebase always preserved) (misleading, see below)

Root cause of the reboot loop

  • 08:23:59 CDT: kernel OOM-killed Chrome (VM size 1.46 TB mapping)
  • 08:37:12: systemd failed to unmount /mnt/storage and /mnt/workspace cleanly, forced reboot
  • Current boot: 08:40 CDT. Console is a 4 vCPU / 11 GB RAM VM, so headroom is thin.

Cleanup already done this session

Action Freed
Killed 15 of 16 stale context7-mcp procs ~1.1 GB
Killed 2 idle worker tmux Claude sessions (spawn-finding-nemo-5a63_Opus47, spawn-help-with-05c7_Opus47) ~600 MB
Kept (load-bearing) home-base_Opus47 tmux, Remotion studios on 3013/3014 (active video-edit-eval), hyperframes preview on 3003

After cleanup: avail RAM 5.3 → 6.5 GB, load 1.42 → 1.26.

Current state at handoff (09:00 CDT)

  • Auth: working. claude -p "ping" --model claude-haiku-4-5 --dangerously-skip-permissions returned "Pong. Ready to work." in <5s, rc=0. The other session's credentials-rotation theory (token rewrote at 02:03) is not currently reproducing.
  • Tmux: 1 process, 3 stale sockets. The "23 alive" claim from the other session was counting the 85 stale ~/.claude/projects/*.json session-history files, not live procs.
  • VS Code: still leaky. extensionHost PID 34522 = 1.77 GB, only 4 minutes old at time of measurement. PID 29613 = 700 MB, older. Total VS Code footprint ~3.1 GB / 11 GB.

Hypothesis on the /spawn failure

Likely a side effect of the 16 stale context7-mcp procs — MCP boot fan-out got slow enough that the spawn script's prompt-wait timeout fired before ❯ appeared. Auth was a red herring. Worth retrying /spawn now that cleanup is done; if it still fails, capture real debug: 

claude -p "boot test" --model claude-opus-4-7 --dangerously-skip-permissions --debug 2>&1 | head -50

Open items / next steps for the next bot

  1. Verify /spawn works post-cleanup — Justin did not retry yet. If it fails, run the debug command above and inspect.

  2. Bounce VS Code extension host — cheap immediate fix for the lag. Justin can do Ctrl+Shift+P → "Developer: Restart Extension Host" to kill PIDs 34522 + 29613 + the two claude extension subprocs (~2.9 GB) and respawn one fresh. Editor state survives.

  3. Investigate WHY extensionHost leaks to 1.77 GB in 4 min. Suspects:

  4. Claude Code VS Code extension (anthropic.claude-code-2.1.126)
  5. File watcher on the forge tree (very large repo)
  6. One of the other extensions (codex, json-language-features)

  7. Reproduce by bouncing ext host then watching ps -p <new-pid> -o rss --no-headers over 5 min

  8. Stale tmux sockets cleanup — /tmp/tmux-1000/ has 3 sockets but only 1 has a live server. forge/scripts/forge_tmux_socket_sweep.sh exists for this; consider running it.

  9. Long-term: Console RAM is undersized. 11 GB for the workload (VS Code + multiple Claude sessions + Remotion + Hyperframes + Docker + AutoAgent specialists) is the structural problem. Worth bumping to 16 or 24 GB on the Proxmox host (Finn) next maintenance window.

  10. The 1.46 TB Chrome VM mapping that triggered the OOM is suspicious — may be an old Chrome session with an extension leak or a bad tab. If Chrome runs again on Console, watch its VSZ.

What NOT to do

  • Don't kill the home-base_Opus47 tmux session (always-on per reboot resilience stack)
  • Don't kill the 2 Remotion studios (ports 3013/3014) — active video-edit-eval-rounds-3-4-5-pickup work
  • Don't claude login unless claude -p ping reproducibly hangs again — auth is fine right now

Reference

[Claude Code]