Posts tagged with "browser"

Anthropic Introduces an In-App Browser for Claude Cowork

Hot on the heels of OpenAI’s addition of a cloud-based browser to ChatGPT Work, Anthropic has added an in-app browser to Claude Cowork in its desktop app. What’s interesting about the two browser implementations is that while both ChatGPT Work and Claude Cowork are meant to be used for general knowledge work, Claude Cowork’s browser is something of a hybrid that mixes aspects of OpenAI’s Codex built-in browser with its ChatGPT Work cloud-based browser.

First of all, I do not yet have access to Claude’s in-app browser, so the following is based solely on Anthropic’s announcement and other documentation. Still, the differences are worth understanding since the tools are aimed at different workflows.

Like Codex’s in-app browser, Claude Cowork’s in-app browser is built into the desktop app itself. That ties Claude’s browser to the instance of its app running on your Mac. Turn your Mac off or close the Claude app, and the browser becomes unavailable. Leave the Claude app running, and you’ll be able to control the browser session remotely through the Claude mobile app or the web.

From there, however, the browsers diverge. As you’d expect, the Codex implementation is developer-oriented, with tools to build, inspect, and annotate web pages along with access to a terminal, repos, and diffs. In contrast, Claude Cowork’s in-app browser opens automatically as needed for general-purpose web tasks instead of development tasks.

Also, while both ChatGPT Work’s and Claude Cowork’s browser implementations benefit from being isolated from your other day-to-day browser use outside those apps, their handling of login credentials is a little different. As I wrote in greater detail yesterday, ChatGPT separates the login process from the model’s activity and evaluates the login page for things like phishing schemes. Claude Cowork’s in-app browser offers two ways to log in: manually, or by importing cookies from logged-in sessions in another browser. Currently, Claude supports cookie imports on the Mac from Chrome, Edge, and Firefox, but not Safari. In addition to the security benefits that come with a browser that runs isolated from your everyday browser, Claude also requests permission before acting on a site for the first time, blocks high-risk sites, checks actions against the your requests, and uses the same prompt injection protections as its Chrome extension.

My first-run experience with ChatGPT Work’s cloud browser was a mixed bag but showed promise. Although I haven’t tried Claude Cowork’s browser yet, I’m glad to see Anthropic moving in the same direction as OpenAI here. Isolating agent browsing by bringing the browser into Claude and ChatGPT doesn’t solve every security issue, but it’s a good starting point. I expect we’ll see both Anthropic and OpenAI iterate quickly on this theme in the coming months.

Hands-On with ChatGPT Work’s New Cloud Browser Feature

Yesterday, OpenAI introduced a new ChatGPT Work feature designed to let it navigate websites that require a login without revealing your credentials to the model.

Like a lot of people, I spend far too much time clicking around websites that require a login, looking at analytics and other data, checking whether new sponsors have been booked for our podcasts, and more. It’s a tedious but necessary part of my week that slows me down and takes me away from writing and other creative work. ChatGPT’s new Work feature is designed to handle that sort of work for you.

The feature works by signing into websites using a virtual, cloud-based computer. That separates the browsing session from any browsing session on your local computer, walling the agent’s computer use off from your open tabs, cookies, browsing history, passwords, and other data. Because the login and browsing happen in the cloud, that also means work can continue whether you close the ChatGPT app or power down your computer.

According to OpenAI, an additional review model checks the sign-in request and credential destination for signs of phishing or deception. ChatGPT Work then pauses while the user signs in. Credentials entered through its secure sign-in form go directly to the cloud browser and are not visible to the model. After the user authenticates, ChatGPT resumes its work.

OpenAI also explains that its cloud-based browser doesn’t store your username and password. Instead, it saves cookies that allow you to return to a previously authenticated session. If you don’t want to remain logged in, ChatGPT’s cloud browser settings allow you to clear browser data for individual websites or all sites.

Similar to other features in ChatGPT and Codex, users have choices when it comes to which sites ChatGPT Work can access. “Always ask” is the default, requiring the agent to check with the user before using a website, but the permission level can also be set to “Auto approve” after ChatGPT checks a site for relevancy and risk or “Always allow,” which OpenAI discourages. Individual websites can also be allowed or blocked. These settings control website access, but consequential actions require separate confirmation.

ChatGPT Work's browser control works best on a mobile device and with simple login systems.

ChatGPT Work’s browser control works best on a mobile device and with simple login systems.

