Claude Code to Claude for Chrome: the handoff pattern

Eight sender mailboxes. Eight custom SMTP profiles. Your terminal session knows the project folder, the CLAUDE.md, the file layout, the half-finished spreadsheet from yesterday. Claude Code can describe the work in detail. It just cannot reach your browser to do it.

Claude Code can’t click.

That’s the wall.

It can write a script that clicks. It can describe what clicking would do. What it cannot do is open a Chrome tab and interact with a UI on its own. So what now?

Three Claude products, one model brain

The map is shorter than people think.

Claude Code runs in your terminal. It walks the parent directories of wherever you opened it, reads CLAUDE.md files, holds onto an hour of accumulated context, executes shell commands, and reaches the web through plain HTTP fetches. It’s the developer-and-operator surface. No browser, no mouse, no DOM access. By design.

Claude Desktop is the GUI app. Inside Desktop you find Connectors for Microsoft 365, Salesforce, Google Drive, and a directory of extensions Anthropic has built. One extension is called Control Chrome. It uses Chrome’s AppleScript API to drive the local browser, which means macOS only. A Windows user who opens the same directory sees “This extension requires Mac OS” next to the install button. Annoying if your laptop runs Windows.

Claude for Chrome is the separate piece. A Chrome Web Store extension Dario Amodei’s Anthropic ships at the Claude listing on the Chrome Web Store. It installs into Chrome or Edge - Edge accepts Chrome Web Store extensions natively, which matters if your IT team blocked Chrome on corporate laptops. Once installed, the extension lives as a side panel, reads the active tab’s DOM, and drives the browser via mouse-and-keyboard actions when you ask it to. Anthropic’s own write-up of the extension covers the threat-model decisions and the rollout shape. The Hacker News discussion on launch day collected nearly 800 points and 400 comments if you want the unfiltered community read.

Computer Use is the model capability that powers broader desktop control. Different layer. The Claude model is trained to take screenshot-and-action steps across any application - not just the browser. Anthropic’s computer-use tool docs cover the API side. Cowork uses this capability. Claude for Chrome uses a slimmer browser-only flavour. Same underlying ability, three different surfaces.

Every one of these talks to the same Claude. Opus or Sonnet, depending on what you pick. The model is shared. What changes is the wrapper around it. Two products. One brain. Different hands.

What you get for free on macOS, Windows, and Edge

If you’re on a Mac, install the Control Chrome extension from inside Claude Desktop and you’re set. The connector exposes about eight verbs to the model - open_url, get_current_tab, list_tabs, switch_to_tab, reload_tab, go_back, go_forward, close_tab. Eight verbs cover most navigation. The downside: AppleScript only sees what Chrome’s scripting interface exposes, so things like intercepting a fetch request or reaching across into a non-Chrome app aren’t on the table.

If you’re on Windows, Control Chrome won’t install at all. You’ll get the “requires Mac OS” message. Use the Chrome Web Store extension instead. It works on Chrome and on Edge.

Edge probably matters more than people credit. In conversations I’ve had with operations teams inside larger corporates, Chrome is often blocked at the device-policy level whilst Edge ships pre-installed and pre-approved. Turns out the Chrome Web Store extension imports cleanly into Edge with no special handling - same install button, same side panel, same behaviour. Brilliant news if you’ve been losing the Chrome-install argument with your IT team.

One real constraint to flag. The Chrome Web Store extension and the Desktop Control Chrome connector are independent surfaces. Two installs. Two separate session histories. If you set up Control Chrome on your Mac and later install the Chrome Web Store extension, the second one has no memory of the first one’s runs. Treat them as two different employees who happen to share a brain.

That’s the picture today. If the task is browser-only and nothing from your project folder needs to travel into the browser session, you’re done - pick the path your OS gives you and start clicking.

When Code can’t reach the browser - the meta-prompt handoff

Here’s the bit nobody warns you about until you hit it.

Claude Code’s session lives in the terminal. Knows your files. Holds the last hour of context. Claude for Chrome’s session lives in the browser. Knows the active tab. Has no idea what the terminal session knows. They are two separate API connections to the same model, and Anthropic does not stitch their sessions together - at least, not today. Will that change? Maybe, eventually. Today, no.

So if Code knows your team needs to add eight mailboxes to a SaaS tool with eight specific SMTP profiles, and you want Claude for Chrome to do the clicking, the state has to travel. The pattern: Code writes a self-contained text prompt that carries every URL, every field value, every halt-condition, every check, every report-back rule. You copy it. You paste it into Claude for Chrome. Hit send. The for-Chrome session has everything it needs to drive the browser, with no reference to the terminal session required.

I call this the meta-prompt handoff because Code is writing a prompt for a future Claude session to consume. The prompt is the bridge. Same model on both sides - that’s why it works. And yeah, it feels a bit like passing a note in class, except the note is written so a machine can act on it without further context.

