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)

[G7CNF]

What version of Codex is running?

codex-cli 0.56.0 (also 0.55.0)

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5-medium

What platform is your computer?

macOS 26.1 (Apple Silicon)

What issue are you seeing?

After updating to macOS 26.1 and installing Codex CLI 0.56.0 (and downgrading to 0.55.0), natural-language prompts cause Codex to return unexpected status 404 Not Found: 404 page not found. Slash commands like /status work, but any prompt such as creating a file or asking a question immediately returns this error. This happens even after clearing ~/.codex, removing the Codex keychain entry, unsetting API/proxy environment variables, and configuring web_mode=true, transport="web", model="gpt-5-medium". The issue appears specific to macOS 26.1.

What steps can reproduce the bug?

1. Use a clean shell (no virtualenv) and install Codex CLI v0.56.0 via npm (the issue also occurs with v0.55.0).
2. Delete ~/.codex and create a config with:
   web_mode = true
   transport = "web"
   model = "gpt-5-medium"
3. Run codex --model gpt-5-medium.
4. In the Codex prompt, run /status to verify the session.
5. Enter any natural-language prompt, such as "Create a file docs/hello.md containing a single line: Hello from Codex on macOS 26.1" or "one sentence about macos 26.1".

What is the expected behavior?

Codex should perform the requested natural-language action (such as creating a file or generating a sentence) and not return an unexpected 404 error.

Additional information

Versions tested: codex-cli 0.56.0 and 0.55.0 (both exhibit the issue).
Subscription: ChatGPT Plus.
Model: gpt-5-medium.
Platform: macOS 26.1 (Apple Silicon).
All API-related environment variables are unset; no proxy settings.
State cleaned by deleting ~/.codex and removing the OpenAI Codex keychain entry.

[etraut-openai]

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.

[G7CNF]

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.

[G7CNF]

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.

[etraut-openai]

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)?

[G7CNF]

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.

[G7CNF]

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).

[G7CNF]

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

[G7CNF]

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.