Codex CLI fails on native Termux (Android) - authentication, request, and lock failures

@etraut-openai it doesn't seem like the issue I'm reporting is the same as https://github.com/openai/codex/issues/6757. I'm not running in proot, and I never witnessed that same error. The DNS issue I'm describing is resolved by building with a aarch64-linux-android target, and a small code change to address the locking issue

OK, reopening.

I tried the API key flow by generating an API key, then using that directly instead of the OAuth flow, which is failing. Is there any difference? Both paths provide the Codex CLI with a valid access token to communicate with the models, right?

!Image

The API key flow seemed to work, but the thing that brought this to my attention was that codex 5.3 wasn't available via API key when it first released. I'm not sure if that's still true or not.

If anyone stumbles upon this, I'm now mirroring codex releases with termux fixes applied on my fork https://github.com/wallentx/codex-termux/releases

This does not solve native Termux compatibility by itself, but it may be useful for people who mainly want a mobile/browser UI around Codex.

codexUI supports Termux and remote/browser workflows, so it is worth comparing alongside native Termux forks and patches.

GitHub:
https://github.com/friuns2/codexui

I tried to use PC Codex + SSH to troubleshoot this and reached a native Termux setup that works for me. Below is summarized by Codex and edited by me.

---

Native Termux setup:

pnpm global workspace config:

supportedArchitectures:
  os:
    - current
    - linux

On my Termux setup this file is:

~/.local/share/pnpm/global/v11/pnpm-workspace.yaml

Export PNPM_HOME from fish:

set --universal --export PNPM_HOME $HOME/.local/share/pnpm

Install/update function:

function update-codex --description 'Install/update Codex for native Termux'
    set -l v $argv[1]
    test -n "$v"; or set v (pnpm view @openai/codex version)

    command -q tinyproxy; or pkg install -y tinyproxy; or return

    pnpm add -g @openai/codex@$v; or return

    mkdir -p ~/.local/bin
    printf '%s\n' \
        '#!/data/data/com.termux/files/usr/bin/sh' \
        'set -eu' \
        'export HTTPS_PROXY=http://127.0.0.1:8888' \
        'export SSL_CERT_FILE=/data/data/com.termux/files/usr/etc/tls/cert.pem' \
        'tinyproxy' \
        'exec "$PNPM_HOME/bin/codex" "$@"' \
        > ~/.local/bin/codex
    chmod 700 ~/.local/bin/codex
    fish_add_path -m ~/.local/bin

    mkdir -p ~/.codex
    touch ~/.codex/config.toml
    grep -q '^sandbox_mode[[:space:]]*=' ~/.codex/config.toml
    and sed -i 's/^sandbox_mode[[:space:]]*=.*/sandbox_mode = "danger-full-access"/' ~/.codex/config.toml
    or echo 'sandbox_mode = "danger-full-access"' >> ~/.codex/config.toml

    codex --version
end

Generated wrapper:

#!/data/data/com.termux/files/usr/bin/sh
set -eu
export HTTPS_PROXY=http://127.0.0.1:8888
export SSL_CERT_FILE=/data/data/com.termux/files/usr/etc/tls/cert.pem
tinyproxy
exec "$PNPM_HOME/bin/codex" "$@"

Run:

update-codex
codex

Why these pieces are needed:

• @openai/codex is the direct global package, so pnpm update -Lg works.
• supportedArchitectures.os = [current, linux] makes pnpm install Codex's Linux optional dependency on native Termux.
• The wrapper executes pnpm's Codex shim through PNPM_HOME, which avoids recursion through ~/.local/bin/codex.
• tinyproxy makes HTTPS traffic resolve through Termux's networking path.
• SSL_CERT_FILE=$PREFIX/etc/tls/cert.pem gives the Linux Codex binary the Termux CA bundle.
• sandbox_mode = "danger-full-access" avoids the Linux sandbox path, which does not work in native Termux.

What does not work:

• Installing @openai/codex-linux-arm64@npm:@openai/codex... as the direct global package breaks pnpm update -Lg; pnpm later resolves the alias name as a registry package and gets a 404.
• Hard-coding or searching for the vendored Codex binary path ties the wrapper to pnpm's internal global layout.
• exec codex "$@" inside ~/.local/bin/codex recurses when ~/.local/bin appears before pnpm's bin directory on PATH.
• proot bind-mounting $PREFIX/etc/resolv.conf into /etc/resolv.conf fixes DNS, but it made live tool-call reaction latency much worse in my Termux session.
• In a six-consecutive-date tool-call test, I saw roughly:
• proot -> native codex: about 39s average gap;
• tinyproxy + direct native codex: about 10s average gap;
• a Linux reference machine: about 3s average gap.
• libresolv-wrapper did not fix the request failure in my test.
• proxychains-ng relies on LD_PRELOAD, which does not fit the shipped Linux/musl Codex binary running under native Termux.

Verified on my current Termux global packages:

@openai/codex 0.141.0
ctx7 0.5.3
pnpm 11.8.0

codex --version reports:

codex-cli 0.141.0

wish i'd seen this sooner and not spend tokens, had the same issue and used codex cli macOS + adb to troubleshoot and fix.
workaround was to run codex through proot with a bound /etc/resolv.conf, plus CODEX_CA_CERTIFICATE=$PREFIX/etc/tls/cert.pem

@onlyoneuche

Have you checked Codex’s response speed when calling tools while using Proot? I tried the proot workaround, but it seems to affect Codex’s receipt of notifications that external tool execution has finished. As a result, every tool call, regardless of how long it actually takes, makes Codex wait for around 40 seconds until Codex actively checks whether the tool is still running before continuing. This is very undesirable, so I used the tinyproxy method to solve the DNS resolution issue. You can see my reply above.

just to clarify, I'm automatically mirroring every codex release here with termux fixes applied. I'm doing the same with antigravity-cli, opencode, and claude-code. so if you are running termux and want these working, you can use the artifact from any of my releases, and auto update pulls from my fork.