/chrome in Claude Code: let Claude work in your Chrome session

TL;DR Claude Code spots the Chrome extension and offers to use your browser by default. The preselected button is No. Say yes and what happens next is decided by your permission mode: in Auto a classifier approves routine browser actions for you, and in Don't Ask anything that would need approval gets skipped instead of prompted.

Hooking Claude Code up to your Chrome is a one-second yes, and the dialog asking for it spells out exactly what follows. The catch is that the sentence doing the spelling changes with the mode you happen to be in when you read it, and the quietest version is the one you least expect.

The dialog you never asked for

If the extension is installed and you have not made up your mind yet, Claude Code does not wait for you to type /chrome. It offers:

╭─ Claude in Chrome extension detected ──────────────────────────╮
│                                                                │
│  Claude will use your Chrome browser by default — navigating   │
│  sites, filling forms, and capturing screenshots in your       │
│  existing session.                                             │
│                                                                │
│  Browser actions still go through Claude's regular permission  │
│  prompts before they run. Turn browser tools off for future    │
│  sessions with /chrome.                                        │
│                                                                │
│  ❯ No, keep browser tools off                                  │
│    Yes, use my browser                                         │
│                                                                │
╰────────────────────────────────────────────────────────────────╯

The wording is verbatim from 2.1.266, read out of the binary; the frame and the layout are mine, because I cannot make the dialog appear: my own ~/.claude.json already has the answer stored.

It does not reach everyone either. Claude Code skips the offer when the extension is not present on the machine, when you already answered once (even in another session), when your organization blocks it by policy (allow_claude_browser_extension or deniedMcpServers), or when the rollout of the offer itself has not reached you. Never seen it? Nothing is missing: /chrome does the same thing whenever you want it.

Two details in there carry weight. The highlighted option is No, not yes, so hitting Enter without reading leaves you exactly where you were. And "in your existing session" means it: no lab browser, no clean profile, the Chrome sitting in front of you with your cookies, your tabs and your Gmail already open. That half of the story, Claude acting as you inside Docs, Gmail or Notion with no API wiring, is told in full in the Chrome extension versus the DevTools MCP, and the map of all three possible browsers is in which of the three to use.

The middle line is not always that line

The middle paragraph, the one about permissions, is not fixed text. Claude Code swaps it for the mode you are in when the dialog appears, and there are three versions:

• Normal: "Browser actions still go through Claude's regular permission prompts before they run."
• Auto: "This session is in Auto mode, so an AI classifier approves routine browser actions, you are only prompted when it is unsure."
• Don't Ask: "This session is in Don't Ask mode, so browser actions that need approval are skipped rather than prompted."

Read that third one twice. In Don't Ask, an action that would need your approval does not turn into a question: it is skipped. No prompt to clear, and no click either. So when the form you expected Claude to fill never gets filled, it did not refuse you. The mode you are in says the things that need permission simply do not happen.

Since Shift+Tab cycles modes mid-task, the yes you gave on Tuesday in normal mode behaves differently on Thursday. If the six modes are not clear in your head, they are all here.

Plan mode splits the tools instead

In plan mode the dialog shows you the normal line, the one about prompts. But the real boundary there is not the mode, it is the tool. Calls that only look at the page run with no prompt (read_page, get_page_text, find, reading console messages or network requests, taking a screenshot). Calls that change something ask first: clicks, typing, navigation, tab and window management, recording a GIF.

The part that trips people: a read-only call starts asking the moment you hand it a flag that writes, such as save_to_disk on a screenshot, clear on the console and network readers, or createIfEmpty on the tab context. And a browser_batch runs prompt-free only when every action inside it is read-only.

Where your yes ends up

In ~/.claude.json, as three keys rather than one:

{
  "cachedChromeExtensionInstalled": true,
  "claudeInChromeDefaultEnabled": true,
  "hasCompletedClaudeInChromeOnboarding": true
}

claudeInChromeDefaultEnabled ships as false and is the one that decides. You can flip it without opening the file from /config, where it reads Claude in Chrome enabled by default, or from /chrome. Leaving it on costs you context, because the browser tools load in every session, a trade-off flagged back in Claude Code and Chrome.

What leaves your machine, and what does not

Worth knowing before you hand a browser with your bank session open to anything. This is not my summary: it is how Claude Code describes these tools inside the allow_claude_browser_extension organization policy, the switch an admin turns on or off. The calls travel over the local native-messaging connection between the app and the extension, encrypted end to end between the two. Page content is never relayed through Anthropic servers. The address is a different story: the extension's hosted URL-safety check stays on, so the URL of every page the agent acts on is checked against the Anthropic API.

Reference

Official docs: Use Claude Code with Chrome · Permission modes