Claude Cowork Now Opens Its Own Browser for Web Tasks

What Anthropic Actually Shipped This Week

Anthropic started rolling out a built-in browser inside Claude Cowork this week, in the Claude desktop app for macOS, Windows, and Linux, with Linux marked as beta. It ships now on Pro, Max, and Team plans. Enterprise works differently: admins can turn the feature on for their organization starting today, but it is off by default at launch and only flips to on by default for Enterprise from September 10, 2026, unless an admin has already turned it off. Enterprise admins also get a control to restrict Claude's browser access to an approved list of domains, which is the kind of guardrail I would want before letting this loose on anything work related.

The feature is specific to Cowork, the task-runner surface inside Claude, not a general purpose browser extension you install separately. According to Anthropic's own documentation, when the desktop app is online, the same built-in browser is also reachable from Cowork on web and mobile, so a task started on a laptop can keep running with browser access even when checked on a phone.

I read through the announcement and the Cowork help documentation directly rather than going off a headline, because "Claude now browses the web" is the kind of claim that means very different things depending on scope, and I wanted to know exactly what this does and does not cover before writing about it. This is not Claude gaining unrestricted internet access by default. It is a scoped browser session, tied to a specific task, that a person can watch running in real time. It is the same habit that made the MCP spec's move to stateless worth reading in full rather than trusting a summary, a scope change buried in a paragraph matters more than the headline framing it.

The timing is worth noting too. Cowork itself is still a relatively new surface for Anthropic, built around letting Claude carry out longer, more autonomous tasks rather than a single back and forth chat. A built-in browser fills an obvious gap in that model, since a lot of real tasks, filling out a form, checking a listing, comparing prices across sites, pulling a document from a portal, require an actual browser and not just an API call. Before this, a task that needed a website either had to route through a connector built for that specific site, or it simply could not be done inside Cowork at all.

How The Browser Behaves Inside A Task

The mechanics, based on what Anthropic has published, are straightforward. When a Cowork task needs to interact with a website, a browser window opens in a side panel right next to the task itself. Claude navigates to the site, reads what is on the page, clicks the elements it needs to click, types into fields, and fills out forms, all visible in that panel while the task runs. There is no separate window to hunt for and no browser extension to install first. It is part of the Cowork interface itself.

That visibility is the detail I care about most. A tool that acts on a live website on my behalf is only as trustworthy as how easy it is to watch it work. A side panel that shows every page Claude opens and every action it takes, in real time, in the same window as the task, is a very different design than a background process that reports back after the fact with no way to interrupt it mid-action. I have not run this against my own workflows yet, since it only started rolling out this week and I want to watch how the first wave of usage reports actually shakes out before touching anything connected to raxxo.shop, but the interaction model as described is the right shape for a tool doing things I did not type myself.

The scoping to a single task also matters. This is not a persistent browsing session that carries state between unrelated tasks by default. Each task's browser use is tied to that task, which limits how far a mistake in one task can spread into something else Claude is doing.

The Login And Privacy Model

The part most likely to actually matter for anyone considering turning this on is how it handles logins. Anthropic built login import as opt in and site by site, not a blanket handoff of a person's browser identity. You can bring credentials over from Chrome, Edge, or Firefox on macOS, and from Firefox on Windows and Linux, picking which sites to include rather than importing an entire saved password store at once.

Certain categories are excluded by default regardless of what a person imports elsewhere. Banking sites, email, and single sign on providers stay out of the built-in browser's reach unless a person deliberately chooses to include them. That is a sensible default line to draw, since those three categories are exactly the ones where a mistake or a misread page has the highest cost. I read this as Anthropic drawing the line at "the sites where getting it wrong is expensive" rather than leaving that judgment call to whoever is setting up their first Cowork task without thinking it through.

For Enterprise accounts, the domain whitelist control adds another layer on top of the opt in login model. An admin can restrict which domains the browser is allowed to reach at all, which turns this from "trust the login controls" into "trust the login controls and a hard boundary on where Claude can go in the first place." That is the setting I would reach for first if I were rolling this out for a team rather than using it solo.

None of this replaces ordinary judgment about what to hand an AI browsing tool in the first place. A domain whitelist and excluded login categories reduce the blast radius of a mistake, they do not make every remaining site automatically safe to hand over. The sites left in scope after those exclusions still deserve the same "would I actually want an assistant clicking around here unsupervised" question before importing anything.

There is also a quieter design choice worth naming, which is that none of this happens silently. Importing a login is a deliberate, site by site action a person takes, not a background sync that happens the first time Cowork needs a credential. That matters because the failure mode I actually worry about with browsing agents is not a single dramatic mistake, it is a slow accumulation of access nobody remembers granting. A model where every credential handed over required a specific, visible choice is a model that stays auditable months later, when someone finally asks "wait, what does this thing actually have access to."

Why This Matters For How I Actually Use Claude

I run a one person studio, which means the tasks that eat real time are rarely complicated, they are just tedious and web bound. Checking whether a domain registrar changed a setting, pulling a screenshot from a dashboard that has no API, filling out the same kind of form across a few different platforms. None of that needs a model with deep reasoning. It needs something that can open a page, find the right field, and act on it the way I would, just faster and without me tabbing away from whatever I am actually building.

That is the specific gap a built-in, watchable browser fills better than a chat window ever could. A model describing what it would click is not the same as a model clicking it while I watch the same panel it is looking at. The side panel design is what makes this usable for the kind of task I would actually hand off, since I can see a wrong click coming and stop a task before it goes further, instead of finding out after the fact what happened on a site I was not watching.

I am not switching any Shopify adjacent workflow over to this in its first week. New browser access to real websites, rolling out to millions of accounts at once, is exactly the kind of feature I want to watch mature for a bit before I let it near anything connected to the store. But for the smaller, lower stakes web chores that make up a surprising share of a solo operator's week, a scoped, visible, opt in browser inside the tool I already use daily is the kind of feature that quietly saves real time once it has had a few weeks to prove itself.

The comparison I keep coming back to is the difference between a tool that does a task for me and a tool that lets me watch a task get done. Plenty of automation exists that runs a script against a website in the background and reports success or failure after the fact, and I have used my share of it. That model works fine for a task I have already trusted completely, but it is a bad fit for the first several times I try something new, when I actually want to see what is happening at each step and step in if a page loads wrong or a form has a field I did not expect. A side panel I can watch turns a leap of faith into something closer to supervised practice, and supervised practice is how a task earns the right to run unsupervised later.

Bottom Line

Claude Cowork getting a built-in browser is not a flashy model release, it is a practical feature that closes a real gap between "Claude can reason about a task" and "Claude can actually do the parts of that task that live on a website." The rollout is deliberately staged, desktop first across macOS, Windows, and Linux beta, Pro, Max, and Team now, Enterprise on an admin controlled timeline with a domain whitelist option. The login model is opt in and site by site, with banking, email, and single sign on excluded by default, which is the right set of defaults for a tool that is about to start clicking around on real accounts.

I am watching this one closely rather than adopting it immediately, the same way I watched auto mode's rollout in Claude Code before deciding where I actually wanted the extra scrutiny to stay. A visible side panel and scoped, revocable logins are the right shape for a browsing agent. Whether it earns a permanent place in my own workflow is still a question the next few weeks of actually using it will answer, not the announcement itself.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)