[BUG] Custom MCP connector loses OAuth authentication after ~1-2 hours (refresh token not used)

Resolved 💬 3 comments Opened Mar 21, 2026 by dmcgurie2500 Closed Mar 24, 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?

Custom MCP connectors using OAuth (Softeria ms-365-mcp-server deployed on Railway via HTTP transport) lose authentication after approximately 1-2 hours of active use in Cowork sessions.

The connector status changes from "connected" to "needs authentication" and requires manual reconnection through the Cowork MCP settings.

This suggests the OAuth refresh token is either not being stored by Cowork or not being used to obtain new access tokens when the Microsoft access token expires (~1 hour lifetime).

Setup:

  • 3 separate Railway-hosted instances of Softeria ms-365-mcp-server (HTTP transport mode)
  • Azure AD app registration (public client, multi-tenant)
  • Each instance authenticated to a different Microsoft 365 account
  • All 3 connectors exhibit the same timeout behavior
  • Railway Serverless mode is OFF on all instances (containers stay running)

Reference IDs from failed auth attempts:

  • ofid_71babd202083b466
  • ofid_0731cb7fbdd0e08a

Expected behavior: Cowork should silently use the OAuth refresh token to obtain a new access token when the current one expires, keeping the connector connected indefinitely.

Actual behavior: After ~1-2 hours the connector drops to "needs authentication" status, requiring manual re-auth each time.

What Should Happen?

Cowork should silently use the OAuth refresh token to obtain a new access token when the current one expires (~1 hour for Microsoft). The custom MCP connector should remain connected indefinitely without requiring manual re-authentication.

Error Messages/Logs

Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: "ofid_71babd202083b466"

Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: "ofid_0731cb7fbdd0e08a"

Steps to Reproduce

  1. Deploy Softeria ms-365-mcp-server to Railway with HTTP transport mode (node dist/index.js --http --enable-dynamic-registration)
  2. Register an Azure AD app (public client, multi-tenant) and configure OAuth redirect URIs
  3. Add the server as a Custom Connector in Cowork (Settings > MCP Servers > Add Custom Connector)
  4. Complete OAuth authentication — connector shows "connected"
  5. Use the connector actively for ~1-2 hours (reading emails, calendar, etc.)
  6. After ~1-2 hours, the connector status changes to "needs authentication"
  7. Must manually reconnect through Cowork MCP settings to restore access

Note: Railway Serverless mode is OFF — containers stay running. The issue is not container restarts. The MCP server itself remains accessible; it's the OAuth token that expires and is not refreshed by Cowork.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.81 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