Chrome MCP never starts in VS Code extension — experimentGates.tengu_quiet_fern not populated

Resolved 💬 3 comments Opened Mar 25, 2026 by Audacity88 Closed Apr 24, 2026

Description

The Chrome browser MCP (@browser) never starts in the Cursor VS Code extension because of two issues: --no-chrome is hardcoded in extraArgs, and isBrowserIntegrationSupported() checks this.experimentGates.tengu_quiet_fern, which is never populated in the extension's globalState.

This is a different issue from the many "Browser extension is not connected" reports (#37027, #33022, #35675, etc.) — in those cases the MCP server starts but fails to connect. Here, the MCP server is never spawned at all.

This may be Cursor-specific — the experiment gates delivery mechanism may work correctly in VS Code proper but not in Cursor.

Root Cause

Two things prevent the Chrome MCP from starting:

1. --no-chrome hardcoded in extension.js

The extension passes "no-chrome":null in extraArgs when spawning the Claude process, which disables Chrome integration entirely.

2. Experiment gate not delivered

Even with --no-chrome removed, isBrowserIntegrationSupported() blocks the MCP:

isBrowserIntegrationSupported() {
  return this.authManager.getAuthStatus()?.authMethod === "claudeai"
    && !!this.experimentGates.tengu_quiet_fern
}

experimentGates is initialized from context.globalState.get("experimentGates") || {} and updated at runtime via onExperimentGatesUpdated(). However, the tengu_quiet_fern flag is never delivered to the extension's globalState in Cursor, even though it exists in ~/.claude.json's cachedGrowthBookFeatures.

Because the gate returns false:

  • The extension never calls getChromeMcpServerConfig() to spawn --claude-in-chrome-mcp
  • @browser is silently unavailable with no error shown to the user

Environment

  • Claude Code extension version: 2.1.83
  • Host editor: Cursor (may not reproduce in VS Code proper)
  • OS: macOS Darwin 21.6.0
  • Chrome extension: installed, paired, onboarding completed
  • Auth: claude.ai OAuth (authMethod === "claudeai")
  • ~/.claude.json confirms: cachedChromeExtensionInstalled: true, claudeInChromeDefaultEnabled: true, hasCompletedClaudeInChromeOnboarding: true, chromeExtension.pairedDeviceId set

Workaround

Three steps required:

1. Remove --no-chrome from extension.js

Find "no-chrome":null in extraArgs and remove it.

2. Patch extension.js to remove the experiment gate:

Find:

isBrowserIntegrationSupported(){return this.authManager.getAuthStatus()?.authMethod==="claudeai"&&!!this.experimentGates.tengu_quiet_fern}

Replace with:

isBrowserIntegrationSupported(){return this.authManager.getAuthStatus()?.authMethod==="claudeai"}

3. Register the MCP server manually (since the extension's internal registration under the reserved name claude-in-chrome still doesn't trigger):

claude mcp add chrome-browser -- ~/.local/share/claude/versions/<version> --claude-in-chrome-mcp

Then reload the editor window. All three steps are needed.

Expected Behavior

If Chrome pairing is complete, auth is valid, and claudeInChromeDefaultEnabled is true, the Chrome MCP should be available in the extension without requiring workarounds.

Notes

  • Extension updates overwrite the extension.js patches, requiring re-application
  • The workaround's manual MCP registration persists in ~/.claude.json but the version-specific path needs updating on CLI upgrades

View original on GitHub ↗

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