Standalone executables leak a fresh TMPDIR copy of every dlopen'd embedded native library on each launch #40076

What version of Bun is running?

1.3.14

Which platform(s) does your issue occur on?

Linux x64 (WSL2, kernel 6.6). Likely affects every platform where bun build --compile output dlopens embedded native libraries.

What build steps are needed to reproduce?

$ cc -shared -fPIC -o lib.so lib.c   # int marker(void) { return 42; }

entry.ts:

import lib from "./lib.so" with { type: "file" }

const { dlopen } = await import("bun:ffi")
dlopen(lib, { marker: { args: [], returns: "int" } })
console.log("dlopened:", lib)

Build and run the standalone executable twice:

$ bun build --compile --target=bun-linux-x64 ./entry.ts --outfile app
$ ./app && ./app

What is the expected behavior?

The temporary extraction of an embedded native library should be cleaned up after dlopen (or reused across launches), so running a compiled binary does not grow $TMPDIR.

What do you see instead?

Every launch extracts a fresh copy of the embedded library to $TMPDIR/.<hash>-<index>.so and never deletes it — not even on clean exit. After the two runs above:

$ ls -la /tmp/.59ee* 
-rw-r--r-- 1 thomas thomas 15112 Aug 22 11:20 /tmp/.59ee776dfc9ebfd7-00000000.so
-rw-r--r-- 1 thomas thomas 15112 Aug 22 11:20 /tmp/.59ee776dfddbfeff-00000000.so
-rw-r--r-- 1 thomas thomas 15112 Aug 22 11:16 /tmp/.59ee77edf4bfbfbf-00000000.so
-rw-r--r-- 1 thomas thomas 15112 Aug 22 11:16 /tmp/.59ee77edf7b2bf97-00000000.so

One leaked file per process launch (the two 11:16 files are from earlier runs of the same binary).

Real-world impact

opencode ships a ~14 MB libopentui.so inside its compiled binary; it gets extracted to a fresh temp file on every launch and never unlinked. A user accumulated 44 orphaned copies (~533 MB), which filled /tmp completely — after which opencode failed to start at all with a misleading "Failed to open library ... No such file or directory" (the extraction write hits ENOSPC, so the path doesn't exist by the time dlopen runs).

Notes for a fix

• Unlinking the temp file right after dlopen returns is safe on Linux/macOS: the inode survives for the existing mapping, and typical consumers (e.g. OpenTUI) never re-open the path. On Windows the unlink of a loaded DLL will fail, which can be ignored or deferred.
• Alternatively, reuse one cached extraction per embedded library across launches (keyed by content hash) instead of extracting per launch.
• The current failure mode when $TMPDIR is full also produces a confusing error: the reported bunfs path (/$bunfs/root/lib...so) looks like a packaging bug rather than ENOSPC.