openclaw - 💡(How to fix) Fix OpenAI Codex OAuth port conflict still opens browser to occupied localhost:1455 and produces confusing state failure

Summary

When openclaw models auth login --provider openai-codex cannot bind the fixed OpenAI Codex OAuth callback port localhost:1455, the CLI correctly falls back to manual paste and the login can still succeed. However, the UX is still confusing in current release 2026.5.4: the browser flow is still opened against redirect_uri=http://localhost:1455/auth/callback, which can be served by the unrelated process occupying port 1455. The browser then shows an OpenAI error such as Authentication Failed: Invalid or expired OAuth state.

This makes the failure look like an OpenAI account/OAuth state bug, even though the real issue is a local port conflict and manual paste works.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• Command: openclaw models auth login --provider openai-codex
• OS: macOS
• Local port conflict: 127.0.0.1:1455 occupied by BrowserOS

Observed local listener:

COMMAND    PID  USER  FD  TYPE  DEVICE  SIZE/OFF  NODE  NAME
browseros  1057 ...   18u IPv4  ...     0t0       TCP   127.0.0.1:1455 (LISTEN)

BrowserOS process:

/Applications/BrowserOS.app/Contents/Resources/BrowserOSServer/default/resources/bin/browseros_server --config=... --cdp-port=9100 --server-port=9200 --extension-port=9300

Steps to reproduce

1. Start any local process that listens on 127.0.0.1:1455.
2. Run:

openclaw models auth login --provider openai-codex

1. Open the generated OpenAI OAuth URL and complete browser sign-in.
2. Observe the browser callback and CLI behavior.

Actual behavior

The CLI detects the bind failure:

[openai-codex] Failed to bind http://127.0.0.1:1455 ( EADDRINUSE ) Falling back to manual paste.
Open: https://auth.openai.com/oauth/authorize?...&redirect_uri=http%3A%2F%2Flocalhost%3A1455%2Fauth%2Fcallback&state=...
OpenAI Codex OAuth callback did not arrive within 15000ms; switching to manual entry (callback_timeout).
Manual OAuth entry required
Paste the authorization code (or full redirect URL):

In the browser, after signing in, the callback can land on the process occupying localhost:1455, producing:

Authentication Failed
Invalid or expired OAuth state
Please close this tab and try again.

Manual paste still succeeds afterward, so this is not a total auth failure.

Expected behavior

When localhost:1455 is already occupied, OpenClaw should make the local-port conflict unambiguous and avoid leading the user into a misleading browser state failure.

Possible acceptable behavior:

• Immediately tell the user that automatic browser callback cannot work because localhost:1455 is already in use.
• Prefer prompting for manual redirect/code immediately instead of waiting 15 seconds.
• Show a suggested diagnostic command such as:

lsof -nP -iTCP:1455 -sTCP:LISTEN

• If possible, include port-owner details when available.
• Clarify that Invalid or expired OAuth state in this scenario can be caused by the callback being handled by the wrong local process.

Notes

I saw related history:

• #51896 was closed as not reproducible / resolved by freeing port 1455.
• #48592 and #47901 targeted Codex OAuth callback fallback and were closed as already implemented / incremental polish.

This report is narrower: current 2026.5.4 does fall back to manual paste and can complete login, but it still opens a browser flow that redirects to an occupied fixed callback port and produces a confusing OAuth state error. The remaining problem is diagnostics and UX, not token exchange or OAuth validity.

I am not proposing a configurable callback port here, since the redirect URI may be constrained by the registered OAuth app. A smaller fix would be clearer EADDRINUSE handling and immediate/manual-only guidance for this local conflict path.