Web search returns 503 Service Unavailable in both Codex desktop app and CLI; /feedback also fails
Open 💬 5 comments Opened Mar 27, 2026 by fffergal
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Hello, Codex wrote this report on itself when web search and /feedback stopped working for me:
I’m seeing a consistent failure of web search in both the Codex desktop app and the Codex CLI. Normal chat/model usage still works, but any web search attempt fails with 503 Service Unavailable.
I also tried submitting feedback from the CLI with /feedback, and that failed too, so I couldn’t report it from inside the product.
Date
- March 27, 2026
Affected clients
- Codex desktop app
- Codex CLI
Versions observed
- Desktop app bundle version:
26.325.21211 - Desktop bundled helper:
codex-cli 0.117.0-alpha.24 - Homebrew CLI in
PATH:codex-cli 0.116.0
Symptoms
- Any minimal web search query, e.g.
OpenAI, fails - Error returned:
503 Service Unavailable - The failing backend path appears as:
search.openai.svc.cluster.local.:8000/internal/tool_call/process
What still works
- Normal Codex chat
- Regular model access
- CLI auth appears valid
- Model list refresh and websocket model traffic still work normally
So this appears to be isolated to the web-search path rather than general auth or total service failure.
Reproduction
- Open Codex desktop app or Codex CLI
- Trigger a web search with a minimal query such as
OpenAI - Observe
503 Service Unavailable
Frequency
- 100% reproducible during this session
- Retried multiple times with the same result
Isolation already done
- Reproduces in both desktop app and CLI
- Reproduces after switching to a phone hotspot
- This makes the original local network much less likely to be the cause
Local investigation
- CLI config looked normal
- CLI auth state was populated and appeared structurally valid
- CLI could still reach core model endpoints successfully
- Desktop app had normal local app state, with no obvious local setting disabling search
- I didn’t find evidence of broad auth failures like
401or403
Additional issue
/feedbackin the CLI also failed, so I couldn’t submit an in-product report
Current best guess
This looks like one of:
- a backend outage/regression isolated to the search service
- an account-level routing/feature issue affecting search
- a client/backend compatibility issue specific to the current search path
Why I think this is not just my machine
- It affects both app and CLI
- It reproduces on a different network
- The failing host is an internal service name, which suggests the failure is behind the product edge rather than a local connectivity problem
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Based on the symptoms you're describing, it sounds like this is a network configuration or connectivity issue on your end. You'll need to do some investigation and self diagnostic.
I still suspect that too, but if it is then it is a networking issue that is being triggered by something codex does that everything else I'm using does not. I appreciate that intersections like that are hard to account for and debug, so thank you for considering it @etraut-openai.
I was hoping it might be something others have reported too (outside of GitHub issues, I checked first), or something that had changed recently (it worked earlier in the week) and you might have some pointers on where to go next with my investigation?
I noticed it's trying a .local address, I assume there is some in process name lookup that name relies on and it isn't supposed to be available through DNS or service discovery to the rest of my Mac. Is that something that has changed recently? Do they map to specific IP addresses or a range that might overlap with other things I'm using on my Mac (maybe container networking or a VPN, turning the VPN off didn't solve the problem)? On a hotspot on my phone I had the same problem, which makes it seem like it's to do with what's on my Mac, not my home network or Internet. Responses aren't affected, but search and maybe feedback are (I don't have as detailed errors for feedback), does codex do networking differently for responses verses other internal services? It says it gave a 503 response, which is different to not responding at all. Does that mean there is a gateway or proxy that is working, and it can't connect on to the actual search service? If so then I assume this proxy must be local for it to be affected by the networking on my Mac even though I can reach it.
Does any of that give a clue to how I can carry on the investigation into my network configuration, based on what you know about codex' internals?
Thanks again.
@etraut-openai after reading some of the code in this repo, I don't think this can be a my network problem anymore. There is no separate endpoint for web search, it's part of responses and is handled on the server. If I'm getting responses but web search has errors, those errors are happening on the server. Trying again today and it is working, but it wasn't for hours yesterday. Was I sticky on an impacted host so I was seeing errors while most people were not? If so, is there something I can try next time to unstick and get reallocated? I did try logging out and in while it was happening before but that didn't help.
Additional datapoint from March 31, 2026:
/feedback wss is 503did not submit feedback successfully./feedbackto create/report the issue, but the command path appears broken.This is a narrower repro than the general web-search report: the built-in issue-reporting command appears unreliable exactly when it is needed to report an issue.