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

[wallentx]

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Plus

Which model were you using?

All

What platform is your computer?

Linux 6.1.145-android14-11-gb812b232b095-ab14605088 aarch64 unknown

What terminal emulator and version are you using (if applicable)?

Termux 0.119.0-beta.3

What issue are you seeing?

Codex CLI does not function correctly on **native Termux / Android**. There are multiple related failure modes.

---

### 1) Authentication fails

Both authentication flows fail:

- **Sign in with ChatGPT**
- **Sign in with Device Code**

The failure manifests as:

`Stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)`

`strace` indicates resolver-related activity and DNS traffic toward `127.0.0.1:53`. This environment does not provide a traditional `/etc/resolv.conf`, which is typical for Android.

Because authentication fails, Codex cannot complete the initial login flow on Termux.

#### Workaround

If `~/.codex/auth.json` is generated on another system and copied into Termux, authentication succeeds.
Similarly, if `auth.json` was created previously, Codex can start.

However:

Once a valid `auth.json` is present, the same request failure appears during interactive use (e.g. `codex exec "hello"` or starting a session).

So the resolver issue affects both:
- authentication
- normal request execution

---

### 2) Startup lock errors (non-fatal)

On startup, Codex emits lock-related errors consistent with file-lock operations not being supported in this environment. The errors are of the form:

`std::fs::TryLockError::Error(err)` where `err.kind() == std::io::ErrorKind::Unsupported`

Importantly:

- These errors do **not** crash the application.
- Codex continues running.
- No obvious functionality appears broken solely due to these startup lock errors.

---

### 3) Session preference does not persist when pressing `p`

When Codex prompts for permission to perform an action, it offers an option to press `p` to auto-accept for the rest of the session.

On Termux:

- Pressing `p` triggers the same lock-related failure.
- The preference does not persist.
- Codex continues prompting instead of remembering the choice.

This appears related to the unsupported lock behavior described above.\

What steps can reproduce the bug?

Authentication failure path

1. Use Android + Termux (native Termux; no proot/chroot).
2. Install and run Codex CLI.
3. Attempt either:

• "Sign in with ChatGPT"
• "Sign in with Device Code"

4. Observe request failure:
   Stream disconnected before completion: error sending request for url (...)

Optional:

• Run strace and observe resolver-related calls / DNS attempts toward 127.0.0.1:53.

---

Interactive failure path (after auth workaround)

1. Copy a valid ~/.codex/auth.json from another system into Termux.
2. Run codex exec "hello" or start an interactive session.
3. Observe the same request failure described above.

---

Lock persistence failure path

If you manage to work around the DNS issues - i.e. have root access and are able to make a /etc/resolv.conf:

1. Use Android + Termux.
2. Run Codex CLI until a permission prompt appears.
3. Press p to auto-accept for the rest of the session.
4. Observe lock-related error(s) and that the preference does not persist.

What is the expected behavior?

Codex CLI should function on native Termux/Android, including:

• Successful authentication.
• Successful request execution.
• No lock-related errors on startup.
• Session-level preference toggles (like “auto-accept for rest of session”) should work or degrade gracefully.

Additional information

• I have successfully implemented changes locally that allow Codex CLI to run correctly on Termux. There were a few additional Android-specific adjustments required beyond the issues described above.
• Since docs/contributing.md indicates external PRs are invitation-only, I’m reporting this first. I’m happy to open a PR if invited, as I've already got one drafted against my fork here Fix Termux/Android compatibility issues (DNS, locking, Android target support) wallentx/codex-termux#5
• A working Termux build is available here https://github.com/wallentx/codex/actions/runs/22006539253

[wallentx]

@etraut-openai it doesn't seem like the issue I'm reporting is the same as #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

[etraut-openai]

OK, reopening.

[wiilwaalka]

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?

[wallentx]

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.

[wallentx]

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

[friuns2]

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