Activity

1. github-actions

   assigned

   rekram1-node

   on Aug 16, 2026
2. github-actions commented on Aug 16, 2026

   

   github-actionsBot

   on Aug 16, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • tui: leaks ~21MB .so per launch into /tmp; fills tmpfs and breaks TUI startup #42700: tui leaks ~21MB .so per launch into /tmp; fills tmpfs and breaks TUI startup
   • [Bug] OpenCode leaks temporary .so files in /tmp, consuming hundreds of GB over time #28089: OpenCode leaks temporary .so files in /tmp, consuming hundreds of GB over time
   • tui: libopentui temporary copies consume 207 GiB #39876: libopentui temporary copies consume 207 GiB
   • v2 cli: headless commands load OpenTUI and leak native temp files #37671: v2 cli headless commands load OpenTUI and leak native temp files

   Please check whether any of the above already covers your report, and consider adding your findings (rate ~700 MB/min, the RAM disk + cleanup timer workaround) as a comment on the most relevant existing issue rather than opening a new one. If your case is distinct, please let a maintainer know.
3. weboliver commented on Aug 16, 2026

   

   weboliver

   on Aug 16, 2026

   Last edited by weboliver

   Author

   More actions

   Traced this: opencode itself creates these files (main PID, not a subprocess), one per LLM output event, and never cleans them up.

   strace -f -e trace=openat,unlink,unlinkat -P /tmp -p <opencode_pid> on v1.18.18 during a normal chat session shows:

   • Every .so write comes from a fresh PID/TID that resolves back to opencode itself — a new one per LLM output chunk (1:1 timing correlation), never reused.
   • unlink/unlinkat traced in parallel but produced ~0 matching events for these paths:
     grep -c 'openat..so' trace.log # N opens
     grep -c 'unlink..so' trace.log # ~0
   • → real leak, not fast cache churn. Matches the reported ~700 MB/min.

   Env: WSL2, /tmp on tmpfs.

   sudo strace -f -e trace=openat,unlink,unlinkat -e signal=none -P /tmp -tt -p 2>&1 | grep --line-buffered '.so'
   [pid 245737] 21:07:56.991061 openat(13, ".9adf5ebbf3f2ffdf-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 245760] 21:07:59.375999 openat(13, ".9adf5ebde3fcefd7-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 245867] 21:08:12.598743 openat(13, ".9adf5ebff7ffef97-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 245893] 21:08:15.515089 openat(13, ".9adf5ebfe3efefd7-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 245992] 21:08:32.394968 openat(13, ".9adf5ebbf3f0ff87-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246032] 21:08:35.498223 openat(13, ".9adf5ebdeae0fdb7-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246053] 21:08:38.566210 openat(13, ".9adf5ebde3e3fdff-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246176] 21:08:57.710706 openat(13, ".9adf5ef9f6e0ffd7-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246234] 21:09:00.636154 openat(13, ".9adf5efbe7fafdb7-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246263] 21:09:04.482977 openat(13, ".9adf5efbeae9fd97-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14
   [pid 246411] 21:09:15.574247 openat(13, ".9adf5efdfffdfdaf-00000000.so", O_WRONLY|O_CREAT|O_CLOEXEC, 0644) = 14

   I hope that helps.

   Best Regards,
   Oliver
4. thdxr commented on Aug 19, 2026

   

   thdxr

   on Aug 19, 2026

   Member

   More actions

   Update: the unbounded native-library temp-file growth described here is fixed in OpenCode V2.

   As of V2 build 0.0.0-dev-17643, the compiled CLI uses Bun 1.4.0-canary.1 (681a49bee). That runtime includes oven-sh/bun#29587, which replaces the unique temporary .so/.dylib/.node extraction on every load with a deterministic, content-hashed path reused across calls, Workers, processes, and restarts. The V2 build provenance is workflow run 32216069554.

   This bounds extraction to one reusable file per embedded native module and user instead of allowing unbounded disk growth. It does not mean the temp directory will contain zero native files, and upgrading does not remove files leaked by older builds; those stale randomly named files can be cleaned up after all older OpenCode processes have stopped.

   👍React with 👍1Reacted by Oliver Neumann

   ❤️React with ❤️1Reacted by Oliver Neumann
5. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
6. thdxr

   closed this as not plannedon Oct 11, 2026