Session compaction OOMs and never completes, leaving the session permanently unresumable (heap exhaustion at default ~4.3 GB cap)

Describe the bug

A session that reaches the context-compaction threshold enters an unrecoverable crash loop: session.compaction_start is emitted, compaction never completes, and the process dies with Allocation failed - JavaScript heap out of memory. Every subsequent --resume re-enters the same failing compaction and OOMs again, so the session is permanently unopenable.

The machine had ~56 GB of 67 GB RAM free at every crash. This is V8 old-space exhaustion against the default ~4.3 GB cap, not system memory pressure.

Evidence

Four consecutive --report-on-fatalerror diagnostic reports, all trigger: OOMError, event: Allocation failed - JavaScript heap out of memory:

Crash (UTC)	JS heap used/limit	old_space available	RSS	CPU consumed
11:58:49	4.06 / 4.30 GB	156,944 B	4.94 GB	590 s
12:31:50	4.03 / 4.30 GB	108,768 B	5.57 GB	964 s
12:36:26	4.15 / 4.30 GB	242,800 B	6.46 GB	466 s
12:45:32	4.01 / 4.30 GB	209,008 B	6.06 GB	602 s

workers: 0 and no child-process handles in every report — the growth is in the main isolate. RSS exceeding heap by 1–2 GB indicates significant native allocation on top. CPU consumption of 265–286% is consistent with GC thrash.

Root cause signal

The session event log contains four session.compaction_start events and no corresponding completion event for any of them. Each start aligns with a crash, and the token count increases across attempts — compaction never reclaims anything:

session.compaction_start	trigger	currentTokens
10:31:24.938	memory_pressure	125,865
10:36:07.701	memory_pressure	135,928
10:45:01.851	threshold (tokenLimit 200,000)	160,996
10:45:25.351	memory_pressure	161,730

The last two are 24 seconds apart: a threshold-triggered compaction started, did not finish, a new assistant turn started regardless, and a second compaction fired under memory pressure — then the heap was exhausted. So a failed compaction does not halt or retry-with-backoff; the turn proceeds and the conversation keeps growing, guaranteeing the next attempt is strictly larger and fails sooner.

Secondary symptom (likely not the cause)

Immediately before each OOM the log floods with:

[WARNING] [rust:session_bindings::api_session_event_stream] Session event stream lagged while flushing {"skipped":<N>}
[WARNING] [rust:session_bindings::api_session_event_stream] Session event stream lagged; recovering from the registry snapshot {"skipped":592}
[WARNING] [rust:session_bindings::api_memory_pressure] Memory pressure persists after GC - triggering emergency compaction

Worth noting: the reported skipped counts exceed the total number of events the session ever produced (592 skipped vs. 437 total events, 1.6 MB on disk, zero duplicate event IDs). So this is the event consumer starving while the main thread is blocked in the failing compaction and then re-syncing from the registry snapshot — a symptom, not the driver. The underlying session data is small; 437 events and 1.6 MB should not require 4 GB of heap to compact.

Affected version

• Copilot CLI 1.0.83
• Bundled Node v24.20.0, V8 13.6.233.17-node.53
• Linux, glibc 2.39, x86_64, 32 CPUs, 67 GB RAM
• Launched as: copilot --no-warnings --report-on-fatalerror --optimize-for-size --expose-gc (no NODE_OPTIONS set, so the default old-space limit applied)

Steps to reproduce the behavior

1. Run a long session that accumulates context toward the compaction threshold (this one reached ~161k tokens against a 200k limit, over roughly one hour, with many tool calls and large tool outputs).
2. Let automatic compaction trigger (trigger: threshold, or memory_pressure).
3. Observe the process OOM before compaction completes.
4. --resume the session. It re-enters compaction and OOMs again, reproducibly — four for four here, surviving between 3m46s and ~10 minutes each time.

I do not have a minimal reproducer; it appears to require a session large enough to trigger compaction. Happy to supply further redacted detail from the diagnostic reports on request.

Expected behavior

• Compaction should complete within a bounded memory budget, and should not require materializing the whole conversation such that a ~1.6 MB session exhausts a 4 GB heap.
• A failed compaction should surface an actionable error and stop the turn, rather than allowing the turn to proceed and the context to grow further.
• Repeated memory_pressure compaction attempts should back off instead of retrying into a guaranteed OOM.
• A session that cannot be compacted should still be openable in a degraded/read-only mode so the work is recoverable, instead of becoming permanently unloadable.

Additional context

• Raising the ceiling via NODE_OPTIONS="--max-old-space-size=12288" is a plausible workaround, but the fact that the token count grows on every attempt suggests a larger heap may only delay the failure rather than let compaction converge.
• The default heap cap may be worth revisiting for the bundled runtime: the process dies at ~4.3 GB on a host with 56 GB free.
• Diagnostic reports are written to the current working directory as report.<date>.<time>.<pid>.0.001.json. It would help to place these under the CLI state directory instead, or document them, since they land inside whatever repository the user is working in and are easy to commit accidentally.

Details deliberately redacted: session content, file paths, repository and account identifiers.

L’issue non indica alcun file sorgente o test. Inizia riproducendo il problema con --resume in una sessione di grandi dimensioni e tracciando session.compaction_start attraverso la compattazione, usando i report --report-on-fatalerror; il lavoro è completato quando il fallimento della compattazione è circoscritto e gestibile e la sessione rimane recuperabile invece di causare OOM ripetutamente.