›_ Codex Issues
Codex Issues / #4679

codex 0.44.0 fails under proot: prctl(PR_SET_DUMPABLE, 0) error

Resolved 💬 10 comments Opened Oct 3, 2025 by mcburgertron Closed Feb 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex version

codex 0.44.0

Model

gpt-5-codex

Platform

Linux 6.2.1-PRoot-Distro aarch64 aarch64

Steps to reproduce

  1. Run Codex 0.44.0 inside a Termux proot-distro Ubuntu 24.04 container on Android (arm64).
  2. Execute codex --version.

Minimal standalone repro for the failing syscall inside proot:

cat <<'C' > /tmp/test_prctl.c
#include <sys/prctl.h>
#include <stdio.h>
#include <errno.h>
int main(void) {
  errno = 0;
  int rc = prctl(PR_SET_DUMPABLE, 0);
  printf("rc=%d errno=%d\n", rc, errno);
  return rc;
}
C
gcc /tmp/test_prctl.c -o /tmp/test_prctl
/tmp/test_prctl

This prints rc=4 errno=0 under proot, so callers see a non-zero return and treat it as failure.

Expected behavior

codex --version should print codex-cli <version> and exit 0, as 0.42.0 does in the same environment.

Actual behavior

codex --version exits with:

ERROR: prctl(PR_SET_DUMPABLE, 0) failed: No error information (os error 0)

Additional information

  • Regression between 0.42.0 (works) and 0.44.0 (fails). The previous release never invoked PR_SET_DUMPABLE when printing the version.
  • Stock proot explicitly intercepts PR_SET_DUMPABLE so that traced processes remain dumpable; it returns the option value and leaves errno untouched. 0.44.0 now invokes this syscall and treats any non-zero return as fatal, so the CLI cannot start.
  • Local workaround: wrap /usr/local/bin/codex with an LD_PRELOAD shim that intercepts prctl(PR_SET_DUMPABLE, 0) and returns success before proot sees it. After doing so, 0.44.0 works normally again.
  • Suggestion: guard the call or downgrade it to a warning (or add a flag) so Codex keeps working in proot-based environments, which are common on Android/Termux and some CI setups.

View original on GitHub ↗

10 Comments

mcburgertron · 9 months ago

Also, codex created this issue for me. I forgot that my terminal was gh logged in so now I've made an issue!

github-actions[bot] contributor · 9 months ago

Potential duplicates detected:

  • #4197

Powered by Codex Action

cr8ivecodesmith · 9 months ago

@mcburgertron
Hey! I’ve been running into the same prctl(PR_SET_DUMPABLE, 0) issue inside a proot (Ubuntu on aarch64, Termux).
I saw you mentioned getting a shim working, and I’ve been trying to reproduce that but haven’t had much luck so far.

Here’s what I’ve tried and found:

  • The Codex CLI ends up spawning

/home/matt/.local/share/nvm/v24.10.0/lib/node_modules/@openai/codex/vendor/aarch64-unknown-linux-musl/codex/codex
which is a musl static binary.

  • Because it’s static, it ignores LD_PRELOAD, so my shim never actually loads in the process where the prctl happens.
  • I made a couple versions of the shim (hooking both prctl() and syscall(SYS_prctl)), wrapped node and codex, tried a global /etc/ld.so.preload, and confirmed with strace that the failing call is in that musl child — none of it helped.
  • There’s no glibc (aarch64-unknown-linux-gnu) build in my vendor folder, just musl.

I’m curious how you got yours working — did you happen to replace the musl helper with a glibc one, or run Codex outside proot entirely?
If there’s some trick to making LD_PRELOAD affect that static binary, I’d really love to hear it.

Thanks a ton — this thread’s been super helpful already!

mcburgertron · 9 months ago

@cr8ivecodesmith

Here's what Codex said, because Codex produced both the issue and the resolution:

Fetch the glibc helper somewhere that can run it (outside proot, another box, etc.):

curl -fsSLO https://github.com/openai/codex/releases/download/rust-v0.44.0/codex-aarch64-unknown-linux-gnu.tar.gz
tar -xzf codex-aarch64-unknown-linux-gnu.tar.gz

Copy the extracted binary into proot and install as the real helper:

install -m0755 codex-aarch64-unknown-linux-gnu /usr/local/bin/codex.real

file /usr/local/bin/codex.real must say “dynamically linked.”

Drop the shim source (adjust path if you prefer):

cat >/tmp/codex_prctl_shim.c <<'EOF'
#define _GNU_SOURCE
#include <dlfcn.h>
#include <sys/prctl.h>
EOF

On every Codex update, download the new codex-aarch64-unknown-linux-gnu.tar.gz and replace /usr/local/bin/codex.real; leave the wrapper and shim untouched.

If future releases fix the proot behavior, delete /usr/local/lib/libcodex_prctl_shim.so, rename /usr/local/bin/codex.real back to codex, and drop the wrapper.

mcburgertron · 9 months ago

Additionally, be aware that you'll see this error when Codex applies patches:

✘ Failed to apply patch
  └ failed in sandbox: ERROR: prctl(PR_SET_DUMPABLE, 0) failed: Success (os error0)

However, Codex will circumvent this without breaking.

supastishn · 9 months ago

tried this but doesnt seem to be qorking? i'm on fedora, ussd same commands but replaced 0.44.0 with 0.47.0

supastishn · 8 months ago

@mcburgertron I'm using fedora and this doesnt seem to be working

mcburgertron · 7 months ago

@supastishn Just to be sure, are you on Fedora + Arm + proot and seeing the prctl(PR_SET_DUMPABLE, 0) error?

I created a rust-script here:
https://github.com/mcburgertron/make-rust-script-do-stuff/blob/main/codex_glibc_helper_patch_install.ers

Usage with rust-script installed:
rust-script codex_glibc_helper_patch_install.ers --tag rust-v0.63.0

to address this issue on my device. I think it's reasonable for me to believe it'll work on Fedora + Arm + proot, but I have not tested it there: I use Ubuntu.

etraut-openai contributor · 4 months ago

Reviewing old (possibly stale and no-longer-relevant) bug reports. Are you still seeing this with the latest version of Codex?

mcburgertron · 4 months ago
Reviewing old (possibly stale and no-longer-relevant) bug reports. Are you still seeing this with the latest version of Codex?

Issue was resolved.