Skip to content

Atlassian Rovo MCP Server connector fails auth probe with HTTP 400, blocking all Atlassian tool calls #5118

Description

@davehenk-haivision

Summary

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

  1. In an active session, call any Atlassian Rovo MCP tool, e.g. atlassianUserInfo or getAccessibleAtlassianResources.
  2. Observe the tool call fails.
  3. 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).

Actual behavior

  • atlassianUserInfo → {"code":401,"message":"Unauthorized"}
  • 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.

Activity

  1. added
    area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry
    on Oct 12, 2026
  2. davehenk-haivision commented on Oct 12, 2026

    @davehenk-haivision
    Author

    Update: issue resolved on its own

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions