Codex Desktop loses LixRay OAuth session after update and removes MCP tools

[felixhaeberle]

Summary

A previously working LixRay MCP connection in Codex Desktop became unavailable after a desktop app update. The MCP configuration is still enabled and the LixRay endpoint is healthy, but Codex now reports the server as Not logged in and exposes no mcp__lixray__* tools.

The evidence points to a lost, invalidated, or no-longer-reused OAuth credential/refresh state rather than a LixRay service outage.

Environment

• macOS
• Codex Desktop
• Remote MCP endpoint: https://lixray.com/mcp
• OAuth scopes advertised by the resource: openid email profile offline_access
• Authorization server advertises both authorization_code and refresh_token grants
• Current bundled Browser/Codex runtime generation: 26.818.61809
• Previously working runtime generation observed in the same desktop thread: 26.803.41515

Timeline and evidence

2026-08-18: working

Codex Desktop log:

MCP server OAuth login completed name=lixray

After login, the LixRay tools were available and successfully performed:

• list_lixes
• open_lix
• query_sql
• execute_sql
• create_checkpoint

A second Codex app process later on the same day required another OAuth login and again logged:

MCP server OAuth login completed name=lixray

Between 2026-08-18 and 2026-08-24: desktop runtime changed

The packaged Codex app changed runtime/build artifacts, including the bundled browser generation from 26.803.41515 to 26.818.61809.

2026-08-26: unavailable

The configuration is unchanged:

[mcp_servers.lixray]
enabled = true
url = "https://lixray.com/mcp"

However:

$ codex mcp list
lixray  https://lixray.com/mcp  enabled  Not logged in

The agent tool catalog contains no mcp__lixray__* tools.

The endpoint is reachable and returns the expected auth challenge:

HTTP/2 401
WWW-Authenticate: Bearer resource_metadata="https://lixray.com/.well-known/oauth-protected-resource", scope="openid email profile offline_access", error="invalid_token", error_description="Sign in to LixRay to continue."
X-Request-ID: f45f5c8f-224c-4608-8258-dd1ea330f5fb
X-Railway-Request-ID: QAl-bcHIRLmUP2a_8u2xcg

The protected-resource and authorization-server metadata are reachable and internally consistent. The authorization server advertises refresh_token, and the browser session on lixray.com remains signed in.

Expected behavior

A successful MCP OAuth login requesting offline_access should survive ordinary Codex Desktop restarts and updates. If refresh fails or credentials are revoked, Codex should surface a clear reauthentication-required state instead of silently omitting all LixRay tools from the agent context.

Actual behavior

• The MCP remains configured and enabled.
• Codex reports Not logged in.
• All LixRay tools disappear from the agent tool catalog.
• The user receives no actionable reauthentication prompt during the task.

Likely failure area

One of the following appears likely:

1. Codex Desktop OAuth credentials are scoped to a runtime/app identity and are not migrated or reused after an update.
2. A refresh token is not persisted, not requested despite offline_access, or not reused.
3. Refresh-token rotation/invalidation is not handled correctly between Codex and the Supabase authorization server.
4. The server returns an invalid-token challenge correctly, but the client does not trigger an interactive reauthentication flow.

The current evidence confirms the lost authentication state, but does not prove whether the credential was lost client-side or invalidated server-side.

Reproduction outline

1. Configure LixRay as a remote Streamable HTTP MCP server.
2. Complete OAuth login.
3. Confirm LixRay tools work.
4. Restart Codex Desktop and/or install a desktop update.
5. Wait beyond the access-token lifetime.
6. Start a new agent turn that needs LixRay.
7. Observe whether the server becomes Not logged in and its tools disappear.

Suggested improvements

• Verify refresh-token issuance and rotation in server auth telemetry.
• Add a restart/update persistence test for Codex Desktop OAuth credentials.
• When an enabled MCP is unauthenticated, expose an actionable tool/status signal instead of silently removing its tools.
• Automatically prompt for reauthentication when the endpoint returns invalid_token.
• Log a sanitized reason when refresh fails: missing credential, rejected refresh token, expired token, or client-registration mismatch.

[felixhaeberle]

Update after reauthentication

Running codex mcp login lixray restores the connection:

• codex mcp list now reports lixray ... enabled OAuth.
• The complete mcp__lixray__* tool set is exposed again.
• list_lixes succeeds (request ID: 8982fdde-ea95-414a-8bff-6e86950ce897).

However, the OAuth login is now bound to a different LixRay namespace and repository ID than the previously working MCP session. The former knowledge-base repository is not listed or accessible; the newly returned repository contains only two unrelated files.

This changes the impact from a simple expired login to a possible identity-resolution / duplicate-account problem after reauthentication:

1. A working OAuth session disappears.
2. Reauthentication succeeds.
3. The same user/browser environment resolves to a different LixRay account/namespace.
4. Data from the original repository is no longer accessible through MCP.

For privacy, the public comment omits the two namespace handles and Lix UUIDs. The request ID above should allow server-side correlation. Please ask if those identifiers are needed privately.