TUI unconditionally uses ~6.5-7GB RSS on startup, even in a brand-new empty project (no plugins, no content)

Summary

Launching the opencode TUI (opencode with no subcommand) unconditionally allocates roughly 6.5–7 GB of RSS on startup, even in a brand-new, completely empty project directory with no PDFs, no attachments, no relevant session history, no plugins, and a normal, correctly-sized terminal. This reproduces reliably and immediately — it is not a slow leak that builds up over a long session, it's a fixed, enormous cost paid on every single launch.

This looks related to, but is distinct from, other memory-usage reports in this repo (e.g. #42263 the PDF-ingestion leak, #42216 cyclic-symlink skill traversal, #37799 "severe memory leak"). I want to flag it separately because I was able to fully rule out project/session content, plugins, and terminal-size artifacts as the cause — it reproduces with none of those factors present.

Environment

opencode version: 1.18.31 (latest)
os: Linux 6.8.0-45-generic x64 (Ubuntu 24.04)
terminal: ghostty 1.2.0 / xterm-ghostty (reproduced separately inside tmux with an explicit 120x40 pane, ruling out a terminal-size artifact)
plugins: none

Steps to reproduce

mkdir -p /tmp/oc_empty && cd /tmp/oc_empty
opencode .

Then watch RSS of the opencode process, e.g.:

watch -n0.5 'ps -o pid,rss,cmd -ax | grep -m1 "^\s*[0-9]* .* opencode \."'

What I ruled out before filing

• Project/session content: reproduces in a brand-new empty directory (mkdir empty-dir && cd $_ && opencode .) — no PDFs, no prior sessions for that directory, nothing to ingest.
• Home-directory file watching: reproduces identically whether launched from $HOME or a small empty directory elsewhere.
• Plugins: reproduces with --pure (no external plugins) at the same magnitude.
• Skill discovery / cyclic symlinks (cf. #42216): I have symlinked skill directories (~/.claude/skills/<name> -> ~/.agents/skills/<name>, 9 of them, cross-directory but not cyclic — verified with find -type l that nothing points back the other way, and no nested symlinks inside the real skill dirs). The log shows skill discovery completing normally and quickly (message="duplicate skill name" for the 9 dupes, then message="init count=19", then proceeding through watcher backend / project copy refresh / booting location services) — it is not stuck or looping, unlike the blank-TUI symptom in #42216.
• Terminal size artifact: initially tested via script -qc "opencode ..." /dev/null, which reports a degenerate 0x0 pty size (stty size → 0 0) — worth being aware of as a separate footgun for anyone scripting/automating opencode, since a naive screen-buffer allocation keyed to reported size could plausibly explain runaway memory in that scenario. But I re-tested inside tmux with an explicit, valid 120x40 pane (confirmed via tmux display-message -p "#{pane_width}x#{pane_height}") and got the same ~6.5–7 GB result, so this is not just a 0x0-pty artifact.
• Headless mode is fine: opencode serve (headless, no TUI) in the same empty directory uses only ~300 MB RSS. So this is specific to the TUI code path, not the core server/session engine.

Measured growth curve (fine-grained sampling, 0.5s interval, empty dir, tmux 120x40)

t=0.5s   70 MB
t=1.0s  207 MB
t=1.5s  318 MB
t=2.0s  343 MB
t=2.5s  480 MB
t=3.0s  617 MB
t=3.5s  694 MB
t=4.0s 1187 MB
t=4.5s 1989 MB
t=5.0s 2728 MB
t=5.5s 3478 MB
t=6.0s 4230 MB
t=6.5s 4825 MB
t=7.0s 5510 MB
t=7.5s 6204 MB
t=8.0s 6927 MB
t=8.5s 7178 MB   <- peak
t=9.0s .. t=16.5s   steady at ~7143 MB
t=17.0s .. t=20.0s  drops to ~6553 MB and holds (apparent partial GC)

So it's a steady, roughly-linear climb (~800 MB/s) for about 8 seconds, a plateau around 7.1 GB, then a partial GC settles it at ~6.55 GB — bounded, not an unbounded/infinite leak, but the absolute magnitude for an empty project with no plugins is the problem.

--log-level DEBUG --print-logs during this window shows no additional log lines beyond the normal ~27-line startup sequence (ending at message="booting location services") — whatever is allocating this much memory does so silently, with no corresponding log activity, which made it hard to pin to a specific subsystem from the log alone. A heap snapshot (opencode has a "Write heap snapshot" debug affordance per the evidence in #42263) would likely nail the exact retainer; I did not have a way to trigger one non-interactively from a script-driven session.

Expected behavior

Starting the TUI against an empty project with no plugins should use on the order of tens to a couple hundred MB (roughly matching opencode serve's ~300 MB in the same conditions), not 6-7 GB.

Actual behavior

Every TUI launch, regardless of project content, costs ~6.5-7 GB of RSS, which is a serious problem on memory-constrained machines and makes the app impractical to run alongside other applications.