[BUG] Claude Desktop Cowork: "Check your Claude in Chrome account" error persists despite correct account, working native messaging, and active socket connection

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 Desktop's Cowork mode consistently fails to connect to Chrome with the error "Check your Claude in Chrome account", even though:

1. The Chrome extension and Claude Desktop are signed in with the same account
2. The native messaging host is running correctly and creating Unix sockets
3. MCP clients are successfully connecting to the socket
4. Claude Code CLI (claude --chrome) connects to the same Chrome extension without any issues

This is NOT a race condition (Chrome is already fully loaded), and dismissing the dialog + retrying does NOT resolve it.

Environment

• macOS Darwin 24.6.0 (Apple Silicon)
• Claude Desktop: latest (as of 2026-03-20)
• Claude Code CLI: 2.1.80
• Chrome extension: v1.0.63 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn), installed in Default profile
• Chrome has 3 profiles; extension is in Default

What Should Happen?

Cowork should connect to Chrome successfully, just like Claude Code CLI does.

Diagnostic Evidence

1. Claude Code CLI works fine

With the tengu_copper_bridge=false workaround (see #24593), Claude Code CLI connects to Chrome without issues:

$ CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --chrome
# tabs_context_mcp returns available tabs successfully

2. Native messaging host is healthy

~/Library/Logs/Claude/chrome-native-host.log shows clean socket creation and successful MCP client connections — no errors:

[2026-03-20 20:25:52] Chrome native host starting (version 0.1.0)
[2026-03-20 20:25:52] Socket created successfully at: /tmp/claude-mcp-browser-bridge-rudolph/84818.sock
[2026-03-20 20:25:52] Entering main message loop
[2026-03-20 20:25:52] Socket server listening for connections
[2026-03-20 20:27:18] Accepted new MCP connection (client 1). Total clients: 1
[2026-03-20 20:27:18] MCP client 1 connected

3. Socket is active and connected

$ ls -la /tmp/claude-mcp-browser-bridge-rudolph/
srw-------  1 rudolph  wheel  0 Mar 20 20:25 84818.sock

$ lsof -U | grep claude-mcp
chrome-na 84818 rudolph  10u  unix  ...  /tmp/claude-mcp-browser-bridge-rudolph/84818.sock

The native host process (/Applications/Claude.app/Contents/Helpers/chrome-native-host) is running and connected to the Chrome extension.

4. Desktop config is correct

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "preferences": {
    "chromeExtensionEnabled": true
  }
}

5. Native messaging manifest is correct

// ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
{
  "name": "com.anthropic.claude_browser_extension",
  "path": "/Applications/Claude.app/Contents/Helpers/chrome-native-host",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"
  ]
}

What I've already tried (all failed)

• Restarting Chrome
• Restarting Claude Desktop (full Cmd+Q)
• Logging out and back in to Claude Desktop (to refresh OAuth token)
• Confirming Chrome is the default browser (it is)
• Reloading the Chrome extension
• Setting tengu_copper_bridge=false in ~/.claude.json
• Setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 via launchctl setenv for GUI apps
• Dismissing the error dialog and retrying multiple times

Root Cause Analysis

The local connection path (native messaging + Unix socket) works perfectly — both Claude Code CLI and the native host logs confirm this.

The issue is that Claude Desktop performs an account verification check via the cloud WebSocket bridge (wss://bridge.claudeusercontent.com) before allowing Cowork to use Chrome tools. This bridge verification fails (likely the same OAuth token validation bug reported in #24593), and Desktop shows the error dialog without falling back to the working local connection.

Unlike Claude Code CLI, Claude Desktop does not respect CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 or tengu_copper_bridge=false, so there is no user-side workaround for Cowork.

Suggested Fix

1. Apply the same bridge bypass that works for Claude Code CLI to Claude Desktop
2. Or: if the local socket connection is healthy, skip/defer the bridge account verification and let the connection proceed
3. Or: fix the bridge's OAuth token validation (root cause of #24593)

Related Issues

• #24593 — Same bridge token validation bug, workaround exists for CLI but not Desktop
• #33660 — Identical symptoms, closed as "not about Claude Code" without resolution
• #36620 — Similar error but attributed to race condition (cold Chrome start); this issue persists even with Chrome fully loaded
• #32132 — Intermittent variant; this issue is persistent, not intermittent