[FEATURE] Session bridge: CLI/VS Code → Chrome Extension with shared context

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

When working in CLI or VS Code, there's no way to hand off the current session to the Chrome Extension mid-task. If I'm building a feature and need to test something in the browser — fill a form, check a UI state, debug a network request — I have to open the Chrome Extension as a completely new session and re-explain all the context from scratch.

This breaks flow on tasks that naturally span code and browser:

1. I'm debugging an API endpoint in CLI — Claude has full context of the codebase, the bug, and the fix I'm testing
2. I need to verify the fix works in the actual browser (with my real cookies, auth state, logged-in session)
3. I open Claude in Chrome → new session → "So I was working on this endpoint, the bug was X, I just pushed a fix, can you navigate to Y and check if Z works now?"
4. I've just re-briefed Claude on 20 minutes of context it already had

This happens multiple times per day for full-stack work.

Proposed Solution

Allow a CLI or VS Code session to bridge to the Chrome Extension while preserving the conversation context:

CLI session (code context) → bridge → Chrome Extension (same context + browser control)

The CLI keeps handling code. The Chrome Extension adds native browser capabilities. But they share one conversation — no context lost.

Why This Is Different from MCP Browser Tools

MCP tools like Playwright and Chrome DevTools MCP can control browsers, but they run headless or via proxy. The Chrome Extension has something they don't:

• Real user session — cookies, auth tokens, logged-in state
• Native browser context — the actual page the user is looking at
• No proxy setup — works with any site, including ones behind SSO/VPN
• Visual interaction — the user sees what Claude is doing in real-time

MCP browser tools are great for automated testing. The Chrome Extension is for interactive, user-session-aware browser work. Bridging the CLI to the extension would combine code-level power with browser-level access.

Alternative Solutions

• Manually copy context to a new Chrome Extension session (current workaround — painful)
• Use MCP browser tools from CLI (works but loses real user session/cookies)
• Use /remote to continue from Claude app (doesn't have browser control capabilities)

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. Working in CLI: "Fix the login redirect bug in /api/auth/callback"
2. Claude identifies the issue, I push the fix
3. I say: "Bridge to browser — navigate to the login page and test the OAuth flow with my real Google account"
4. Chrome Extension picks up the same session, opens the login page, walks through the flow
5. Reports back: "Redirect works correctly now, landed on /dashboard with session cookie set"
6. I continue in CLI: "Great, now write a test for this flow"

All in one continuous conversation.

Additional Context

Related but different:

• #35888 — Programmatic tab spawning (VS Code tabs, not browser)
• #11455 — Session handoff between CLI sessions (not CLI → browser)
• #37345 — CLI-as-remote-control-client (terminal → terminal, not terminal → browser)

This request is specifically about bridging CLI/VS Code sessions to the Chrome Extension with shared context and the extension's native browser capabilities.