Summary
On Termux, the packaged latest line can fail when Codex relaunches the native Android binary directly instead of going through the Node wrapper.
The practical symptom is that operations such as apply_patch can fail before doing any work with an Android linker error about libc++_shared.so.
Environment
- Package:
@mmmbuto/codex-cli-termux@0.116.2
- Device environment: Android Termux ARM64
- Reproduced from a fresh reinstall
Example failure from a Codex conversation
During an interactive Codex conversation, apply_patch reported:
• Added thread_apply_patch_probe.txt (+1 -0)
1 +probe
✘ Failed to apply patch
└ CANNOT LINK EXECUTABLE "/data/data/com.termux/files/usr/lib/node_modules/@mmmbuto/codex-cli-termux/bin/codex.bin": library "libc++_shared.so" not found: needed by main executable
That same failure pattern also appears when launching the packaged ELF directly without the wrapper-provided environment.
Direct reproduction
From the installed package, the native binary fails under a stripped environment:
env -i PATH=/data/data/com.termux/files/usr/bin:/system/bin /data/data/com.termux/files/usr/lib/node_modules/@mmmbuto/codex-cli-termux/bin/codex.bin --version
Observed result:
CANNOT LINK EXECUTABLE ".../codex.bin": library "libc++_shared.so" not found
Expected result:
Root cause
The Android ELF no longer carries a usable runpath for its bundled shared C++ runtime. Older Termux builds worked because the binary had RUNPATH=$ORIGIN. Current launcher scripts still set LD_LIBRARY_PATH, so normal top-level CLI launches work, but any path that bypasses the wrapper can hit the linker error.
Proposed fix
Restore an Android runpath in the Rust linker flags so codex.bin and codex-exec.bin can resolve their sibling libc++_shared.so even when LD_LIBRARY_PATH is not present.
Concretely, add:
alongside the existing Android -lc++_shared link argument.
Validation
With that change applied, the rebuilt debug binary succeeds under an empty environment:
env -i PATH=/data/data/com.termux/files/usr/bin:/system/bin HOME=/data/data/com.termux/files/home ./codex-rs/target/debug/codex --version
and reports:
readelf -d on the rebuilt ELF also shows a runpath containing $ORIGIN.
Summary
On Termux, the packaged latest line can fail when Codex relaunches the native Android binary directly instead of going through the Node wrapper.
The practical symptom is that operations such as
apply_patchcan fail before doing any work with an Android linker error aboutlibc++_shared.so.Environment
@mmmbuto/codex-cli-termux@0.116.2Example failure from a Codex conversation
During an interactive Codex conversation,
apply_patchreported:That same failure pattern also appears when launching the packaged ELF directly without the wrapper-provided environment.
Direct reproduction
From the installed package, the native binary fails under a stripped environment:
Observed result:
Expected result:
Root cause
The Android ELF no longer carries a usable runpath for its bundled shared C++ runtime. Older Termux builds worked because the binary had
RUNPATH=$ORIGIN. Current launcher scripts still setLD_LIBRARY_PATH, so normal top-level CLI launches work, but any path that bypasses the wrapper can hit the linker error.Proposed fix
Restore an Android runpath in the Rust linker flags so
codex.binandcodex-exec.bincan resolve their siblinglibc++_shared.soeven whenLD_LIBRARY_PATHis not present.Concretely, add:
alongside the existing Android
-lc++_sharedlink argument.Validation
With that change applied, the rebuilt debug binary succeeds under an empty environment:
and reports:
readelf -don the rebuilt ELF also shows a runpath containing$ORIGIN.