You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the detailed report and especially for the screenshots — they show the mechanism directly, so this is confirmed rather than suspected.
What is happening
On the default loopback setup, opencodex does not give Codex a separate provider. It points Codex's own built-in openai provider at the proxy, by writing a root override into %USERPROFILE%\.codex\config.toml — the three lines in your second screenshot:
model_catalog_json = "...\opencodex-catalog.json"# Auto-injected by opencodexopenai_base_url = "http://127.0.0.1:10100/v1"# Auto-injected by opencodexexperimental_realtime_ws_base_url = "http://127.0.0.1:10100/v1"
Those lines are on disk, so they survive a reboot, and Codex has no second endpoint to fall back to. Once nothing was listening on 10100, every Codex request failed — including the sign-in bootstrap, which is why you got a retry screen instead of a model error. Your reading of it was right.
Two details worth adding, because they explain why it persisted:
Applying the Codex integration does not install a background service. That is a separate ocx service install step, so after a restart there may be nothing bringing the proxy back. On Windows the scheduled task also starts at logon rather than at boot.
Deleting opencodex-catalog.json while the model_catalog_json line is still in config.toml gives you the same symptom from a second cause: Codex fails to load its configuration when that file is missing. If you removed the catalog file first, that alone would keep Codex broken even with a healthy proxy. The pointer and the routing have to go together.
Getting out of it without fixing the proxy first
There is already a command for this and it needs no running proxy, no dashboard and no network:
ocx restore
It removes the routing, the realtime override and the catalog pointer together, and Codex signs in normally afterwards. ocx restore back re-points Codex at the proxy when you want it again. The problem is that nothing told you this existed — the config file named no command, and ocx status on a stopped proxy only offered ways to restart the proxy.
Injected routing now names its own undo: # Auto-injected by opencodex (undo: ocx restore). Existing configs gain the hint on the next start, and older markers keep working.
ocx status with the proxy down now says sign-in fails too, and names the command that does not need the proxy back.
A troubleshooting page for exactly this state, including the manual edit and the warning about the catalog pointer.
I am leaving this issue open. That change removes the dead end, not every way into it: the Codex shim still discards ocx ensure failures silently and only covers the CLI rather than the Codex app, nothing revalidates the catalog pointer after injection, and Windows autostart still has no boot trigger.
What would help
All read-only, no changes to your setup:
Had you run ocx service install at any point, or only ocx init / ocx start?
In what order did it happen — did Codex break before or after opencodex-catalog.json was deleted?
For the account-pool failures, which I think are a separate problem: was the proxy running at the time, and did ocx account login openai print an error, or did the browser step fail? The browser flow needs port 1455 specifically and cannot use another one, so if something else holds it, ocx account login openai --device avoids both the browser and that port.
Output of ocx doctor if you still have the setup, with paths and identifiers redacted.
Landed on dev via #5332 (merge 9d7d7eb), which declared Closes #5261 and covers the remaining browser-launch and account-refresh visibility gaps after #5288. Merges into dev do not auto-close issues, so closing manually. Please reopen if it still reproduces on a release that contains it.
Activity
lidge-jun commentedon Sep 20, 2026
Thanks for the detailed report and especially for the screenshots — they show the mechanism directly, so this is confirmed rather than suspected.
What is happening
On the default loopback setup, opencodex does not give Codex a separate provider. It points Codex's own built-in
openaiprovider at the proxy, by writing a root override into%USERPROFILE%\.codex\config.toml— the three lines in your second screenshot:Those lines are on disk, so they survive a reboot, and Codex has no second endpoint to fall back to. Once nothing was listening on 10100, every Codex request failed — including the sign-in bootstrap, which is why you got a retry screen instead of a model error. Your reading of it was right.
Two details worth adding, because they explain why it persisted:
ocx service installstep, so after a restart there may be nothing bringing the proxy back. On Windows the scheduled task also starts at logon rather than at boot.opencodex-catalog.jsonwhile themodel_catalog_jsonline is still inconfig.tomlgives you the same symptom from a second cause: Codex fails to load its configuration when that file is missing. If you removed the catalog file first, that alone would keep Codex broken even with a healthy proxy. The pointer and the routing have to go together.Getting out of it without fixing the proxy first
There is already a command for this and it needs no running proxy, no dashboard and no network:
It removes the routing, the realtime override and the catalog pointer together, and Codex signs in normally afterwards.
ocx restore backre-points Codex at the proxy when you want it again. The problem is that nothing told you this existed — the config file named no command, andocx statuson a stopped proxy only offered ways to restart the proxy.What is changing
#5267:
# Auto-injected by opencodex (undo: ocx restore). Existing configs gain the hint on the next start, and older markers keep working.ocx statuswith the proxy down now says sign-in fails too, and names the command that does not need the proxy back.I am leaving this issue open. That change removes the dead end, not every way into it: the Codex shim still discards
ocx ensurefailures silently and only covers the CLI rather than the Codex app, nothing revalidates the catalog pointer after injection, and Windows autostart still has no boot trigger.What would help
All read-only, no changes to your setup:
ocx service installat any point, or onlyocx init/ocx start?opencodex-catalog.jsonwas deleted?ocx account login openaiprint an error, or did the browser step fail? The browser flow needs port 1455 specifically and cannot use another one, so if something else holds it,ocx account login openai --deviceavoids both the browser and that port.ocx doctorif you still have the setup, with paths and identifiers redacted.fix(codex): name the undo command in injected Codex routing
fix(cli): point a dead-proxy status report at the offline Codex restore
test(codex): pin the Codex sign-in lockout behind a stopped proxy
docs: add a troubleshooting page for a Codex lockout behind a stopped…
fix(codex): stop a stopped proxy from locking users out of Codex sign…
fix(codex): close the silent paths into a Codex lockout (#5288)
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix(oauth): say when a CLI login's browser never opened
fix(gui): stop a failed account refresh from reading as a current roster
docs(devlog): record lane R3 and correct the stale #5292 row
fix: make a failed browser launch and a failed account refresh visible (
lidge-jun commentedon Sep 23, 2026
Landed on dev via #5332 (merge 9d7d7eb), which declared Closes #5261 and covers the remaining browser-launch and account-refresh visibility gaps after #5288. Merges into dev do not auto-close issues, so closing manually. Please reopen if it still reproduces on a release that contains it.