Repository navigation
Runaway /tmp .589*-00000000.so artifacts can exhaust disk during long-running usage #16996
Closed as not planned
Description
Problem
During long-running usage, temporary files under /tmp accumulate rapidly with names like:
.589<hex>-00000000.so
These can grow unbounded and exhaust root disk space.
Environment
- Linux host
- OpenCode CLI/serve usage over long sessions
Observed Behavior
/tmpgrew to tens of GB from this pattern alone- files continued to appear over time
- disk exhaustion caused service instability and I/O errors
Reproduction Pattern
- Run OpenCode continuously with multiple active sessions/plugins/tools
- Observe
/tmpover time - Count matching files:
ls /tmp | grep -E '^\\.589[0-9a-f]+-00000000\\.so$' | wc -l
Expected Behavior
- temporary runtime artifacts should be cleaned automatically
- no unbounded growth in
/tmp
Suggested Fix Directions
- ensure deterministic cleanup for generated temp
.soartifacts - add lifecycle hooks for cleanup on process exit and crash paths
- consider bounded temp storage / periodic internal cleanup
- add debug metrics/logging for temp artifact creation and cleanup
Reacted by Mike Wyatt, Andrey Andreev and G. M.
Reacted by Bala Bosch, Matt Jackson and Luigi Maselli
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Mar 11, 2026
This issue might be a duplicate of existing issues. Please check:
.so/.dylibtemp files with hex names loaded from/tmpby OpenCode's Bun runtimeIf your issue is specifically about the
.589*-00000000.sofiles (which are Bun's native runtime libraries for OpenTUI), it may already be tracked in one of the above. Please check those issues before proceeding.If this is a distinct problem (e.g., unbounded growth rather than just the presence of these files), feel free to clarify and this issue will remain open.
johnuopini commentedon Apr 15, 2026
Same issue, basically the app is unusable, fills disk in a day
fix(session): read opencode session list from SQLite, not subprocess (#…
github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
thdxr commentedon Aug 19, 2026
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/.nodeextraction 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.
bit0x43 commentedon Aug 26, 2026
Noting here for completeness: this same bunfs temp-artifact leak is still active and has a macOS sibling. On macOS (arm64) opencode leaks ~3.6 MB
.dylibfiles ($TMPDIR/.5bff*-00000000.dylib, etc.) continuously during a session — measured ~1.6 GB/hour (33 GB in 21 h on opencode 1.18.23). Tracked in the open issue #42700, which remains unfixed. Workaround:find "$TMPDIR" -maxdepth 1 -type f -name '.*-*.dylib' -delete(safe on macOS; space frees when the process exits).