I gave ChatGPT’s browser use a try and the results were mixed. I wasn’t able to get the feature to work at all using ChatGPT Work in Safari on my Mac. Some websites had security measures in place that prevented me from logging in. Other times, the cloud browser asked me to take over manually, but I was unable to do so because the UI was frozen or login panels didn’t appear.

Logging into a site with a CAPTCHA required manual intervention.

Logging into a site with a CAPTCHA required manual intervention.

I had better luck using my iPhone. On one site with a simple username and password system, a login sheet appeared. I entered my credentials, was logged in, and the agent navigated the site to answer my queries. On Apple’s affiliate link dashboard website, I had to take over the browser interaction manually to satisfy a CAPTCHA, which worked after several challenges. Once logged in, the agent pulled and analyzed the data I requested. Also, after I’d signed in to both of those sites on my iPhone, I remained logged in to ChatGPT’s cloud browser, which meant I could also use them from my Mac.

In its current form, the idea of having ChatGPT Work browse signed-in websites on your behalf is better than its implementation. If you can get logged in, having an agent collect and analyze things like analytics data is fantastic. However, getting past the initial login screen is still too frustrating. That said, I’ll be keeping a close eye on the feature, which is available on eligible plans depending on rollout and workspace settings, for future use collecting and analyzing data that would otherwise require a lot of clicking around.

Safari’s New MCP Server Is Great for Agents→

Saron Yitbarek, writing on the WebKit blog:

In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes your web development and debugging workflow faster and more powerful. We know agents are increasingly integral to the coding process and the Safari MCP server gives your agent the ability to know how your code actually renders in the browser by connecting it to a Safari browser window.

Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.

Importantly:

The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.

For the past few months, I’ve been using Google Chrome on my MacBook Pro and Mac Studio not because I like the browser (in fact, I really dislike Chrome’s text rendering and UI), but simply because it was the best option for agents. In Codex specifically, between Playwright, Chrome Dev Tools, and OpenAI’s own Chrome extension, I could kick off research tasks (such as vacation planning and booking a hotel) that involved a browser directly from my iPhone, letting Codex drive the research on my remote Mac.

Safari in Codex.

Safari in Codex.

Now, thanks to Safari’s new MCP server, I no longer have to use Chrome on desktop and can return to a unified browser setup across all my devices. Even better: it actually looks like Apple shipped the most ergonomic browser MCP for agents to date. The MCP server has dedicated tools for page extraction (including getting webpages as Markdown, based on WebKit’s own conversion pipeline), evaluating JavaScript, DOM interactions (clicking, scrolling, resizing the viewport for mobile screens, etc.), taking screenshots, and more. I set this up immediately in Codex, and I also asked Codex about comparing Safari’s MCP to its own Chrome extension and the older Playwright. The verdict: although Chrome has a richer API with Chrome Dev Tools when it comes to network requests, Codex actually preferred Apple’s leaner, more direct approach for letting an agent drive and debug a browser.

I’m really happy to see folks at Apple embrace agentic tools: between the new MCP capabilities of Xcode and now this, it looks like Apple’s software (on the Mac, of course) is becoming more and more approachable by people who are working in new ways thanks to agents. Whether you’re a web developer or tinkerer, I highly recommend checking out what Apple has released in Safari Technology Preview. More of this, please.

Permalink

Well, I Guess I Like Safari’s Compact Tab Bar in iPadOS 26.4 (Also: Using Vertical Tabs in Safari for iPad)

We're so back.

We’re so back.

Yours truly, back in September 2021:

In case I haven’t been clear enough above, I’ll be blunt: I don’t understand why the compact tab bar exists on iPad, and I think this design shouldn’t have shipped to customers.

My understanding is that Apple thought the benefit of removing a separate address bar, therefore saving a few vertical pixels on the page, would have made all the compromises we’ve seen so far worth the trade-offs in usability. I think that’s a wrong and mismanaged decision driven by an unmotivated pursuit of an iPhone-like design that has no place on iPad. If slightly increasing vertical space on webpages is Apple’s only argument here in favor of the compact tab bar, you tell me if it’s worth the trouble by judging from the screenshots below.

If, like me, you missed this in the release notes for the recently released iPadOS 26.4, the compact tab bar has returned to Safari for iPad after mysteriously disappearing in iPadOS 26.0. And I’m here to tell you that not only do I not despise it like I did five years ago, but I actually like this mode and have been working with Safari on my 13” iPad Pro like this for the past two weeks.

