anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 18:10:41 -05:00 by yindo · 10 comments
yindo commented 2026-02-16 18:10:41 -05:00
Owner
Copy Link
Copy Source

Originally created by @baiyun1123 on GitHub (Feb 6, 2026).

Originally assigned to: @thdxr on GitHub.

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_
Originally created by @baiyun1123 on GitHub (Feb 6, 2026). Originally assigned to: @thdxr on GitHub. ### 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: ```json { "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_
yindo added the bug label 2026-02-16 18:10:41 -05:00
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 6, 2026):

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

  • #11689: [FEATURE]: Make a binary build for Android Aarch64 (Termux) - This feature request addresses the exact same problem of missing Android/Termux support
  • #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.

@github-actions[bot] commented on GitHub (Feb 6, 2026): This issue might be a duplicate of existing issues. Please check: - #11689: [FEATURE]: Make a binary build for Android Aarch64 (Termux) - This feature request addresses the exact same problem of missing Android/Termux support - #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.
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 6, 2026):

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 commented on GitHub (Feb 6, 2026): 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.
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 6, 2026):

awa

@baiyun1123 commented on GitHub (Feb 6, 2026): awa
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@kaan-escober commented on GitHub (Feb 8, 2026):

@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

@kaan-escober commented on GitHub (Feb 8, 2026): @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
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 9, 2026):

@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 commented on GitHub (Feb 9, 2026): @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.
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 9, 2026):

no

@baiyun1123 commented on GitHub (Feb 9, 2026): no
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 9, 2026):

It doesn't seem to be good yet

@baiyun1123 commented on GitHub (Feb 9, 2026): It doesn't seem to be good yet
yindo commented 2026-02-16 18:10:41 -05:00
Author
Owner
Copy Link
Copy Source

@kaan-escober commented on GitHub (Feb 9, 2026):

whats wrong

@kaan-escober commented on GitHub (Feb 9, 2026): whats wrong
yindo commented 2026-02-16 18:10:42 -05:00
Author
Owner
Copy Link
Copy Source

@baiyun1123 commented on GitHub (Feb 9, 2026):

@kaan-escober ---
Title: ld-linux-aarch64.so.1: loader cannot load itself error on Termux

Description:
When running the built Termux binary, the following error occurs:
$ ./my-app-termux
ld-linux-aarch64.so.1: loader cannot load itself
Exit code: 127

Environment:

  • Platform: Android/Termux (aarch64)
  • glibc version: 2.42 (glibc package)
  • glibc-runner version: 2.0-3
  • clang version: 21.1.8

Steps to Reproduce:

  1. Clone the repository
  2. Run make to build wrapper
  3. Run python3 build.py ./demo-app/my-app
  4. Execute the generated binary: ./my-app-termux

Investigation:

  1. The wrapper binary is built successfully (Bionic-linked, Android-compatible)
  2. The build process successfully embeds the Bun ELF and generates my-app-termux (247.5 KB)
  3. On first run, the wrapper extracts the embedded Bun ELF to $TMPDIR/bun-termux-cache/
  4. The extracted file /data/data/com.termux/files/usr/tmp/bun-termux-cache/bun-* is identical to the glibc's ld-linux-aarch64.so.1 (241144 bytes)

Analysis:

  • The wrapper extracts the wrong data - it appears to be extracting ld-linux-aarch64.so.1 instead of the actual Bun binary
  • This suggests the BUNWRAP1 metadata parsing or Bun ELF size extraction may be incorrect
  • Or the original my-app binary may have an incorrect structure

Expected Behavior:
The bundled Bun executable should run on Termux without the "loader cannot load itself" error.

@baiyun1123 commented on GitHub (Feb 9, 2026): @kaan-escober --- Title: ld-linux-aarch64.so.1: loader cannot load itself error on Termux Description: When running the built Termux binary, the following error occurs: $ ./my-app-termux ld-linux-aarch64.so.1: loader cannot load itself Exit code: 127 Environment: - Platform: Android/Termux (aarch64) - glibc version: 2.42 (glibc package) - glibc-runner version: 2.0-3 - clang version: 21.1.8 Steps to Reproduce: 1. Clone the repository 2. Run make to build wrapper 3. Run python3 build.py ./demo-app/my-app 4. Execute the generated binary: ./my-app-termux Investigation: 1. The wrapper binary is built successfully (Bionic-linked, Android-compatible) 2. The build process successfully embeds the Bun ELF and generates my-app-termux (247.5 KB) 3. On first run, the wrapper extracts the embedded Bun ELF to $TMPDIR/bun-termux-cache/ 4. The extracted file /data/data/com.termux/files/usr/tmp/bun-termux-cache/bun-* is identical to the glibc's ld-linux-aarch64.so.1 (241144 bytes) Analysis: - The wrapper extracts the wrong data - it appears to be extracting ld-linux-aarch64.so.1 instead of the actual Bun binary - This suggests the BUNWRAP1 metadata parsing or Bun ELF size extraction may be incorrect - Or the original my-app binary may have an incorrect structure Expected Behavior: The bundled Bun executable should run on Termux without the "loader cannot load itself" error.
yindo commented 2026-02-16 18:10:42 -05:00
Author
Owner
Copy Link
Copy Source

@kaan-escober commented on GitHub (Feb 9, 2026):

if you could tell me mofe about the binary, i will try to fix it

@kaan-escober commented on GitHub (Feb 9, 2026): if you could tell me mofe about the binary, i will try to fix it
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8731
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?