codex - 💡(How to fix) Fix Authenticating with oauth protected MCP servers fails in WebIDEs

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Code Example

https://example.domain/proxy/43119/callback/<callback_id>

---

/callback/<callback_id>

---

mcp_oauth_callback_path_mode = "exact"  # default
mcp_oauth_callback_path_mode = "suffix"
RAW_BUFFERClick to expand / collapse

What issue are you seeing?

Currently Codex can advertise a non-localhost MCP OAuth callback URL via mcp_oauth_callback_url, which is needed when running Codex in a remote environment such as codeserver/WebIDE.

However, WebIDE/code-server exposes forwarded ports through a path prefix, while Codex receives the forwarded callback without that prefix. For example, Codex may advertise:

https://example.domain/proxy/43119/callback/<callback_id>

but receive:

/callback/<callback_id>

Codex currently requires the received callback path to exactly match the advertised path, so this callback is rejected.

This means it is impossible to authenticate oauth protected mcp servers when running codex on WebIDE/codeserver

What steps can reproduce the bug?

  1. Setup a codeserver/WebIDE environment.
  2. Define config for an OAuth protected MCP server in config.toml
  3. Define callback url and port for MCP server in config.toml
  4. try to authenticate with codex mcp login [NAME]
  5. new tab opens in browser window
  6. but OH NO: "This site can’t be reached"

What is the expected behavior?

New tab in browser should indicate successful authentication and when going back to codeserver tab, the MCP server authentication process in the terminal should be completed.

Additional information

This issue can be easily solved by adding a new mcp_oauth_callback_path_mode parameter with the following options.

mcp_oauth_callback_path_mode = "exact"  # default
mcp_oauth_callback_path_mode = "suffix"

exact preserves the current behavior. suffix allows the received callback path to be a suffix of the advertised path, so WebIDE/code-server proxy callbacks work while still requiring the callback id to match.

I would like to open a PR. Is that possible @etraut-openai ?

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING