Exact error
Match the message before using the fix
configRequirements/read failed during TUI bootstrapFailed to read requirements file /etc/codex/requirements.toml: No file descriptors available (os error 24)Too many open files (os error 24)Quick answer
Start here
`os error 24` is the decisive signal: the app-server has exhausted file descriptors, even if the message names `/etc/codex/requirements.toml`. Stop the long-lived app-server cleanly and let a current Codex build start a fresh one, then inspect its effective open-file limit and child-process count. Do not create or edit the missing requirements file unless your organization actually manages one.
Diagnosis
Why it happens
- The source report measured 1022 open descriptors against a 1024 soft limit after eight days.
- Unreaped per-session MCP children accounted for most pipes and pidfds.
- The daemon can inherit a systemd session limit rather than the launching shell's `ulimit`, so changing only the shell limit may not affect it.
Safest first
Fixes, in order
Confirm descriptor exhaustion on the app-server process
Applies when: The nested error contains `os error 24` or EMFILE
The named requirements path is a misleading call site in this branch.
- Identify the long-lived `app-server --listen` process.
- Inspect `/proc/<pid>/limits` for Max open files.
- Count entries in `/proc/<pid>/fd` and record the process age.
- List child process groups without terminating unrelated processes.
pid=$(pgrep -f 'app-server --listen' | head -1)
awk '/Max open files/{print}' /proc/$pid/limits
find /proc/$pid/fd -maxdepth 1 -type l | wc -lExpected: The app-server is at or near its soft descriptor limit.
Restart only the exhausted app-server
Applies when: The process is confirmed saturated
The report recovered descriptors by terminating the daemon; use the supported manager when it owns the process.
- Save active work and close Codex clients using the daemon.
- Try the supported `codex app-server daemon restart` command.
- If Codex says the daemon is unmanaged, fully quit its owning client rather than killing arbitrary processes.
- Start Codex and confirm a fresh app-server PID and version.
Expected: The new daemon has a low descriptor count and TUI startup succeeds.
Check effective limits and version skew
Applies when: The problem returns after several days
A higher shell limit alone may not reach a detached systemd-scoped daemon.
- Compare CLI version with `codex app-server daemon version`.
- Inspect the new daemon's actual `/proc/<pid>/limits` after startup.
- Update Codex and report recurring child/descriptor growth with measurements.
- Have the system administrator adjust the user-service limit only if policy permits and the current daemon truly inherits it.
Expected: The running daemon uses the intended version and an understood descriptor limit.
Verification
Prove the fix worked
- Start the TUI and confirm configRequirements/read completes.
- Verify descriptor count is well below the soft limit after normal MCP startup.
- Open and close a test session, then confirm its MCP children are cleaned up.
Escalation
If it still fails
- Do not create `/etc/codex/requirements.toml` just because the misleading error names it.
- Do not kill every `codex` or MCP process without identifying the exhausted daemon and saving work.
- Do not assume `ulimit -n` in the shell equals the daemon's effective limit.
Scope
Environment and version notes
- The measured report used CLI 0.147.0 with a still-running 0.146.0 app-server on Ubuntu 24.04.
- Related reports cover leaked MCP pipes and per-thread server processes.
- Sources rechecked September 23, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.