用Codex配置完opencodex后无法调用模型，重启后无法登录

[Wh1tZz]

Client or integration

Codex App

Area

CLI

Summary

我用codex帮我配置了opencodex，添加号池一直失败，之后我在codex内就无法调用模型了，起初我以为是codex的问题，重启后发现无法正常登录了，后来经过审查分析后，发现opencodex 之前把 Codex 的所有请求都劫持到它自己的本地代理（端口 10100），导致卡死，所有的附图均已上传

Reproduction

无法正常配置号池，添加帐号也无法正常显示

Version

2.59.0

Operating system

win11

Provider and model

No response

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

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 opencodex
openai_base_url = "http://127.0.0.1:10100/v1"
# Auto-injected by opencodex
experimental_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.

What is changing

#5267:

• 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:

1. Had you run ocx service install at any point, or only ocx init / ocx start?
2. In what order did it happen — did Codex break before or after opencodex-catalog.json was deleted?
3. 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.
4. Output of ocx doctor if you still have the setup, with paths and identifiers redacted.