Android/Termux install fails: postinstall requires missing package `opencode-android-arm64`

[baiyun1123]

Description

Title: Android/Termux install fails: postinstall requires missing package opencode-android-arm64

Hi maintainers,

I’m trying to install opencode-ai in Termux (Android arm64), and installation fails during postinstall.

Environment

• Device: Android (arm64)
• Shell: Termux
• Node: (run node -v)
• npm: (run npm -v)
• Install command: npm i -g opencode-ai

Error log

Failed to setup opencode binary: Could not find package opencode-android-arm64: Cannot find module 'opencode-android-arm64/package.json'
Require stack:

• /data/data/com.termux/files/usr/lib/node_modules/opencode-ai/postinstall.mjs

npm error code 1
npm error path /data/data/com.termux/files/usr/lib/node_modules/opencode-ai
npm error command failed
npm error command sh -c bun ./postinstall.mjs || node ./postinstall.mjs

Investigation

optionalDependencies for opencode-ai currently are:

{
  "opencode-linux-x64": "1.1.53",
  "opencode-darwin-x64": "1.1.53",
  "opencode-linux-arm64": "1.1.53",
  "opencode-windows-x64": "1.1.53",
  "opencode-darwin-arm64": "1.1.53",
  "opencode-linux-x64-musl": "1.1.53",
  "opencode-linux-arm64-musl": "1.1.53",
  "opencode-linux-x64-baseline": "1.1.53",
  "opencode-darwin-x64-baseline": "1.1.53",
  "opencode-windows-x64-baseline": "1.1.53",
  "opencode-linux-x64-baseline-musl": "1.1.53"
}

### Plugins

_No response_

### OpenCode version

_No response_

### Steps to reproduce

_No response_

### Screenshot and/or share link

_No response_

### Operating System

_No response_

### Terminal

_No response_

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Make a binary build for Android Aarch64 (Termux) #11689: [FEATURE]: Make a binary build for Android Aarch64 (Termux) - This feature request addresses the exact same problem of missing Android/Termux support
• OpenCode binary fails to run natively on Termux / Android aarch64 (wrong interpreter + non‑PIE executable) #10504: OpenCode binary fails to run natively on Termux / Android aarch64 - Related to binary compatibility issues on Android/Termux

Feel free to ignore if none of these address your specific case.

[baiyun1123]

I believe this is a duplicate of #11689 (and related to #10504).

My Termux/Android arm64 repro:

• npm i -g opencode-ai fails in postinstall.mjs
• error: Cannot find module 'opencode-android-arm64/package.json'
• npm view opencode-ai optionalDependencies --json does not include opencode-android-arm64

So Android arm64 seems referenced by installer logic but not published as a platform package.
Also, running binaries from shared storage paths (e.g. /sdcard-like mount) can cause Permission denied due to noexec, which is a separate runtime constraint.

[baiyun1123]

awa

[kaan-escober]

@thdxr here is the complete termux fix
so i fixed the whole bun termux compatibilty thing once and for all.

Termux uses Bionic (Android's libc), but Bun is compiled against glibc. The standard workaround is using grun (glibc-runner), but this breaks Bun bundled executables because /proc/self/exe points to ld.so instead of the actual binary.

Bun bundled executables detect their embedded JavaScript by reading /proc/self/exe and looking for the ---- Bun! ---- magic trailer. When /proc/self/exe points to ld.so, Bun can't find its embedded code and falls back to CLI mode.

The Solution

This tool uses userland exec - it loads glibc's ld.so via mmap() and jumps to it directly, without calling execve(). Since the kernel only updates /proc/self/exe on execve(), it stays pointing to our binary which contains the embedded JavaScript.

I wrote a custom userspace exec wrapper in C. Now Opencode, Droid, claude code & Amp run natively on termux. Opencode was a little trickier because it loaded opentui from $bunfs which wasnt available on termux, so i added a dlopen interception for $bunfs calls and now Opencode works

Here is the repo with source code: https://github.com/kaan-escober/bun-termux-loader

[baiyun1123]

@kaan-escober
Thanks for the report. That error usually means the wrapper is extracting the wrong ELF and jumping into ld-linux-aarch64.so.1 instead of the Bun runtime. In your case the cached file size (241144 bytes) matches glibc’s ld-linux-aarch64.so.1, not the Bun ELF (~90MB), so the metadata parsing or input binary is likely wrong.
Please confirm:
1)
file ./my-app (input to build.py)
2)
strings -n 8 ./my-app | rg 'BUNWRAP1|---- Bun! ----'
3)
ls -l $TMPDIR/bun-termux-cache/ (size of extracted bun-* file)
If the input isn’t the compiled bun binary from bun build --compile, build.py will embed the wrong payload and you’ll hit this exact error. Once the input is correct, the extracted bun-* file should be ~90MB and the error should disappear.

[baiyun1123]

no

[baiyun1123]

It doesn't seem to be good yet