Feature Request: Shared context between Claude Code, Chrome Extension, and Co-Work — with progressive trust

Resolved 💬 3 comments Opened Mar 18, 2026 by PMac65 Closed Apr 15, 2026

The Problem

Claude Code, the Chrome Extension, and Co-Work are three powerful tools that can't talk to each other. Each operates in isolation:

  • Claude Code has deep project context — codebase, git history, memory, architecture docs, 50+ sessions of accumulated knowledge — but can't interact with authenticated web UIs.
  • Chrome Extension can navigate and act on any website in the user's browser (Cloudflare, Vercel, Chrome Web Store, Google Workspace) — but has zero project context.
  • Co-Work can control the full desktop — but also starts fresh with no shared memory.

This means a developer who has been working with Claude Code for weeks on a project still has to manually perform every web UI task: setting DNS records in Cloudflare, configuring environment variables in Vercel, updating a Chrome Web Store listing, editing Google Workspace settings. Claude Code knows exactly what values need to go where — but can't go do it.

The Use Case

I'm building a Chrome Extension (Contact Scout). My daily workflow with Claude Code involves:

  • Writing and testing code (Claude Code is excellent at this)
  • Deploying to Vercel (npx vercel --prod — works great from terminal)
  • But then: updating CWS dashboard descriptions, configuring Cloudflare DKIM records, setting Stripe promo codes, editing Google Cloud Console OAuth settings...

For every web UI task, I have to context-switch out of our shared workflow, go click through a dashboard manually, sometimes screenshot it and paste it back so Claude can verify. The irony is Claude Code already knows the exact values — it just can't reach the browser to enter them.

The Proposal: Delegated Browser Actions with Shared Context

Allow Claude Code to delegate browser tasks to the Chrome Extension or Co-Work, with shared context:

  1. Claude Code determines what needs to happen (e.g., "Set DKIM record v=DKIM1; k=rsa; p=... for contactscout.app in Cloudflare DNS")
  2. Claude Code hands that task — with full context — to the Chrome Extension in the user's authenticated browser
  3. The Chrome Extension executes within the user's existing sessions (logged into Cloudflare, Google, etc.)
  4. Results flow back to Claude Code for verification

The user reviews and approves each step, just like they do with file edits today.

Progressive Trust / Earned Autonomy

Currently, Claude Code treats session 1 and session 50 identically. Every tool call gets the same permission prompts regardless of track record.

Consider a trust scoring system:

  • If the user consistently works within approved plans
  • If the user reviews changes before marking complete
  • If the user stays within defined scopes of work
  • If sessions show a pattern of disciplined, step-by-step collaboration

...then Claude could earn progressively more autonomy within the scope of the active plan. Not unlimited — scoped. "We agreed to update DNS records. I have the plan. I have the values. Execute steps 1-3."

This isn't about launching agents into the ether. It's about recognizing that a user who has 50 disciplined sessions of plan-driven work has demonstrated they operate responsibly — and the tool should adapt to that.

The Security Harness Is a Good Thing — At First

I want to be clear: the permission system is valuable, especially for new users. It's essentially an apprenticeship model, like the trades use for electricians and plumbers. You start by fetching tools and watching.

When I started with Claude Code in February, I hadn't used a CLI since CP/M and early DOS. That's not an exaggeration — decades. The permission prompts forced me to slow down, read what was happening, and learn:

  • First I learned to take screenshots and paste them into the conversation (a skill I'd never needed before)
  • Then I learned to read browser console output — how to find it, copy it, share it
  • Then CLI commands: git, npm test, npx vercel --prod, gh run list
  • Now I'm reviewing diffs, reading test output, understanding deployment pipelines

The security harness didn't just protect me — it taught me. Each permission prompt was a moment to understand what Claude was doing and why. That's genuinely good design for onboarding.

The frustration comes when session 50 feels identical to session 1. I've graduated from the apprenticeship. I understand the tools. I work within defined plans, review every change, and stay in scope. But the system doesn't recognize that growth. An apprentice electrician who's been on the job for a year shouldn't still be asking permission to pick up a screwdriver.

Why This Matters

The building blocks are all there: Claude Code (terminal + deep context), Chrome Extension (browser agent), Co-Work (desktop control), MCP (tool interop). The missing piece is shared memory and delegation between them.

For developers managing multi-service stacks (GitHub + Vercel + Stripe + Cloudflare + Google Cloud + Chrome Web Store), the web UI tasks are often the most tedious part of the workflow — and the part where Claude Code's knowledge is most wasted because it can't act on it.

Environment

  • Claude Code (Claude Opus 4.6, 1M context)
  • Windows 11, also Chromebook for work
  • Daily user since February 2026
  • Projects: Chrome Extension development, Vercel backend, GitHub Pages, Stripe billing, Cloudflare DNS, Google OAuth

View original on GitHub ↗

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