The flow has six steps:

1. You describe the browser task to Claude Code in your project folder.
2. Code reads project context. Files. Configs. Where the credentials live (but not the credentials themselves).
3. You say: “now write the prompt I’ll paste into Claude for Chrome to do this.”
4. Code outputs a fenced text block. Self-contained. Inline URLs. Inline values. Halt-before-destructive rules. A report-back format at the end.
5. You copy the block. Paste it into Claude for Chrome. Hit send.
6. For-Chrome drives the browser, pauses on halts, reports back at the end.

A trimmed example of what Code produces. Placeholders for secrets, not real values:

You are running a browser session via the Claude for Chrome extension.

Task: Add 8 sender mailboxes at https://app.example-sales.tld/settings/mailboxes

Mailboxes (do these one at a time, in order):
1. [email protected] | SMTP: smtp.acme.tld:587 | TLS | Display: "JP Reyes"
2. [email protected] | SMTP: smtp.acme.tld:587 | TLS | Display: "Li Chen"
... etc

For each row:
- Click "Add mailbox", paste the email, paste display name, fill SMTP host and port, click "Test connection"
- Halt and ask me before clicking "Save" - I will paste the password for that mailbox at that moment
- After Save, confirm the row shows status "Active" before moving to the next

Never delete or overwrite an existing mailbox. Halt and ask if a duplicate row is detected.

At the end, report back:
- A numbered list of mailboxes added with status
- Any failures with the error message the page showed

Four safety rails worth pointing at directly. Never embed live credentials in the meta-prompt - that’s the same hygiene a CI pipeline uses. Pasting an API token or a real password into a text block your for-Chrome session reads is asking for trouble. Use a placeholder like <<PASSWORD_FOR_jp>> and have the operator type the real value when the browser asks. Second: always ask before destructive actions. Delete a record. Archive a row. Submit a transaction. Pay an invoice. Send a live email. Any of those should pause and request a yes. Third: always include a verification step - “confirm the row shows status Active” - so the model has to look at what happened on screen rather than assume the click landed. Fourth: always require a report-back at the end. A numbered list of what got done, what failed, what error the UI showed. The thing is, the difference between “the job ran” and “the job worked” is exactly that report.

In building Tallyfy over the last decade, and in advisory work with mid-size operations teams, the pattern I keep seeing is that the SaaS catalog has roughly two halves - tools with usable APIs, and tools without. The half without is exactly where the meta-prompt handoff earns its keep.

Picking your spots

A blunt heuristic. If the task has an API that’s better than the UI, use the API. If the UI is the only path, use the handoff. Most of the time the answer is obvious within thirty seconds of looking.

API beats UI when you’re inside Microsoft 365, inside Salesforce, inside Google Workspace, inside anything where Cowork’s fifty-plus MCP connectors already touch the surface. Cowork is the longer-horizon answer for non-code browser work, shipped under Mike Krieger’s product organisation at Anthropic to general availability in April 2026, and it sits a clear notch above the meta-prompt handoff in how little babysitting it needs. Mind you, Cowork is a separate session from your Claude Code project too, so the same context-bridge problem applies in a different shape - you still have to move state across, just via Cowork’s project memory rather than a copied prompt. The map I drew earlier on Chat vs Cowork vs Code covers the decision tree more fully.

UI beats API when the API is older than the UI, when the API costs extra, when the API requires a security review your IT team cannot schedule for six weeks, when the SaaS vendor never built one. The meta-prompt handoff fits all four. It also fits one-off batches where standing up a Playwright script would be more work than the task itself - classic yak shaving. Five minutes of prompt-writing beats two hours of automation engineering for a job you run once. Vendor portal invoice extraction. Recurring metrics from a SaaS dashboard that refuses to export. Form-fill against the kind of HR or finance system nobody bothered to put an API on. All decent candidates.

What the handoff does not fix. It does not make the for-Chrome extension safer than its threat model already allows. Click counts stay the same. The moment where you paste credentials is still there. The pattern is a bridge, not an end state. Once you find yourself running the same handoff three times a month, that’s the cue to escalate - either to a proper API integration, or to a Cowork project with the right connectors, or to the heavier-weight tools your engineering team would build if you asked. The philosophical case for moving past browser-only automation sits alongside this one - both posts argue the same direction from different ends.

For now, though, the handoff is your fastest unlock. The boring middle. A workable kludge that buys you time until the proper integration lands. Not as autonomous as Cowork, not as locked-in as a hand-rolled Playwright script, exactly the right level of effort for the work that mid-size operations teams do every week. If your team would value a second pair of eyes on where to apply this versus where to skip it, Pravina Pindoria and I take this kind of work through Blue Sheen.