Codex App should identify unreachable custom openai_base_url in connection-refused errors

What version of the Codex App are you using (From “About Codex” dialog)?

penAI.Codex_26.818.8289.0_x64

What subscription do you have?

Pro

What platform is your computer?

Windows 11 - 10.0.26200.9168

What issue are you seeing?

Codex Desktop on Windows repeatedly failed with:

Reconnecting /5

stream disconnected before completion: No connection could be made because the target machine actively refused it. (os error 10061)

Reconnecting... waiting for network

Connection failed: error sending request

The failure was caused by a stale custom base URL in %USERPROFILE%\.codex\config.toml:

openai_base_url = "http://127.0.0.1:8787/v1"

Nothing was listening on 127.0.0.1:8787, but Codex continued trying to connect to it. The UI only reported a generic network/reconnect error and did not indicate that the failing connection was the configured openai_base_url.

Removing the openai_base_url override and restarting Codex immediately restored normal operation.

What steps can reproduce the bug?

On Windows 11:

1. Add the following to %USERPROFILE%\.codex\config.toml:

openai_base_url = "http://127.0.0.1:8787/v1"

1. Make sure no process is listening on TCP port 8787.
2. Start/restart Codex Desktop.
3. Send any prompt.
4. Codex begins reconnecting and eventually reports:

stream disconnected before completion: No connection could be made because the target machine actively refused it. (os error 10061)

1. Find the Codex process PID and inspect its connections:

tasklist | findstr /I codex
netstat -ano | findstr <CODEX_PID>

During the failure I observed:

TCP    127.0.0.1:<ephemeral-port>    127.0.0.1:8787       SYN_SENT
TCP    <local-ip>:<ephemeral-port>   104.18.32.47:443     ESTABLISHED

I also verified that the normal Codex backend was reachable independently:

curl.exe -i -X POST https://chatgpt.com/backend-api/codex/responses

This returned:

HTTP/1.1 401 Unauthorized
{"detail":"Unauthorized"}

The 401 is expected without authentication and confirmed that DNS, TCP, TLS, and connectivity to the normal Codex backend were working.

I also confirmed there was no Windows proxy involved:

netsh winhttp show proxy

Result:

Direct access (no proxy server).

And:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable

Result:

ProxyEnable REG_DWORD 0x0

Finally, I removed:

openai_base_url = "http://127.0.0.1:8787/v1"

from config.toml, restarted Codex Desktop, and prompts immediately worked again.

Codex Desktop package observed during testing:

OpenAI.Codex_26.818.8289.0_x64

Windows build:

10.0.26200.9168

What is the expected behavior?

If a non-default openai_base_url is configured and that endpoint refuses the connection, Codex should surface that information in the error.

For example:

Unable to connect to configured OpenAI base URL:
http://127.0.0.1:8787/v1

The endpoint refused the connection. Check your openai_base_url setting in config.toml or verify that the local proxy/service is running.

Codex should not present only a generic network/reconnection error when it already knows that requests are being routed to a user-configured custom endpoint.

This would make it clear that general internet connectivity, authentication, firewall, or the OpenAI service itself may not be the problem.

Additional information

The stale openai_base_url appears to have originated from a third-party local proxy integration. I am not claiming Codex created the stale configuration.

The Codex-side issue is that the current error does not identify the actual failing destination, which makes a straightforward local endpoint failure look like a general Codex/OpenAI network outage.

The diagnostic evidence was fairly clear:

Codex -> 127.0.0.1:8787     SYN_SENT / failing
Codex -> remote :443         ESTABLISHED

while the normal chatgpt.com/backend-api/codex/responses endpoint remained reachable.

A more specific error for unreachable custom openai_base_url configurations would significantly reduce troubleshooting time