Windows: server process RAM runaway (8-12 GB private) during interactive session bootstrap - history never sent; not MCP/provider/config related

Summary

On Windows, the jcode server process (builds\shared-server\jcode.exe --provider auto serve) enters a runaway memory allocation (~200–300 MB/s, reaching RSS 8–9 GB / private ~12.6 GB) only when an interactive client connects and creates a session. The server never sends conversation history to the client (TUI shows "Still loading session… the server hasn't sent the conversation history"; log shows Remote history still not loaded after 11s/16s; re-requesting session history (attempt 1/4, session=None)), then the process dies. Headless usage never reproduces it. Not related to MCP, provider, config, or session data size.

Environment

• OS: Windows 11 (build 26200), 16 GB RAM, 4 CPUs
• jcode: v0.84.0 (57d587899), fresh install (official install.ps1)
• Terminal: Windows Terminal (also reproduced in PowerShell/cmd directly — not WSL-specific; tried from pwsh and cmd, same result)
• Machine has ~1.3 GB of Claude Code data: ~/.claude/skills (63 MB, 157+ skills), ~/.claude/projects (84 JSONL, 64 MB), ~/.claude.json (7 MCP servers)

Reproduction

1. Fresh install jcode v0.84.0 on Windows.
2. Run jcode interactively (any terminal: Windows Terminal, Hyper, pwsh, cmd).
3. "Starting server" appears, a session is auto-created.
4. Within ~1–2 min the server process balloons: RSS climbs 200–300 MB/s until ~8–9 GB RSS / 12.6 GB private, then the process exits (appears to be killed/aborts under memory pressure; client stays alive at 10–35 MB).

Meanwhile the TUI shows "Still loading session… the server hasn't sent the conversation history. This usually clears on its own; if it persists, run /restart", and the log shows the server stuck before sending history.

Measured evidence

Live process sample during a user run (Task Manager equivalent):

pid=14628  "C:\Users\rahmadhani\AppData\Local\jcode\builds\shared-server\jcode.exe" --provider auto serve
          RSS: 8560 MB → 8690 MB → 8972 MB (3 consecutive 1s samples)   Private: 12,647 MB

TUI client process stayed at 6–35 MB the whole time. The server died ~2 s after the last sample.

jcode's own runtime-memory log (~/.jcode/logs/memory/server-runtime-memory-*.jsonl) during the 12 GB state reports: live sessions: 1 message / 833 bytes, embedding model not loaded (embed_loaded=false) → the memory is runaway allocation, not held session data or embeddings.

Startup anomaly in the same run: Registry prewarm completed in 14737ms (normal is ~1–3.4 s in headless runs on the same machine).

What was ruled out (bisect performed)

So: not MCP, not provider, not external_sessions, not session-picker data. The trigger is the interactive client subscribe / session-bootstrap path on Windows.

Suspected area

The runaway happens while the server prepares the session (before send_history — history is never delivered), with skills=1050ms in send_history prep and the registry/skills prewarm taking 14.7 s. Possibly related to the full-session deserialization class in #1151 or the Windows daemon issues in #1158.

Related issues

• #1151 — session_search count-only scoring cap permits large concurrent full-session deserialization
• #1158 — Windows: orphaned server keepalive respawns the daemon forever (3,733 processes / 14.26 GB)

Happy to run more diagnostics (e.g., capture with the debug socket, or test a patched build) if useful.

Reproduce the interactive jcode client and compare it with headless jcode serve, focusing on the session-bootstrap/history path and the registry/skills prewarm mentioned in the report. Use the runtime-memory log and process measurements to locate the runaway allocation; done means the server remains stable on Windows and sends conversation history to the client.