You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Atlassian Rovo MCP Server connector fails auth probe with HTTP 400, blocking all Atlassian tool calls #5118
The built-in Atlassian Rovo MCP Server connector is failing its authorization probe with an HTTP 400 Bad Request, and every Atlassian tool call (Jira/Confluence) returns 401 Unauthorized as a result. This is blocking an in-progress agent session that needs to edit a Confluence page.
Environment
Copilot CLI app version: 1.0.94-3
Platform: macOS
MCP server: Atlassian Rovo MCP Server (built-in/first-party connector, shown in Settings → MCP Servers as "Custom configuration")
Steps to reproduce
In an active session, call any Atlassian Rovo MCP tool, e.g. atlassianUserInfo or getAccessibleAtlassianResources.
Observe the tool call fails.
In the app UI, an authorization check also fails with a toast: "Could not check authorization" — WsCommandError: invalid argument: MCP server probe returned HTTP 400 Bad Request (screenshot captured by user in session).
Expected behavior
Tool calls to the Atlassian Rovo MCP Server should succeed (as they did earlier in the same session — multiple successful Confluence page reads/edits/creates occurred before this started).
getAccessibleAtlassianResources → {"error":true,"message":"Failed to fetch accessible resources: 401","statusCode":401}
getConfluencePage (for a previously-accessible page) → 404 Not Found (likely a downstream symptom of the same broken auth state)
The in-app connector health probe itself fails with HTTP 400 Bad Request (not 401), suggesting the probe request the client is sending is malformed or rejected before Atlassian even evaluates the token.
Troubleshooting already attempted (did not resolve)
Removed and re-added the Atlassian MCP plugin/connector 3 times, each time completing sign-in successfully.
Fully restarted the GitHub Copilot CLI app.
Removed and re-added the app sign-in itself.
Disconnected from a corporate VPN (Haivision VPN) in case it was interfering with the probe request — no change.
Connector shows as enabled/green-check in Settings → MCP Servers → Atlassian Rovo MCP Server throughout.
Retried the failing tool call repeatedly over ~15 minutes; consistently 401.
Since re-authentication (multiple times, including a full app restart, re-sign-in, and VPN disconnect) did not change the outcome, and the in-app probe reports a 400 (not a 401/expired-token-style error), this looks like a server-side or connector-level bug rather than a user credential/network issue.
Impact
Any session relying on the Atlassian Rovo MCP Server for Jira/Confluence work is fully blocked until this is resolved.
The connector started working again (confirmed via a successful atlassianUserInfo call) roughly 2 hours after the original report, without any new troubleshooting action succeeding in between.
Timeline of what was tried, for reference:
Removing/re-adding the Atlassian plugin 3x (no effect)
Restarting the Copilot CLI app (no effect)
Disconnecting from a corporate VPN (no effect)
Shutting down all other apps except GitHub Copilot — shortly after this, a retry succeeded
Root cause: Unknown. I don't have visibility into server-side connector/OAuth logs, so I can't confirm whether closing other apps actually mattered (e.g. some other process holding a conflicting local port/socket, a stale local token-refresh lock) or whether this was simply a transient issue on the Atlassian/connector backend that cleared independently around the same time. Given the in-app probe was returning a malformed-looking 400 Bad Request (not a typical 401 expired-token error) and no client-side action reliably resolved it, a transient server-side/connector-side glitch seems more likely than a local client misconfiguration — but this is not confirmed.
Closing since the connector has been working reliably since. Please reopen if this recurs with more diagnosable symptoms.
Activity
davehenk-haivision commentedon Oct 12, 2026
Update: issue resolved on its own
The connector started working again (confirmed via a successful
atlassianUserInfocall) roughly 2 hours after the original report, without any new troubleshooting action succeeding in between.Timeline of what was tried, for reference:
Root cause: Unknown. I don't have visibility into server-side connector/OAuth logs, so I can't confirm whether closing other apps actually mattered (e.g. some other process holding a conflicting local port/socket, a stale local token-refresh lock) or whether this was simply a transient issue on the Atlassian/connector backend that cleared independently around the same time. Given the in-app probe was returning a malformed-looking
400 Bad Request(not a typical401expired-token error) and no client-side action reliably resolved it, a transient server-side/connector-side glitch seems more likely than a local client misconfiguration — but this is not confirmed.Closing since the connector has been working reliably since. Please reopen if this recurs with more diagnosable symptoms.