Summary
OpenCode V2 loads its embedded OpenTUI native library for commands that do not render a TUI, including --version, --help, service status, and api. Each process leaves a uniquely named 13.1 MiB libopentui.so in the temporary directory, allowing repeated API or diagnostic calls to exhaust /tmp.
Current V1 loads OpenTUI lazily and does not produce these files for equivalent noninteractive and headless commands.
Environment
- opencode version: installed
0.0.0-next-15760; also reproduced with 0.0.0-next-15803 and current 0.0.0-next-15806
- OS: Arch Linux, kernel
7.1.2-arch3-1, x86_64
- Terminal: tmux,
TERM=xterm-256color, COLORTERM=truecolor
- Shell:
/bin/zsh
- Install/channel: npm package
@opencode-ai/cli, next channel
- Active plugins:
goal-mode.ts, superpowers.ts, and tmux-status.ts; the minimal --version reproduction does not initialize a session or require plugin activity
Reproduction
-
Create an isolated temporary directory:
-
Run a command that cannot render a TUI:
TMPDIR="$probe" BUN_TMPDIR="$probe" opencode2 --version
-
Inspect the directory:
find "$probe" -maxdepth 1 -type f -printf '%s %f\n'
-
Repeat the command and inspect the directory again.
With 0.0.0-next-15806, one invocation produces:
opencode2 v0.0.0-next-15806
13745312 .9adb78bde7f6fdc7-00000000.so
readelf -d identifies the extracted file as:
Each invocation creates another randomly named copy. The installed next-15760 build also reproduces this with --help, service status, and opencode2 api ....
Expected Behavior
Commands that do not render terminal UI should not import or initialize OpenTUI. Version, help, service-management, and API commands should not extract the renderer library.
This is independent of whether Bun eventually deduplicates or cleans embedded bun:ffi libraries: OpenCode should avoid loading its renderer when the selected command cannot use it.
Actual Behavior
Every tested V2 process extracts and retains a separate 13,745,312-byte libopentui.so, including --version.
In one real workload, repeated opencode2 api diagnostics accumulated:
- 459 complete OpenTUI libraries
- 188 zero-byte failed extraction attempts after quota exhaustion
- 5.82 GiB of leaked native libraries
- Exhaustion of the per-user quota on an 8 GiB
/tmp tmpfs
The file-creation timeline correlated with CLI process starts. During one minute, 77 opencode2 api processes started and 77 native libraries appeared.
After quota exhaustion, starting the TUI failed with:
Failed to initialize OpenTUI render library: Failed to open library
"/$bunfs/root/libopentui-h3hyjpa5.so":
/$bunfs/root/libopentui-h3hyjpa5.so: cannot open shared object file:
No such file or directory
Deleting the leaked libraries restored TUI startup.
Additional Context
The current stable V1 release, opencode 1.18.3, was tested as a control.
These V1 commands leave no extracted native library:
opencode --version
opencode run --help
opencode serve --help
opencode debug paths
opencode serve
Starting the actual V1 interactive TUI does extract one 13,622,688-byte libopentui.so, including after a clean Ctrl-C exit. This confirms that V1 still inherits Bun's extraction leak when OpenTUI is genuinely needed, but it does not amplify it through every headless CLI invocation.
The underlying Bun bun:ffi extraction issue is already tracked:
Related OpenCode reports:
This report is specifically about V2 eagerly loading OpenTUI in commands that do not need terminal rendering. Avoiding that import would remove the high-frequency API and diagnostic amplification independently of the pending Bun fix.
Summary
OpenCode V2 loads its embedded OpenTUI native library for commands that do not render a TUI, including
--version,--help,service status, andapi. Each process leaves a uniquely named 13.1 MiBlibopentui.soin the temporary directory, allowing repeated API or diagnostic calls to exhaust/tmp.Current V1 loads OpenTUI lazily and does not produce these files for equivalent noninteractive and headless commands.
Environment
0.0.0-next-15760; also reproduced with0.0.0-next-15803and current0.0.0-next-158067.1.2-arch3-1, x86_64TERM=xterm-256color,COLORTERM=truecolor/bin/zsh@opencode-ai/cli,nextchannelgoal-mode.ts,superpowers.ts, andtmux-status.ts; the minimal--versionreproduction does not initialize a session or require plugin activityReproduction
Create an isolated temporary directory:
probe="$(mktemp -d)"Run a command that cannot render a TUI:
Inspect the directory:
Repeat the command and inspect the directory again.
With
0.0.0-next-15806, one invocation produces:readelf -didentifies the extracted file as:Each invocation creates another randomly named copy. The installed
next-15760build also reproduces this with--help,service status, andopencode2 api ....Expected Behavior
Commands that do not render terminal UI should not import or initialize OpenTUI. Version, help, service-management, and API commands should not extract the renderer library.
This is independent of whether Bun eventually deduplicates or cleans embedded
bun:ffilibraries: OpenCode should avoid loading its renderer when the selected command cannot use it.Actual Behavior
Every tested V2 process extracts and retains a separate 13,745,312-byte
libopentui.so, including--version.In one real workload, repeated
opencode2 apidiagnostics accumulated:/tmptmpfsThe file-creation timeline correlated with CLI process starts. During one minute, 77
opencode2 apiprocesses started and 77 native libraries appeared.After quota exhaustion, starting the TUI failed with:
Deleting the leaked libraries restored TUI startup.
Additional Context
The current stable V1 release,
opencode 1.18.3, was tested as a control.These V1 commands leave no extracted native library:
Starting the actual V1 interactive TUI does extract one 13,622,688-byte
libopentui.so, including after a clean Ctrl-C exit. This confirms that V1 still inherits Bun's extraction leak when OpenTUI is genuinely needed, but it does not amplify it through every headless CLI invocation.The underlying Bun
bun:ffiextraction issue is already tracked:Related OpenCode reports:
opencode run --format jsonextracts libopentui.so to /tmp on every invocation, causing unbounded disk growth #21427This report is specifically about V2 eagerly loading OpenTUI in commands that do not need terminal rendering. Avoiding that import would remove the high-frequency API and diagnostic amplification independently of the pending Bun fix.