[BUG] CoWork connectors (Gmail, Slack, Calendar) lose session state — work once after toggle, fail on next session

Resolved 💬 3 comments Opened Mar 3, 2026 by emre-t808 Closed Mar 6, 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?

CoWork connectors (Gmail, Google Calendar, Slack) fail to connect in CoWork sessions despite being:

  1. Authenticated — show green/connected in Claude Desktop Settings
  2. Working in Chat — same connectors work perfectly in Chat tab
  3. Toggled ON in CoWork — connector toggles are enabled within CoWork

The connectors can be temporarily restored by toggling OFF → wait 5s → toggle ON, but they break again on the next session/chat.

Root Cause Evidence from Logs

1. RemotePluginManager skips initial sync every startup:

[RemotePluginManager] Starting remote plugins sync
[RemotePluginManager] Skipping sync: session not yet confirmed by renderer

This pattern appears on every app startup (verified across Feb 26, Feb 28, Mar 2, Mar 3).

2. When sync eventually runs, API returns 0 plugins:

[PluginsFetcher] fetchBrowsableRemotePlugins: 0 plugins (offset=0, hasMore=false)

Consistently returns 0 even though connectors are authenticated and working in Chat mode.

3. Connector MCP connections are requested but never launched:

MCP Server connection requested for: mcp-registry      ← no "Launching" follows
MCP Server connection requested for: Claude in Chrome   ← no "Launching" follows

Compare to local servers which succeed:

MCP Server connection requested for: Filesystem
Launching MCP Server: Filesystem                        ← launches successfully

4. Token/session persistence failure:

  • Toggle off/on forces fresh handshake → connectors work for ONE session
  • Next new session → fetchBrowsableRemotePlugins: 0 plugins again
  • Tokens or session state are not persisted across CoWork sessions

What Should Happen?

Connectors that are authenticated and enabled should persist across CoWork sessions without requiring manual toggle off/on before each use.

Error Messages/Logs

Key log entries from ~/Library/Logs/Claude/main.log:

# Every startup - sync skipped
2026-03-03 13:18:00 [info] [RemotePluginManager] Starting remote plugins sync
2026-03-03 13:18:00 [info] [RemotePluginManager] Skipping sync: session not yet confirmed by renderer

# When sync eventually runs - 0 plugins
[PluginsFetcher] fetchBrowsableRemotePlugins: 0 plugins (offset=0, hasMore=false)

# MCP servers requested but not launched (unlike Filesystem which launches)
MCP Server connection requested for: mcp-registry
MCP Server connection requested for: Claude in Chrome

Steps to Reproduce

  1. Open Claude Desktop with connectors (Gmail, Slack, Calendar) authenticated and green in Settings
  2. Go to Chat tab → use a connector (e.g., "Read my latest Gmail") → works
  3. Go to CoWork tab → start new session
  4. Ask CoWork to use same connector → fails (connector not available)
  5. Toggle connector OFF in CoWork settings → wait 5s → toggle ON
  6. Try again in CoWork → works for this one session
  7. Start a new CoWork session → fails again

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.1.4498

Platform

Claude.ai (Max plan, Team org)

Operating System

macOS (Apple Silicon M4 Pro, macOS 26.2.0)

Terminal/Shell

N/A (Claude Desktop native app)

Additional Information

  • This is distinct from #20377 (local MCP tools not exposed to CoWork) which was fixed — this is specifically about remote connectors (Gmail, Slack, Calendar)
  • VM boots successfully, has network connectivity, API is REACHABLE
  • MarketplacePluginManagerCLI (knowledge-work-plugins) works correctly
  • Only the RemotePluginManager fails to deliver connector state to CoWork sessions
  • Workaround: Toggle connectors off/on before each CoWork session

View original on GitHub ↗

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