Codex CLI on macOS 26.1 returns “unexpected status 404 Not Found” for natural-language prompts (web-auth mode; models gpt-5-medium, 0.55/0.56)

This error implies that the CLI can't reach the "responses" endpoint for model streaming. Are you logged in with ChatGPT, or are you using an API Key? If it's the former (ChatGPT), are you able to log out and log back in? That will tell us whether you're able to reach other OpenAI endpoints.

I was using API mode but hit my monthly limit and had been using web-auth mode for a couple of days (fairly light use). I completed a diff late last night (UK local time) with no issues (web-auth mode with about 20% context and 5H context at about 10%). I quit the shell which was left open in the mac overnight and instigated the mac update from 26.01 to 26.1. Started codex cli and it reported an update available. Completed this promptly and immediately hit the bug above. No amount of purging, playing with env.variables, removal and reinstall with NPM and cask have fixed it. Not seeing any issues with openai endpoints that I have tried. /status returns live metrics.

Additional diagnostics & proof (macOS 26.1, web mode, 0.56.0 / 0.55.0)

Versions & paths

which codex
codex --version
node -v
npm -v
npm prefix -g

Config & env (verbatim)

# ~/.codex/config.toml
web_mode = true
transport = "web"
model = "gpt-5-medium"
reasoning = "none"
summaries = "auto"

env | egrep -i '^(http|https|all|no)_proxy|openai' || echo 'no proxy/openai envs'

Minimal repro (clean HOME, interactive)

cd ~
codex --model gpt-5-medium
/status
one sentence about macos 26.1
# unexpected status 404 Not Found: 404 page not found

DEBUG trace of failing request

export DEBUG=codex:*,agent:*,transport:*
codex --model gpt-5-medium
/status
one sentence about macos 26.1
# Paste ~10–20 lines around the failing call here (URLs/paths ok; redact any tokens).

Control test

aider --yes -m ollama:llama3.1:8b -q "Create docs/hello_from_aider.md with a single line: Hello from Aider"
sed -n '1p' docs/hello_from_aider.md

Hypothesis
web-mode NL transport path resolves to a 404 endpoint on macOS 26.1.

I'm not familiar with web_mode or transport config options. I don't see these in the codex source. Perhaps they were supported in some older version of codex?

Please refer to the latest config documentation for supported options.

Does it work for you if you use the default config (an empty config file)?

Retested with EMPTY config (per maintainer request):

• Cleared state:

rm -rf ~/.codex && mkdir -p ~/.codex

• Launch:

codex

• /status output (key lines):

Model: gpt-5-codex (reasoning none, summaries auto)
Directory: ~/…/Chirp_Studio_Dev
Sandbox: workspace-write
Account: Plus
Codex: v0.56.0

Repro:
› one sentence about macos 26.1

Actual:
■ unexpected status 404 Not Found: 404 page not found

Conclusion: The 404 persists with an empty config (no web_mode/transport keys). This points to a transport/endpoint issue in web-auth mode for NL prompts on macOS 26.1 rather than a config parsing problem.

Happy to provide DEBUG trace if useful. Say the word and I’ll attach ~20 lines around the failing request.

Next data point:

Captured the failing NL request with DEBUG=codex:,agent:,transport:* in a clean HOME session.

Result: the NL generation attempt is POST’ing to a different endpoint than the slash commands (/status). That POST target returns 404 immediately.

This strongly suggests that the NL transport URL path resolution in Codex CLI 0.56.0 on macOS 26.1 is pointing to an invalid / unimplemented backend endpoint.

I will attach the exact endpoint path next (minus any auth material) so you can directly confirm server side.

Standby for URL only trace snippet (redacted).

Additional capture done.

I captured a full debug session (DEBUG=codex:,agent:,transport:* and NODE_DEBUG=http,https,net,tls) with script to ensure full stderr/stdout was recorded.

Environment:

• macOS 26.1
• Codex CLI v0.56.0
• clean zsh -f in HOME
• empty ~/.codex
• no proxy, no extra transport config keys

Repro (interactive):
/status → works
one sentence about macos 26.1 → unexpected status 404 Not Found
/exit → also returns 404 once NL path is hit

Attached context (~50 lines around failure) shows the failure happens immediately after NL submit and BEFORE any structured HTTP request field appears in debug, strongly suggesting this is happening at the Codex NL execution routing layer instead of being a config issue.

Log size: 67,535 bytes

codex_debug_window.txt

Update: Able to reproduce success when launching Codex outside venv/proxy env. With OPENAI_BASE_URL/OPENAI_API_BASE/HTTP(S)_PROXY/ALL_PROXY/SGPT_* unset, NL prompts work (no 404). Suggestion: CLI could warn when those env vars are set, as they silently route NL transport away from the expected endpoint. I’m using a wrapper (codex-clean) to strip them on launch.