›_ Codex Issues
Codex Issues / #13852

Supabase MCP repeatedly requires reauthentication: OAuth token refresh failed during initialize

Open 💬 16 comments Opened Mar 7, 2026 by markussmueller
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.111.0

What subscription do you have?

Unknown

Which model were you using?

Unknown

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty

What issue are you seeing?

My Supabase MCP integration seems to require reauthentication repeatedly.

After previously authenticating Supabase MCP, Codex sometimes starts with this error instead of refreshing the existing auth session:

⚠ MCP client for `supabase` failed to start: MCP startup failed: handshaking with MCP server
  failed: Send message error Transport
  [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttp
  ClientWorker<rmcp::transport::auth::AuthClient<reqwest::async_impl::client::Client>>>] error:
  Auth error: OAuth token refresh failed: Failed to parse server response, when send initialize
  request

⚠ MCP startup incomplete (failed: supabase)

The practical result is that I have to authenticate Supabase again and again, even though the expected behavior seems to be token refresh or stable session reuse.

What steps can reproduce the bug?

  1. Configure the Supabase MCP server in Codex CLI and authenticate it successfully.
  2. Use Codex normally for some time, or return in a later session after the auth/token has aged.
  3. Start Codex again.
  4. Observe that Supabase MCP sometimes fails during startup with the refresh/initialize error above.
  5. Reauthenticate Supabase MCP to get it working again, until the cycle repeats.

I have not pinned down a minimal deterministic repro beyond the repeated pattern above.

What is the expected behavior?

If the stored auth session is still refreshable, Codex should refresh it successfully and start the Supabase MCP server without manual intervention.

If the auth session is invalid, Codex should report that clearly rather than failing during MCP initialize with a parse error.

Additional information

This looks related to the broader MCP OAuth / handshake issues that have been reported before, but I could not find an existing issue with this exact Supabase error string.

Potentially related reports:

  • #5254
  • #6020
  • #6572
  • #9535
  • #11297

The key detail here is the combination of:

  • Supabase MCP
  • repeated reauthentication requirement
  • OAuth token refresh failed
  • Failed to parse server response
  • failure while sending the MCP initialize request

If maintainers want, I can provide more environment details or try with additional logging enabled.

View original on GitHub ↗

16 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #12285
  • #13766

Powered by Codex Action

markussmueller · 5 months ago

I reviewed the bot suggestions and I don't think either is a true duplicate:

  • #12285 was a Snowflake streamable_http initialize/response-decoding issue using a PAT, and it was closed in favor of #11284 (Cannot initialize Streamable HTTP MCP servers). That looks like a broader transport compatibility problem, but not specifically an OAuth refresh / repeated reauthentication failure.
  • #13766 is a local Dart MCP server handshake timeout on stdio. Different transport and different failure mode.

This issue is specifically about Supabase MCP auth refresh failing during startup:

Auth error: OAuth token refresh failed: Failed to parse server response, when send initialize request

The distinctive behavior here is that Supabase appears to require repeated manual reauthentication instead of refreshing the stored auth session.

So there may be some shared initialize/handshake surface area, but I don't think this should be closed as a duplicate of either suggested issue.

markussmueller · 5 months ago

Additional data point: I previously contacted Supabase support about this, and they indicated they believe this is on the Codex side rather than the Supabase side.

They specifically pointed me to #6020 as a related Codex MCP startup/handshake issue affecting other MCP servers as well.

I still don't think this issue is a strict duplicate of #6020, because the observable failure here is specifically:

Auth error: OAuth token refresh failed: Failed to parse server response, when send initialize request

and the user-facing behavior is repeated manual reauthentication for Supabase.

But this does seem like more evidence that the root cause may live in the Codex MCP client / rmcp auth+initialize path rather than in Supabase alone.

thedaviddias · 5 months ago

Faced the issue today where:

  • /mcp shows that Supabase MCP is enabled
  • but Codex says "OAuth token refresh failed: Failed to parse server response"
  • restarting, enabling/disabling the supabase MCP in the settings didn't trigger the auth window

