What problem does this actually solve?
Previously, any task requiring a website without a Connector meant the user had to open a browser themselves, manually look things up, and copy-paste the results back to Claude — a manual step that was always the least automatable part of the workflow. The built-in browser fills that gap: Claude opens its own browser, reads pages, clicks, and fills forms on its own, removing the user from the copy-paste middleman role.
What it solves isn't "can Claude understand a webpage" — Claude in Chrome already handled that. It's "can Claude complete an entire browsing task independently, without the user ever opening their own browser at all."
With Claude in Chrome also in the picture, won't people get confused about which to use?
There's really just one decision point: does the task need the tab you currently have open? If yes — the CRM page you're looking at, the email you haven't replied to — use Claude in Chrome. If Claude just needs to go look something up on its own, wherever that may be, use the built-in browser instead.
Anthropic also built in a default that reduces the choice burden: existing Claude in Chrome users keep it as the default, while everyone else automatically gets routed to the built-in browser. Most users won't need to manually switch very often.
What does "can't see your tabs, bookmarks, or passwords" actually mean in practice?
The key point here is architectural isolation, not a policy promise or self-restraint. The built-in browser runs in an environment completely separate from a user's everyday browser, with no default data channel between the two — Claude has no pathway to read what's open in your Chrome or Edge tabs. That's a result of environment separation, not "Claude choosing not to look."
Login migration is a separate, opt-in action entirely: you choose which sites' credentials get brought into the built-in browser, and banking, email, and SSO sites are excluded by default unless you actively add them. That means even if you migrate logins for most of your everyday sites, the most sensitive account categories carry an extra threshold — they only get included if you deliberately choose to include them.
Anthropic itself admits Prompt Injection can't be fully eliminated — what should regular users actually do?
That line deserves to be taken seriously rather than dismissed as boilerplate — it reflects where the industry's technical reality actually stands on AI agents browsing the web: detection measures reduce success rates but can't guarantee zero risk. Anthropic already acknowledged this openly when Claude in Chrome launched, and the built-in browser inherits the same protections and the same risk profile.
For everyday users, the practical judgment call mostly comes down to which sites you send Claude to. Sites with stable, predictable structure and a trusted source — internal company systems, a dashboard for a service you use regularly — carry comparatively manageable risk. Pages with unclear provenance or content freely editable by unspecified third parties — public forums, largely user-generated sites — are where prompt injection has more room to hide. For that kind of task, it's worth defaulting to Claude in Chrome on a tab you're actively watching, or at minimum staying alert and checking in on whether Claude's actions still match what you asked for.
Anthropic announced on August 27, 2026, that Claude Cowork's desktop app now includes a built-in browser. When a task requires using a website, the browser opens directly in Cowork's side panel, letting Claude browse pages, read content, click buttons, and fill out forms on its own — no extension installation required.
Anthropic's example use cases include having Claude gather web data needed for a report, pull numbers from a site dashboard, or work inside an enterprise portal that doesn't yet have a Connector. Tasks that used to require the user to open a browser, copy data, and paste it back to Claude can now be handed off in a single pass.
It's worth being clear upfront: this isn't an upgrade to Claude in Chrome, it's a separate capability entirely. Claude in Chrome operates on tabs the user already has open and logged into — well suited for updating the CRM page in front of you, handling an inbox, or editing the document you're currently working on. Cowork's built-in browser instead gives Claude its own independent browsing environment, running completely separately from the user's regular browser.
That distinction is also what decides which tool fits which task: if the job is to act on the page you're currently looking at, use Claude in Chrome; if Claude just needs to go somewhere on its own to gather data or take an action, unrelated to whatever tabs you have open, use Cowork's built-in browser. If a user is already using Claude in Chrome, it keeps working and stays the default; otherwise Claude falls back to the built-in browser. Users can switch the preference under Settings → Cowork → Preferred browser.
Because it's a separate environment, Anthropic states that Claude cannot directly see the tabs, bookmarks, or passwords in the user's own browser. To let Claude log into a site, users can choose to bring login credentials over individually — macOS currently supports migrating logins from Chrome, Edge, or Firefox, while Windows and Linux support migration from Firefox. Banking, email, and Single Sign-On sites are excluded from migration by default, meaning the most sensitive account categories are opted out unless the user actively opts them in.
Giving Claude the ability to operate a browser also means facing the risk common to AI agents that browse the web: prompt injection, where content on a page contains hidden instructions attempting to steer Claude away from the task the user actually assigned. Anthropic says the Cowork built-in browser uses the same protections as Claude in Chrome, including checking in real time whether Claude's current actions still match what the user originally asked for. The company is also direct about the limits of these measures — they reduce risk but don't eliminate it — and recommends users primarily point Claude at trusted sites.
The built-in browser is rolling out gradually to Claude Desktop's Pro, Max, and Team plans, across macOS, Windows, and Linux (the Linux version remains in beta). Enterprise plans already have access, with admins able to manage the feature centrally under Organization settings → Cowork → Built-in browser.
The browser itself runs inside the Claude desktop app: as long as the desktop app stays open and connected, Claude can still drive it even when a request comes from the web app or mobile. If the desktop app isn't running, the web app falls back to Claude in Chrome for browser access instead.
If your workflow keeps hitting the same wall — a system with no Connector, forcing you to open a browser, manually pull data, and paste it back — this is the gap the built-in browser fills. It doesn't replace Connectors (a Connector-backed integration is still the more stable choice where one exists); it covers the sites that will likely never get an official integration but that you still have to check by hand every so often. Before rolling this into your workflow, take stock of which sites you'd actually let Claude visit, and start with ones you trust and whose page structure is stable. Banking, email, and SSO accounts already carry a built-in layer of protection since they're excluded from migration by default with no extra setup needed. Whether to migrate logins for anything else comes down to weighing time saved against how much account access you're willing to hand to an AI Agent — there's no one-size-fits-all answer here.