fix(cli): redirect Bun's tempdir when /tmp is mounted noexec

[LeaCoder0]

Issue for this PR

Closes #26136

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes a silent hang when /tmp is mounted noexec. This is fairly common on hardened Linux setups (CIS, STIG, Lynis baselines all set noexec,nodev,nosuid on /tmp), and increasingly common on managed corporate workstations.

The bundled Bun runtime extracts libopentui.so to $TMPDIR (defaults to /tmp) and dlopens it. When the mount has noexec, mmap can't grant the EXEC perm on the segments and dlopen fails. The TUI swallows the error and the process just hangs — there's no user-visible output unless you remember to pass --print-logs --log-level DEBUG.

Bun reads BUN_TMPDIR to override its embedded-file extraction path. The Node launcher in packages/opencode/bin/opencode already runs before the Bun child is spawned, so it's the right place to set that env var when needed.

The patch adds ensureExecutableTmpdir() which, on Linux only:

1. respects an existing BUN_TMPDIR (if the user already set it, don't touch it)
2. parses /proc/self/mounts to find the longest mountpoint covering $TMPDIR (or /tmp if unset)
3. if that mount has the noexec option, sets BUN_TMPDIR to $HOME/.cache/opencode/tmp and mkdir -ps it

If /tmp is exec-allowed (the common case for everyone not on a hardened box), the function returns immediately and there's zero behavior change. If anything in detection or mkdir fails, it bails out silently so the original error still surfaces — never makes things worse.

The same workaround was already documented as a user wrapper in #5175. This just moves it inside the launcher so affected users don't need a wrapper script.

Why this and not a Bun-side fix: a maintainer comment on #5175 notes the underlying issue is also being worked on in Bun. Once that lands this shim becomes a no-op and can be removed. Until then, this unblocks users.

How did you verify your code works?

Tested on Ubuntu 24.04 (kernel 6.17) with /tmp mounted rw,nosuid,nodev,noexec:

Before the patch:

• opencode hangs forever
• opencode --print-logs --log-level DEBUG shows Failed to initialize OpenTUI render library: ... failed to map segment from shared object

After the patch:

• opencode brings up the TUI normally; all internal plugins (home-footer, home-tips, sidebar-context, etc.) report loaded
• ~/.cache/opencode/tmp/ is created on first run, libopentui.so lands there

Also verified the no-op paths:

• with BUN_TMPDIR=/some/path already exported → function returns early, env var preserved
• on a system with exec-allowed /tmp (a separate VM) → function still returns early, no ~/.cache/opencode/tmp/ is created

Ran node --check packages/opencode/bin/opencode to make sure the launcher still parses.

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