### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude Code's MCP HTTP OAuth layer never uses the stored refresh token. Access tokens for the Atlassian MCP (https://mcp.atlassian.com/v1/mcp) expire ro

[BUG] MCP HTTP OAuth: refresh token never used; multi-session sharing broken

Status Fixed / completed

Reported on v2.1.119

Maintainer reply None cached

Activity 5 comments · opened Apr 27, 2026 · closed May 8, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Claude Code's MCP HTTP OAuth layer never uses the stored refresh token. Access tokens for the Atlassian MCP (https://mcp.atlassian.com/v1/mcp) expire roughly every 8 hours, and instead of silently
refreshing using the refresh token already in ~/.claude/.credentials.json, Claude Code forces a full browser-based /mcp re-authentication.

This duplicates #28262 (closed as "not planned"), #44416, #18442, and #19456. Filing fresh because the closed status communicates this is acceptable behavior, and it isn't — for users on remote MCP
servers that gate real work (Jira, Notion, Linear), it's a steady tax on every working day. Atlassian fixed the server side in atlassian/atlassian-mcp-server#12; the gap is in Claude Code.

New evidence — multi-session state is also broken: today I authenticated in session A (terminal 1). Switched to session B (terminal 2, same machine) and was forced to authenticate again, even though
.credentials.json had been freshly updated by session A. Sessions appear to cache OAuth state in memory and don't re-read .credentials.json on the next failed call. So the cost scales with concurrent
sessions: I'm hitting 4–5 re-auths per week.

What Should Happen?

On token expiry, Claude Code calls the OAuth refresh endpoint using the stored refresh token, without browser interaction.
All concurrent sessions read the latest tokens from .credentials.json before failing a call.
Refreshed tokens are persisted back to .credentials.json.

Error Messages/Logs

Steps to Reproduce

Configure Atlassian MCP via claude mcp add with HTTP transport, server URL https://mcp.atlassian.com/v1/mcp.
Authenticate via /mcp in session A.
Open a second terminal with another Claude Code session (session B).
In session B, try to call any Atlassian MCP tool (e.g., searchJiraIssuesUsingJql) → "Authentication required".
Re-auth in session B. Now session A may also need re-auth on its next call.
Even with only one session: leave Claude Code idle for ~8 hours and the next call requires re-auth, despite a valid refresh token sitting in ~/.claude/.credentials.json.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Inspected ~/.claude/.credentials.json — the mcpOAuth.atlassian|<id> entry contains both accessToken and refreshToken, plus expiresAt set ~8h in the future after each fresh auth. The refresh token is
present but never used.

Bug also reproduced on 2.1.117 and 2.1.118.

Related: #28262, #44416, #18442, #19456, atlassian/atlassian-mcp-server#12.

View original on GitHub ↗

5 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

ranhailo · 4 months ago

Pushing back on the duplicate auto-close, two reasons:

1. All three cited duplicates are locked.

#21333 → closed/duplicate, locked
#28262 → closed/not_planned, locked (despite 9 👍)
#44416 → closed/duplicate, locked

There is currently no open tracker anywhere for this bug. Users cannot
react, cannot add new evidence, cannot signal that the problem persists.
Closing this issue as a duplicate of three locked issues would mean there
is literally no place left to discuss the bug. That's not triage — that's
silencing.

2. The multi-session desync is genuinely new evidence.

None of the three cited issues mention concurrent-session behavior. They
describe single-session token-expiry refresh failures. What I observed
today is distinct:

Session A re-authenticates via /mcp → .credentials.json is updated

with fresh accessToken and expiresAt ~8h in the future.

Session B (already running, separate terminal) fails its very next

Atlassian MCP call with "Authentication required" — despite valid
tokens being on disk.

Session B requires its own /mcp re-auth.

This implies in-memory token caching that isn't invalidated when
.credentials.json changes. That's a separate code path from "we never
called the refresh endpoint" (the #28262 bug). The two might share a
fix, but they are not the same bug.

Ask: keep this issue open as the live tracker for the broader
"MCP HTTP OAuth is fundamentally broken" problem, or unlock #28262
so users have somewhere to add evidence.

bhosmer-ant · 3 months ago

Fixed in v2.1.136. All MCP credential writes now go through a single cross-process lock with a fresh read under the lock, so concurrent token refreshes (multiple MCP servers, or multiple Claude Code sessions) no longer overwrite each other's rotated refresh tokens. The same change also preserves the existing refresh token when the authorization server's refresh response omits it (RFC 6749 §6).

Please reopen or file a new issue if you still see this on ≥ v2.1.136.

jpollard-cs · 2 months ago

Fixed in v2.1.136. All MCP credential writes now go through a single cross-process lock with a fresh read under the lock, so concurrent token refreshes (multiple MCP servers, or multiple Claude Code sessions) no longer overwrite each other's rotated refresh tokens. The same change also preserves the existing refresh token when the authorization server's refresh response omits it (RFC 6749 §6). Please reopen or file a new issue if you still see this on ≥ v2.1.136.

@bhosmer-ant this issue appears not to have been fixed https://github.com/anthropics/claude-code/issues/65036 please advise

github-actions[bot] · 19 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.