Description
Title: [Bug] OpenCode leaks temporary .so files in /tmp, consuming hundreds of GB over time
Environment
- OS: CentOS 7 / Linux x86_64
- OpenCode: latest (running May 2026)
- Shell: bash
Summary
OpenCode generates temporary ELF shared object (.so) files in /tmp and never cleans them up. Over time, this accumulates into hundreds of gigabytes of disk space consumed by orphaned files.
Reproducible Steps
- Run OpenCode CLI for an extended period (days/weeks)
- Observe
/tmp directory
Observed Behavior
- OpenCode creates hidden
.so files in /tmp with naming pattern:
.5fff*-00000000.so (4.3 MB each)
.7bef*-00000000.so (4.5 MB each)
.fbff*-00000000.so (4.5 MB each)
- These are ELF 64-bit LSB shared objects (
file output: "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped")
- New files are generated continuously (creation timestamps within seconds of current time)
- Old files are never deleted — they accumulate indefinitely
Impact
On one system running OpenCode:
| Metric |
Before Cleanup |
After Cleanup |
/tmp size |
728 GB |
252 MB |
.so file count |
~154,000 |
0 |
| Disk usage |
1.8T / 1.9T (99%) |
1.1T / 1.9T (60%) |
| The system was running at 99% disk capacity, leaving only 30 GB free on a 1.9 TB disk. |
|
|
Root Cause Analysis
Using lsof, confirmed that running .opencode processes hold these files as memory-mapped regions:
.opencode 15606 root mem REG ... /tmp/.7befcfab9d7f5ff9-00000000.so
.opencode 27137 root mem REG ... /tmp/.7bef5fffbdff7fbf-00000000.so
.opencode 72378 root mem REG ... /tmp/.5fffa7f6acff5fe7-00000000.so
...
This suggests OpenCode is generating JIT-compiled or dynamically-loaded shared libraries (possibly from V8 code caching or WASM compilation) but lacks any cleanup mechanism — no tmpwatch integration, no file rotation, no cleanup on process exit.
Expected Behavior
- Temporary files should be cleaned up when the process exits
- Or at minimum, a bounded number of files should be retained (e.g., LRU eviction)
- Or use a dedicated temp directory (e.g.
/tmp/opencode/) that is cleaned on startup
Workaround
Added a cron job to clean old .so files daily:
0 2 * * * find /tmp -maxdepth 1 -name ".*.so" -type f -mtime +1 -delete
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Description
Title: [Bug] OpenCode leaks temporary .so files in /tmp, consuming hundreds of GB over time
Environment
Summary
OpenCode generates temporary ELF shared object (
.so) files in/tmpand never cleans them up. Over time, this accumulates into hundreds of gigabytes of disk space consumed by orphaned files.Reproducible Steps
/tmpdirectoryObserved Behavior
.sofiles in/tmpwith naming pattern:.5fff*-00000000.so(4.3 MB each).7bef*-00000000.so(4.5 MB each).fbff*-00000000.so(4.5 MB each)fileoutput: "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped")Impact
On one system running OpenCode:
/tmpsize.sofile countRoot Cause Analysis
Using
lsof, confirmed that running.opencodeprocesses hold these files as memory-mapped regions:This suggests OpenCode is generating JIT-compiled or dynamically-loaded shared libraries (possibly from V8 code caching or WASM compilation) but lacks any cleanup mechanism — no tmpwatch integration, no file rotation, no cleanup on process exit.
Expected Behavior
/tmp/opencode/) that is cleaned on startupWorkaround
Added a cron job to clean old
.sofiles daily:Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response