[FEATURE] Remote Development Support for Chrome Extension

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Current Limitation

The claude-in-chrome MCP uses Chrome Native Messaging (stdio-based):

Chrome Extension → Native Messaging API → Local Native Host → Claude Code CLI

This requires Chrome to spawn a local subprocess, making remote development impossible.

Workaround Attempted

Investigated using Eclipse Che URL redirects, but Native Messaging's subprocess model prevents network-based solutions without code changes.

Labels

enhancement, chrome-extension

Proposed Solution

Add an optional WebSocket bridge mode requiring changes on both sides:

Local Browser                      Remote Container (Eclipse Che)
─────────────                      ────────────────────────────────
Chrome Extension  ──WebSocket──►   Claude Code CLI
(connects to URL)                  (exposes WS server)
                        ▲
                        │
              Eclipse Che ingress/port-forwarding

1. Claude Code CLI (server side) - Expose a WebSocket endpoint:

# When set, Claude Code starts a WebSocket server for Chrome extension connections
CLAUDE_CODE_CHROME_WS_PORT=8765
CLAUDE_CODE_CHROME_WS_HOST=0.0.0.0  # Bind to all interfaces for container access

2. Chrome Extension (client side) - Connect to remote URL instead of native messaging:

// Extension settings or popup configuration
{
  "connectionMode": "websocket",  // vs "native" (default)
  "remoteUrl": "wss://my-eclipse-che-workspace.dev/claude-ws"
}

The cloud IDE's ingress (Eclipse Che, Codespaces, Gitpot, etc.) handles routing the WebSocket connection to the container.

Alternative Solutions

A simpler UX approach using Anthropic's infrastructure as a relay:

Chrome Extension ──► Anthropic Cloud ◄── Claude Code CLI
     (local)            (relay)            (remote)
                           │
                    Paired via code
                    at account level

Flow:

1. Claude Code CLI generates a pairing code: claude pair --generate
2. User enters code in Chrome extension settings (or it syncs automatically via logged-in Anthropic account)
3. Anthropic's servers relay messages between the paired instances

Benefits of this approach:

• Zero configuration - No port forwarding, ingress, or URL setup
• Works behind firewalls - Both sides connect outbound to Anthropic
• Account-level management - Pairings managed in Anthropic dashboard
• Automatic discovery - Extension could auto-detect CLI instances on same account

Example UX:

$ claude code
# In remote Eclipse Che terminal
Claude Code started. Pairing code: ABCD-1234
Or sign in to sync automatically with your Chrome extension.

This mirrors patterns from VS Code Live Share, Tailscale, and Spotify Connect.

Benefits

1. Cloud IDE compatibility - Works with Eclipse Che, Codespaces, Gitpod, etc.
2. Secure tunneling - Can use existing IDE port forwarding/ingress
3. Consistent experience - Same browser automation features regardless of where CLI runs
4. Team environments - Developers on managed workstations can use centralized dev environments

Workaround Attempted

Investigated using Eclipse Che URL redirects, but Native Messaging's subprocess model prevents network-based solutions without code changes.

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

Use Case: Web-First Development

Many developers now work in cloud-based or containerized development environments:

• Eclipse Che / Red Hat CodeReady Workspaces
• GitHub Codespaces
• Gitpod
• AWS Cloud9
• Google Cloud Shell Editor
• VS Code Remote (SSH, Containers, WSL)

These environments run the CLI in a remote container while the developer's browser runs locally. The current Chrome Native Messaging architecture requires the native host executable to be on the same machine as Chrome, which breaks in these scenarios.

Benefits

1. Cloud IDE compatibility - Works with Eclipse Che, Codespaces, Gitpod, etc.
2. Secure tunneling - Can use existing IDE port forwarding/ingress
3. Consistent experience - Same browser automation features regardless of where CLI runs
4. Team environments - Developers on managed workstations can use centralized dev environments

Additional Context

Environment

• Claude Code running in: Eclipse Che (containerized)
• Chrome running on: Local developer machine
• Connection: Eclipse Che provides URL-based access to container services