Repository navigation
TUI unconditionally uses ~6.5-7GB RSS on startup, even in a brand-new empty project (no plugins, no content) #49222
Description
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
$HOMEor a small empty directory elsewhere. - Plugins: reproduces with
--pure(no external plugins) at the same magnitude. - Skill discovery / cyclic symlinks (cf. [BUG] Cyclic symlinks in global skills cause blank TUI and unbounded memory growth #42216): I have symlinked skill directories (
~/.claude/skills/<name> -> ~/.agents/skills/<name>, 9 of them, cross-directory but not cyclic — verified withfind -type lthat 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, thenmessage="init count=19", then proceeding throughwatcher backend/project copy refresh/booting location services) — it is not stuck or looping, unlike the blank-TUI symptom in [BUG] Cyclic symlinks in global skills cause blank TUI and unbounded memory growth #42216. - Terminal size artifact: initially tested via
script -qc "opencode ..." /dev/null, which reports a degenerate0x0pty 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 insidetmuxwith an explicit, valid120x40pane (confirmed viatmux display-message -p "#{pane_width}x#{pane_height}") and got the same ~6.5–7 GB result, so this is not just a0x0-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.
Activity
github-actions commentedon Sep 15, 2026
This issue might be a duplicate of or a regression from existing issues. Please check:
--pureflag makes no difference. That issue was closed as fixed, so if you are seeing this on v1.18.31 it may be a regression worth noting in that context.OPENCODE_AUTO_HEAP_SNAPSHOT=1 opencodeor ctrl+p → heap snapshot) that would help pin the exact retainer, which you noted yourself in the issue.If this is indeed a regression rather than a duplicate, please mention that in your report so maintainers can diff against the prior fix.
fm882 commentedon Sep 15, 2026
Follow-up with a clue that might help narrow this down: the steady-state memory splits cleanly into a "live" part and a "reclaimable garbage" part.
Setting a Bun/JSC heap ceiling env var before launch, which forces more aggressive GC:
...does not stop the initial spike (still climbs to ~7.1GB over the first ~8s, same growth curve as unconstrained), but once GC kicks in afterward, steady-state settles at ~3.6GB instead of ~6.5GB — about a 45% reduction. I pushed the cap as low as 256MB and steady-state stayed at ~3.6GB every time — it doesn't go any lower no matter how much GC pressure is applied. Confirmed the TUI still renders and functions correctly under this setting (prompt bar, skills panel, etc. all render normally), so it's a usable stopgap, not just a crash-avoidance trick.
That suggests:
This might help split the fix into two parts: (1) find and reduce whatever's eagerly loaded into that ~3.6GB permanent floor — a heap snapshot from inside the process would likely nail the exact retainer, which I wasn't able to trigger non-interactively from a scripted session — and (2) separately, GC isn't being triggered proactively enough by default, which is masking the true "live" footprint and making the problem look worse than it structurally is.
In the meantime,
BUN_JSC_forceRAMSizeis a usable workaround for anyone hitting this hard — cuts real-world RAM pressure by close to half with no observed functional regression in my testing.opencodejr commentedon Oct 28, 2026
Thanks for the very thorough report and for ruling out plugins, project content, skill symlinks and terminal size.
This was reported on 1.18.31, which is OpenCode v1. v1 now only gets fixes for critical problems (data loss, security issues, crashes, or breakage with no workaround). High memory use at startup that levels off is a real problem, but it doesn't meet that bar, so it is unlikely to be fixed in v1.
OpenCode v2 (the npm package
@opencode/cli, versions 2.x) is a completely separate implementation, including the TUI, and it is where active work happens. Please try it to see whether startup memory is still a problem there.Related issues, for reference:
If you believe this is critical (for example, it gets the process killed for running out of memory or makes OpenCode unusable on your machine), or if you see the same thing on v2, please reply here with the details. For v2, include the
opencode --versionoutput.opencodejr commentedon Oct 29, 2026
Closing this as not planned. The ~6.5–7 GB TUI startup memory was reported on v1 (1.18.31), which now only gets fixes for critical problems, and we haven't heard back that it causes a crash or out-of-memory kill, or that it also happens on v2.
Thanks again for the detailed investigation. If you try OpenCode v2 (
@opencode/cli) and still see high memory use at startup, please open a new issue with theopencode --versionoutput and the same measurements. You can also reply here if this turns out to be critical on v1.