tui: RSS grows unbounded around ~300k-token sessions, OOM-killed at ~30 GB (v2.0.18, Linux) #51620

Summary

Sessions that reach roughly 300k tokens blow up in memory: the opencode 2.x
process grows to tens of GB and gets OOM-killed. Today the kernel killed it at
~29.7 GB anon RSS (43.7 GB virtual) on a 31 GB machine. This does not seem
tied to wall-clock session length — it correlates with the session reaching
~300k tokens (many tool calls and large tool outputs). The same workflow on
1.18.x was fine; this started after updating to 2.x (currently v2.0.18).

Environment

• opencode version: v2.0.18 (single native ELF binary, ~/.opencode/bin/opencode, 203 MB)
• OS: Linux 6.8.0-142-generic x86_64
• Terminal: TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/bash
• Install/channel: latest (opencode --version -> v2.0.18)
• Active plugins: one local plugin (~/.config/opencode/plugins/rtk.ts, command rewriter); MCP servers enabled: playwright (local stdio) and huggingface (remote URL)

Reproduction

1. Work inside a single session until it accumulates roughly 300k tokens (many bash tool calls, large tool outputs, file reads/edits).
2. RSS grows from a few hundred MB into tens of GB as the session approaches that size.
3. The system starts swapping/hangs and the kernel OOM killer kills opencode.

Observed 3 times in one day; the earlier two ended in a full system freeze
(power cycle). It is not a "left it running for hours" issue: it reproduces
with active work in one growing session, around the ~300k token mark.

Expected Behavior

RSS stays bounded (or grows only modestly) as the session history grows; no
OOM kill.

Actual Behavior

Kernel log from the crash (host/user redacted):

kernel: xfce4-clipman invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=opencode,pid=2290047,uid=1000
kernel: Out of memory: Killed process 2290047 (opencode) total-vm:43678496kB, anon-rss:29699100kB, file-rss:3516kB, shmem-rss:0kB, UID:1000 pgtables:60808kB oom_score_adj:0
kernel: oom_reaper: reaped process 2290047 (opencode), now anon-rss:488kB, file-rss:852kB, shmem-rss:0kB

• ~30 GB anon RSS in the single opencode process (the RSS holder was opencode itself, not its children).
• ~/.local/share/opencode/log/opencode.log was 14.8 MB / ~74k lines, mostly INFO (permission evaluations, loop/stream lines). No memory-related error was logged before the kill.
• No heap snapshot is available (the process was OOM-killed). Previous boots show no OOM entries.

Additional Context

• Regression: the same workflow on 1.18.x did not have this problem; it appeared after updating to 2.x and happens regularly now.
• Possibly related: perf(v2): every LLM call re-reads and re-decodes the full session history (O(n) per step, O(n^2) per session) #51497 (every LLM call re-reads/re-decodes the full session history; O(n) per step / O(n^2) per session), Resumed session: RSS → 2.2GB in 33s from 25MB payload; JS heap only 569MB (rest in native Memory Tag 240) #50578 (resumed session RSS jump from a large payload), serve: RSS grows with activity and remains elevated while idle #51340 (serve: RSS grows with activity), opencode2: RSS grows ~530 MB/min during active agent turn (OOM crash) #41502 (opencode2: RSS grows ~530 MB/min during an active turn).
• Machine: 31 GiB RAM + 4 GiB swap; ~24 GiB free when idle.
• Workarounds tried: none yet. Happy to run debug flags / heap snapshot instructions for the v2 binary if provided.