[FEATURE] Unified cross-context authorization — allow Claude Code to share browser and app integration context with the Claude browser plugin

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

Claude's ecosystem has several powerful, well-functioning integrations — Claude Code (deep local system access), the Claude browser plugin (Chrome context, live page interaction), and various app integrations (Google Workspace, etc.). Each works well in isolation.

The problem is they are completely siloed. Claude Code cannot see or interact with browser context, even when the user has already granted authorization to the browser plugin. The app integrations similarly exist only within their own bubble. As a result, the user becomes the sole integration layer — manually shuttling context, outputs, and state between different Claude instances throughout the day.

This is the opposite of what an agentic assistant should require. A real workflow might involve: reading a Gemini conversation in the browser, downloading assets, organizing files locally, updating a Google Sheet, and committing to GitHub — all steps that Claude's various integrations could theoretically handle, but only if they could share a session and trust context. Today that requires constant manual handoff between separate Claude contexts, breaking flow and creating exactly the kind of fragmented productivity the product is meant to solve.

Proposed Solution

Introduce a unified authorization model across Claude's integrations that allows a trusted session to share context across Claude Code, the browser plugin, and connected app integrations (Google Workspace, GitHub, etc.) when the user has explicitly granted permission.

Concretely:

• Claude Code should be able to request and receive browser context from an active Claude browser plugin session (active tab, page content, DOM state) when the user has authorized the plugin
• - The same authorization token/session that grants the browser plugin access to Chrome should be recognizable by Claude Code
• - - App integrations the user has connected (e.g. Google Drive, Sheets, GitHub) should be accessible from within a Claude Code session under the same authorization umbrella
• - - - The user should be able to define a trust scope once (e.g. "Claude Code may access my browser plugin context and connected apps") rather than re-establishing context manually each time

The implementation doesn't need to be a new product — it could be as simple as Claude Code gaining a --with-browser flag or a hooks-based mechanism that bridges the plugin session.

Alternative Solutions

Current workaround: manually copy-paste context between Claude Code sessions and browser plugin sessions. This is error-prone, breaks flow, and negates the productivity benefits of having both tools.

Alternative considered: running Claude Code inside a browser-based environment — but this would sacrifice the deep local system access that makes Claude Code valuable.

The real gap is architectural: there's no shared trust layer. Other agentic tools (e.g. some Cursor integrations, certain Copilot workflows) solve this by allowing the agent runtime to consume OAuth tokens or session context from companion browser extensions. A similar approach here seems feasible without a full product redesign.

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

Real workflow that prompted this request (today, March 19 2026):

1. I asked the Claude browser plugin to generate a batch of ~27 images in a Gemini conversation and download them
2. The plugin handled the browser interaction well — but the session was cut off mid-task (see bug #36379 3. In the new session, the agent had no memory of which images had been downloaded, which folder they belonged in, or what the project structure was — because that context lived in Claude Code, not the browser plugin
3. I had to manually reconstruct the state and tell the agent where to put the files

With unified context, the agent would have known: "these images belong in /project/assets/characters/ — I already downloaded images 1–3, I need images 4. still, and here's the file naming convention from the project." That's one continuous task, not a fragmented relay race between two separate Claude instances with me as the baton.

Additional Context

This request is closely related to the MCP (Model Context Protocol) architecture — the right solution might be an MCP server that bridges the browser plugin's session context into Claude Code, rather than a deep architectural change.

Related issues filed by same user:

• #34013 — Agent should have visibility into token usage and context cap proximity
• - #36398 — Session hard-stopped at ~3% usage with no warning

The context fragmentation problem compounds every time there's a hard stop (see #36398) — because on restart, not only is the billing context lost, but all cross-tool state is also gone. Fixing the silo problem would make session continuity dramatically more recoverable.

Anthropic has already done the hard work: the browser plugin works, Claude Code works, app integrations work. The missing piece is a trust bridge between them that respects user authorization.