Anthropic adds a built-in web browser to Claude Code's desktop app

The most useful thing to understand about this release is what it replaces. Claude Code's desktop app already had a preview pane, but that pane was only an HTML renderer - it could show simple markup and styling and fell over on anything more complex. The new Browser pane is a full, tabbed, web-capable browser that can navigate, click, and handle server-rendered sites, not just static files ^[1]. That distinction is why the launch generated an 'is this actually new?' undercurrent in the community: from a distance it looks like the same panel, but underneath it went from a viewer to an interactive browser.

That upgrade is what makes the rest of the feature set possible. Because it is a real browser rather than a preview, Claude can pull up docs, designs, issue trackers, or a running production app and interact with them the same way it already interacts with a local dev server ^[2]. The pane can still open static HTML files, PDFs, images, and videos from the project, so the old preview use case survives - it is now a subset of a much larger capability.

The headline is 'Claude can browse,' but the load-bearing feature is that Claude can now watch itself verify its own changes. Inside the pane it takes screenshots, inspects the DOM, clicks elements, fills out forms, and fixes the issues it finds - without a human wiring up a separate browser or an external automation harness first ^[1]. For a builder, that closes a loop that used to require manual glue: the agent makes an edit, opens the affected page, confirms the change actually rendered and behaved correctly, and iterates.

That is a meaningfully different value proposition from 'the assistant can read a webpage.' Digital Trends frames the everyday win as removing the friction of copying links back and forth between a browser and the coding assistant ^[3], but the deeper shift is autonomy: verification stops being a step the developer performs after the agent finishes and becomes something the agent does as part of the work.

Anthropic now ships two different ways for Claude to touch the web, and the split is deliberate. The new in-app Browser pane runs a clean, isolated profile with none of the user's saved logins or history, and session persistence is configurable ^[1]. The separate Claude in Chrome extension takes the opposite approach - it drives the user's real, already-logged-in Chrome or Edge session ^[4]. One is designed for work that does not need your identity; the other is designed for work that does.

This is the point some skeptics missed when they framed the launch as 'Claude has controlled Chrome for months, how is this different?' The isolated profile is not a lesser version of the extension - it is a different trust model. You can hand the agent a browser to test and verify against without exposing your authenticated cookies to a prompt-injection risk, and admins get consistency because the same site allowlist and blocklist that governs the Chrome extension applies here, plus a browserExternalPageTools managed setting to disable Claude's tools on external pages entirely ^[1].

Letting an agent click and type on live external sites is exactly where things go wrong, and Anthropic's answer is a layered permission system rather than blanket trust. Safety classifiers review Claude's write actions - clicking and typing - in every permission mode and trigger a prompt when an action looks risky, which is the mechanism aimed at prompt injection on live pages ^[1]. The first time Claude acts on a new external site, a card offers Allow once, Always allow, or Deny; approvals are saved per site including subdomains and are revocable in Settings ^[3].

There are also hard floors the agent will not cross even on an approved site: it will not purchase items, create accounts, or bypass CAPTCHAs without the user's input ^[3]. Read together, these constraints are what make an isolated in-app browser a defensible design - the blast radius of an agent acting autonomously on the open web is bounded by per-site consent and non-negotiable limits, not just by good intentions.

Community reaction ran broadly positive, with a recurring relief theme: ditching the separate extension and cutting constant tab-switching, and one moderator noting the missing in-app browser had been a reason some users stayed on competitors. The counter-current was practical rather than hostile - questions about how much this differs from prior Chrome control, jokes about bigger screenshots meaning bigger token bills, and a terminal-versus-desktop split where some users migrated to the desktop app for its preview and UI features while terminal loyalists stayed put.