Compared to other tools like Claude Code, the experience is really not great. Codex should trigger opening the auth page if the token needs to be refreshed.

gabrieuz · 5 months ago

codex mcp login supabase solve the problem to me.

venkat0304 · 3 months ago

I am running below command every other day to authenticate with supabase. But, on claude code i connected like a 2 months back and its still working. Wondering how to make the connection work without breaking.

codex mcp login supabase

ID 019e0e56-91e1-7932-ab6c-2953ce75cee6

alexgshaw · 3 months ago

Also running into this issue

jmo-sg · 3 months ago

This issue affects me and I use both Codex and Claude. I often have to restart Codex after manual reauthentication which is a real time waster. Claude does not suffer this issue.

Starvingg · 3 months ago

Any update on this issue? The MCP Server connection is buggy. Sometimes it works if explicitly asked. But if Codex gives me a plan with Supabase as a consideration, it should run the Migration file that was created.

jcarioti · 3 months ago

Still having this same issue with multiple OAuth MCP servers, not just Supabase.

Codex is simply not handling OAuth refresh properly. Seems pretty clear from all of the related reports.

zeevenn · 1 month ago

some issue

mvjpalsson · 1 month ago

Same issue. Claude doesnt' have this issue, only Codex/ChatGPT in my experience.

hemao612 · 1 month ago

Same issue. Claude doesnt' have this issue, only Codex/ChatGPT in my experience.

StillNotYet · 1 month ago

Confirmed still reproducible in Codex Desktop on macOS 26.5.2 arm64 with the bundled codex-cli 0.146.0-alpha.3.1.

I reproduced this through the app-server MCP status path after the stored Supabase OAuth token had expired. The relevant logs are:

MCP OAuth refresh failed; reauthorization required by RMCP compatibility policy
OAuth token refresh failed: Failed to parse server response
failed to refresh OAuth tokens for server supabase
refresh_reason: expiry

The resulting Supabase MCP status had authStatus oAuth, with no serverInfo and no tools loaded.

The remote Supabase MCP is project-scoped and configured with read_only=true. No new login was initiated during this diagnostic. The stored OAuth credentials were found and a refresh was attempted, but the refresh response failed to parse. This indicates that the issue persists beyond 0.111.0 and is not simply caused by credentials failing to persist locally.

m13v · 1 month ago

the 'just reauth on refresh failure' path is where a retryable error goes quiet. Failed to parse server response during initialize is a transport/bad-body problem, not proof the session is invalid, but if refresh treats any failure as auth-dead it drops a still-refreshable token and surfaces 'reauthenticate' as the handled state. so the loud retryable case gets laundered into the quiet 'session expired' one and you can't tell which actually happened. logging the refresh http status separately from the parse step, before deciding to drop the token, is what keeps the two apart.

azolotov · 28 days ago

Additional data point from July 30, 2026: this is still reproducible with codex-cli 0.146.0 on Darwin 25.5.0 arm64, and in my case reauthentication did not restore the MCP even for a fresh startup.

I tested a custom MCP server protected by Supabase OAuth 2.1:

  1. Ran codex mcp logout <server>.
  2. Ran codex mcp login <server> and completed the browser flow successfully.
  3. Confirmed that the Codex MCP Credentials Keychain item was updated.
  4. Started a fresh Codex session four seconds later.

The startup logs show that Codex successfully loaded the newly updated credential:

keyring.load success, service=Codex MCP Credentials

It then immediately failed:

failed to refresh OAuth tokens for server <server>:
OAuth token refresh failed: Failed to parse server response

The MCP request subsequently returned 401 with No authorization provided, and Codex omitted the server entirely—no tools were loaded. The message is presented as a startup warning, but the MCP is actually unavailable.

I also confirmed that both the protected-resource metadata and Supabase authorization-server metadata endpoints return HTTP 200 with valid JSON. Discovery succeeds and advertises the standard Supabase /auth/v1/oauth/token endpoint with refresh_token support.

So this does not appear to be only an aged or missing credential: a newly issued credential is loaded successfully, then immediately enters the refresh path and fails to parse the response. Repeating logout / login does not resolve it.