opencode2: RSS grows ~530 MB/min during active agent turn (OOM crash)

[ildella]

Summary

opencode2 (@opencode-ai/cli@0.0.0-next-17088) leaks memory at a steady ~530 MB/min RSS during an active agent turn, climbing from ~3.8 GB to ~6.2 GB in ~4.5 minutes and eventually crashing the process. Related: #20695 (Memory Megathread).

Environment

• opencode version: 0.0.0-next-17088 (opencode2 from @opencode-ai/cli)
• OS: Linux 7.0.0-29-generic (Ubuntu, x86_64) — Linux tuxell 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 GNU/Linux
• Terminal: TERM=xterm-256color, COLORTERM=truecolor (no TERM_PROGRAM)
• Shell: /bin/bash
• Install/channel: next — binary opencode2.exe via npm global @opencode-ai/cli@0.0.0-next-17088 (~/n/bin/opencode2 → @opencode-ai/cli/bin/opencode2.exe)
• Active plugins (config + local):
  • @sveltejs/opencode (configured)
  • local: ~/.config/opencode/plugins/notify.ts, worktree.ts
  • skill snapshot also listed: @knikolov/opencode-plugin-simple-memory (verify if still loaded)
• MCP (enabled): codegraph (local), mdn (remote), axiom, posthog, paddle-sandbox, paddle-live, netlify
• Compaction: auto: false, prune: false

Reproduction

1. Start opencode2 in a project session (managed/background service default).
2. Run an active agent turn (model streaming + tool calls; not idle).
3. In another terminal, sample RSS every 30s:

while true; do date; ps -o pid,rss,vsz,comm -p $(pgrep -f "opencode2.exe"); echo "---"; sleep 30; done | tee /tmp/opencode_mem.log

4. Observe linear RSS growth until the process dies / becomes unusable.

Expected Behavior

RSS should stay roughly stable or grow slowly with context, not hundreds of MB per minute during a normal agent turn. The process should not OOM/crash from unbounded growth.

Actual Behavior

Near-linear RSS growth while an agent turn is active:

Time (CEST)	RSS (KB)	RSS (MB)	Δ / 30s (MB)
09:50:33	3,910,156	3,819	—
09:51:03	4,177,524	4,080	+261
09:51:33	4,454,140	4,350	+270
09:52:03	4,722,152	4,612	+262
09:52:33	4,989,172	4,872	+261
09:53:03	5,271,300	5,148	+276
09:53:33	5,534,664	5,405	+257
09:54:03	5,828,616	5,692	+287
09:54:33	6,076,260	5,934	+242
(log end)	6,367,028	6,218	—

Derived from full /tmp/opencode_mem.log (10 samples):

• Start RSS: ~3.8 GB → end: ~6.2 GB
• Total growth: ~2.4 GB in ~4.5 min
• Average: ~267 MB / 30s ≈ ~533 MB/min
• VSZ also climbs in lockstep (~80 GB range; large virtual map)

Process eventually crashes / becomes unusable (continuous crash loop from user POV). Host has 29 GiB RAM; swap was already under pressure (free: ~4.9 GiB swap used at capture time).

Additional Context

• Workload during leak: active agent turn (streaming + tools), not idle.
• Session had multiple MCP servers and subagent use available; leak observed under normal interactive agent work.
• Heap snapshot not yet captured — will follow megathread flow and upload:
  • Manual: Ctrl+P → “heap snapshot” while RSS is elevated, upload to the Dropbox request in Memory Megathread #20695
  • Auto: OPENCODE_AUTO_HEAP_SNAPSHOT=1 opencode2 then use until RSS > ~2 GB; snapshots land in the log dir as .heapsnapshot
• Happy to upload a heap snapshot and add a short note on Memory Megathread #20695 once captured.
• No secrets included; plugin/MCP list redacted of tokens.

[ildella]

Follow-up: heap snapshot tooling unavailable on opencode2

Tried the megathread (#20695) instructions on opencode2 0.0.0-next-17088. Neither path works.

Manual (Ctrl+P → heap snapshot)

• Ctrl+P opens the command palette.
• Searching heap / snapshot / Write heap snapshot returns zero matches.
• So the documented manual flow appears not exposed in the opencode2 TUI palette (or not wired).

Auto (OPENCODE_AUTO_HEAP_SNAPSHOT=1)

• Set on the TUI client only (opencode2 PID had the env; serve --service did not).
• After use, ~/.local/share/opencode/log/ still contains only *.log files — no *.heapsnapshot.
• Service is started via detached spawn (serve --register / serve --service) and does not inherit the client’s env unless the service itself is started with the flag.
• Even with the flag on the client, no snapshot file appeared while memory climbed.

Process split (leak is the background service)

While reproducing with an active agent turn:

Process	Role	Notes
opencode2.exe serve --service	backend	RSS climbed into multi‑GB range (e.g. ~0.9 GB → ~2.3 GB+ while monitoring)
opencode2 (TUI)	frontend	Much smaller RSS; had OPENCODE_AUTO_HEAP_SNAPSHOT=1

So the unbounded growth is on the managed service, not the TUI.

Other disk artifacts (may be related)

• ~/.local/share/opencode/opencode.db ≈ 4.2 GB
• ~/.local/share/opencode/log/opencode.log ≈ 109 MB
• Log dir listing: only dated *.log + opencode.log — no heap snapshots

Ask

1. Is heap snapshot supported on opencode2 / next yet? If yes, what’s the correct trigger for the service process?
2. If not, please treat the RSS time series in the issue body as the primary evidence until tooling lands on v2.
3. Happy to re-run with any v2-specific snapshot/debug flag you provide.

[ildella]

It's some MCP. I got tricked by this to enable them all: "https://x.com/thdxr/status/2085865399195779308" :)

I'll investigate which one.

[ildella]

1. paddle MCPs leaked something. Started growing when activated

---
Mon 10 Aug 11:39:52 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 666132 78523344 opencode2.exe
---
Mon 10 Aug 11:40:22 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 668580 78523344 opencode2.exe
---
Mon 10 Aug 11:40:52 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 772336 78591460 opencode2.exe
---
Mon 10 Aug 11:41:22 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 723116 78591460 opencode2.exe

......

---
Mon 10 Aug 12:00:54 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 1033152 79131068 opencode2.exe
---
Mon 10 Aug 12:01:24 CEST 2026
    PID   RSS    VSZ COMMAND
 582116 1141100 79163836 opencode2.exe
---

But probably another one was leaking as well as before it was growing much faster.