Headless opencode serve still extracts libopentui.so into /tmp on every start, causing temp artifact buildup #20043

Description

opencode serve is documented as a headless server, but on Linux it still extracts a bundled native OpenTUI shared library (libopentui.so) into /tmp during startup.

In long-running environments where opencode serve is restarted periodically, this causes repeated creation of hidden temp artifacts such as:

• /tmp/.58afeffabbf7dede-00000000.so
• /tmp/.58afffdf9b3fffef-00000000.so

Observed properties:

• each file is about 4.2 MB
• filenames are randomized
• file content is identical across runs
• ELF SONAME is libopentui.so
• the file is mapped directly by the opencode serve process itself
• the artifact is created at startup time, before pyright-langserver starts

This means the issue is not primarily about language-server activity. It appears to come from the standalone opencode binary extracting a bundled native library even for serve.

Why this is a problem

For headless server deployments, this behavior is surprising and operationally expensive:

• /tmp accumulates many hidden .so files over time
• repeated restarts create new copies with different names
• cleanup is hard to automate safely in shared /tmp
• the behavior is especially awkward for long-running service environments, where serve is used without any terminal UI

What I verified

On Linux, I verified that:

1. opencode serve starts first
2. the temp .so appears immediately after startup
3. pyright-langserver starts much later
4. lsof and /proc/<pid>/maps show the .so is mapped by the opencode serve process
5. the extracted file reports SONAME: libopentui.so

Expected behavior

At least one of the following would be preferable:

1. opencode serve should avoid loading or extracting OpenTUI native libraries entirely when running in headless mode
2. the extracted native library should be cleaned up automatically on normal shutdown
3. extracted files should be reused from a stable cache path instead of creating a new randomized temp file on each start
4. documentation for serve should explicitly call out the BUN_TMPDIR requirement/workaround for service deployments

Suggested improvements

Preferred

• split headless/server builds from TUI-capable builds, so opencode serve does not carry OpenTUI runtime baggage at all

Acceptable

• reuse a deterministic cache location for bundled native libs
• unlink temp artifacts after successful load when possible
• provide an explicit server/runtime flag or documented environment variable strategy for temp extraction

Workaround

BUN_TMPDIR helps redirect the extraction location, but it does not solve the underlying accumulation behavior.

Example:

BUN_TMPDIR=/var/lib/opencode-bun-tmp opencode serve --hostname 127.0.0.1 --port 34876

This is useful operationally, but it still feels like a workaround rather than the correct headless-server behavior.

Version

Observed on the latest release at the time of filing: v1.3.7

Environment

• OS: Linux
• mode: opencode serve
• deployment style: long-running headless service