codex - 💡(How to fix) Fix MCP auth/session does not refresh after successful browser login [1 comments, 2 participants]

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

Codex Desktop 26.417.40842

What subscription do you have?

Enterprise

What platform is your computer?

macOS 26.4.1 (25E253)

What issue are you seeing?

User-visible impact

• Jira MCP becomes unusable after auth/session drift.
• Successful browser login does not restore Jira access in the running app.
• Restarting Codex restores access.
• The same stale-session pattern appears to affect GitHub MCP and Confluence MCP, not only Jira MCP.

What steps can reproduce the bug?

Reproduction

1. Start Codex Desktop and use Jira MCP successfully.
2. Let the Codex app continue running long enough for MCP auth/session state to drift or expire.
3. Attempt a Jira MCP call again, for example jira_get_me.
4. Codex prompts for browser-based Okta login.
5. Complete login successfully in the browser.
6. Retry the Jira MCP call in the same Codex app session.

What is the expected behavior?

Expected

After the browser login completes, Codex should refresh the affected MCP auth/session state, recreate the Jira MCP client if needed, and the retried Jira MCP call should succeed without requiring an app restart.

Actual

• Jira MCP continues to fail in the existing Codex session.
• Restarting Codex fixes the issue immediately.
• In at least one failure path, Jira returned a misleading error string:
• Authentication required to use the GitHub MCP Server.

Additional information

Related existing issues

This problem appears to be in the same bug family as existing MCP auth-refresh issues, but it is not an exact duplicate of the reports below.

Closest match

• openai/codex#17265 - Codex does not auto-refresh routed MCP OAuth tokens even when a refresh token is stored
  • Opened April 9, 2026
  • Strong overlap: MCP auth expires, Codex does not recover automatically, tool calls fail until manual intervention

Additional related issues

• openai/codex#12755 - Your access token could not be refreshed because your refresh token was already used. Please log out and sign in again.

  • Opened February 25, 2026
  • Relevant because it specifically mentions Atlassian MCP refresh failures

• openai/codex#6498 - Refresh token was already used after session timed out

  • Opened November 11, 2025
  • Relevant because the reporter notes that closing and reopening Codex fixes the issue

Why this report is still useful

This report adds details not clearly covered by the issues above:

• The failure was observed in Codex Desktop, not just CLI-style MCP usage.
• The failure affected Jira, GitHub, and Confluence MCPs in the same app session.
• Browser login succeeded, but the running app did not recover.
• Local Codex logs showed repeated RMCP SSE decode failures during the broken state.
• Direct MCP endpoint checks showed short-lived cross_app_*_session cookies with Max-Age=600, which supports the stale long-lived client/session theory.
• Jira surfaced a misleading GitHub-specific auth error string during one failure path.

Evidence

1. Failures were not limited to Jira

During the same Codex session on May 6, 2026:

• mcp__jira__.jira_get_me failed
• mcp__github__.github_get_me failed
• mcp__confluence__.confluence_get_me failed

This suggests shared MCP auth/session state corruption or staleness, not a Jira-only integration problem.

2. Codex transport logs show repeated SSE decode failures

In ~/.codex/logs_2.sqlite, repeated warnings appeared between approximately 12:33 PM and 12:43 PM local time on May 6, 2026:

• target: rmcp::transport::common::client_side_sse
• message: sse stream error: body error: HTTP request failed: error decoding response body

The same period also shows fresh connection attempts to:

• mcp-jira.it-apps.sie.sony.com
• mcp-github.it-apps.sie.sony.com
• mcp-confluence.it-apps.sie.sony.com

This strongly suggests the running RMCP client is receiving a response body it cannot decode as a valid SSE stream and is not recovering cleanly.

3. Codex appears to load MCP keychain credentials at startup/resume, not during recovery

Earlier Codex log entries show per-server keychain accounts under the macOS keychain service Codex MCP Credentials:

• jira|<redacted>
• github|<redacted>
• confluence|<redacted>

Codex log entries on April 27, 2026 show:

• keyring.load start, service=Codex MCP Credentials, account=jira|<redacted>
• keyring.load no entry, service=Codex MCP Credentials, account=jira|<redacted>

I did not find matching keyring reload activity during the May 6 failure window, which is consistent with the running app not re-reading refreshed credentials/session state after the browser auth flow.

4. The MCP endpoints use explicitly short-lived cross-app session cookies

Direct GET requests to the MCP endpoints returned 200 OK with content-type: text/event-stream and short-lived cookies:

• Jira:
  • set-cookie: cross_app_jira_session=...; Max-Age=600
• GitHub:
  • set-cookie: cross_app_github_session=...; Max-Age=600
• Confluence:
  • set-cookie: cross_app_confluence_session=...; Max-Age=600

That Max-Age=600 means the server-side cross-app session is only 10 minutes long. A stale long-running Codex-side RMCP client that does not fully refresh would explain why browser login can succeed but the existing app process remains broken until restart.

Likely root cause

Codex appears to keep a long-lived RMCP client/session alive for MCP servers. When the MCP-side auth/session expires, the browser login flow completes, but the running Codex app does not fully invalidate and recreate the affected MCP client. Instead, it likely keeps using stale auth/session state or a stale SSE transport, causing repeated decode failures and no recovery until full app restart.

There may also be a secondary shared error-mapping bug because Jira surfaced a GitHub-specific auth message.

Suggested fixes

1. On successful browser auth callback, explicitly invalidate and recreate the affected MCP client.
2. Re-read Codex MCP Credentials after auth completion instead of only at startup/resume.
3. When RMCP sees repeated error decoding response body for an MCP SSE stream, clear per-server MCP session state and force a full reconnect/handshake.
4. Add a user-visible action such as Reconnect MCP Servers or Refresh MCP Auth so restart is not required.
5. Fix service-specific auth error mapping so Jira failures cannot surface GitHub MCP error text.

Useful local artifacts

• Codex log DB: ~/.codex/logs_2.sqlite
• Codex config: ~/.codex/config.toml
• Codex auth state: ~/.codex/auth.json

Minimal log queries

select datetime(ts,'unixepoch','localtime') as ts_local, target, feedback_log_body
from logs
where target in (
  'rmcp::transport::common::client_side_sse',
  'codex_keyring_store',
  'rmcp::service'
)
order by id desc
limit 100;

select datetime(ts,'unixepoch','localtime') as ts_local, target, feedback_log_body
from logs
where feedback_log_body like '%mcp-jira.it-apps.sie.sony.com%'
   or feedback_log_body like '%mcp-github.it-apps.sie.sony.com%'
   or feedback_log_body like '%mcp-confluence.it-apps.sie.sony.com%'
order by id desc
limit 100;