Read more

Comet Is the First Agentic Browser for iOS Worth Trying

Comet for iOS.

Comet for iOS.

[Update: Perplexity has released an iPad version of Comet alongside the iPhone version, which you can install using the same App Store links below. However, because it wasn’t part of the TestFlight version of the app that we tested, we were unaware that it was launching with the iPhone version.]

For the past three weeks, I’ve been testing Comet, Perplexity’s cross-platform agentic web browser, on my iPhone Air. The iOS version of Comet, launching today on the App Store and (sadly) lacking an iPad counterpart, follows the expansion of Comet from macOS to Windows and Android devices, and it carries the inherent limitations of Apple’s platform. Comet for iOS is based on Safari’s WebKit engine; you cannot install third-party browser extensions due to iOS sandboxing restrictions; you can make Comet your default iOS browser, but in-app web views in third-party apps will still open with Safari View Controller, not Comet. By and large, Comet on iOS is a skin of Safari, but for the first time since the debut of Arc Search on iPhone two years ago (R.I.P.), I’m actually excited about an alternative to Safari on iOS once again.

Read more

How to Enable Smoother 120Hz Scrolling in Safari→

I came across this incredible tip by Matt Birchler a few weeks ago and forgot to link it on MacStories:

Today I learned something amazing: Safari supports higher than 60Hz refresh. It’s the only mainstream web browser that doesn’t, and I have never understood why, but apparently as of the end of 2025 in Safari version 26.3 (and maybe earlier) you can enable it. Here’s how to do it.

I won’t paste the steps here, so you’ll have to click through and visit Matt’s website (I keep recommending his work, and he’s doing some really interesting work with “micro apps” lately). I can’t believe this feature is disabled by default on iOS and iPadOS; I turned it on several days ago, and it made browsing with Safari significantly nicer.

Also new to me: I discovered this outstandingly weird website that lets you test your browser’s refresh and frame rates. Just trust me and click through that as well – what a great way to show people who “don’t see” refresh rates what they actually feel like in practice.

Permalink

Web Advocates Challenge Apple’s EU Browser Policies→

The EU’s Digital Markets Act requires Apple to allow third parties to offer web browsers with their own browser engines. However, more than a year later, there are no browsers built with Chromium, Gecko, or any other engine in the EU.

At a recent EU workshop on Apple’s compliance with the DMA’s browser requirements, Apple representatives were asked some pointed questions by Open Web Advocacy (OWA), and others about its browser engine policies. OWA, a non-profit that advocates for the open web, raised multiple issues with Apple’s approach to browser engines in the EU that they believe are holding back third-party engines.

One issue is that versions of the same browser with different engines can’t be part of the same app bundle. According to OWA, that effectively means vendors like Google and Mozilla would need to release a new EU-only version of their browsers, starting the process of acquiring users from scratch, which I can’t imagine any browser company would sign up to do voluntarily.

Another issue OWA raised is that there is currently no way for web developers outside the EU who are not associated with the browser makers to obtain browsers with competing engines for testing purposes. That’s a problem that’s been solved with other apps by allowing test versions to be distributed outside the EU. However, as things stand today, OWA says that web developers couldn’t use EU-only browsers for testing even if there were any available.

Other issues were raised, too, but these two strike me as practical impediments to third-party browser engines that can and should be resolved. Apple’s responses to OWA’s challenges focused on privacy and security, which are legitimate factors to consider, but it’s disappointing that more than a year after the DMA took effect, the practical problems raised by OWA and others still haven’t been solved.

Permalink

The iPad’s “Sweet” Solution

In working with my iPad Pro over the past few months, I’ve realized something that might have seemed absurd just a few years ago: some of the best apps I’m using – the ones with truly desktop-class layouts and experiences – aren’t native iPad apps.

They’re web apps.

Before I continue and share some examples, let me clarify that this is not a story about the superiority of one way of building software over another. I’ll leave that argument to developers and technically inclined folks who know much more about programming and software stacks than I do.

Rather, the point I’m trying to make is that, due to a combination of cost-saving measures by tech companies, Apple’s App Store policies over the years, and the steady rise of a generation of young coders who are increasingly turning to the web to share their projects, some of the best, most efficient workflows I can access on iPadOS are available via web apps in a browser or a PWA.

Read more