Safari 27 Lets an AI Agent Drive Your Browser. Apple Built the Hook Itself.

Apple doesn't usually hand out keys to Safari. So it's strange to open the Safari 27 release notes and find instructions for letting Claude Code or Codex open tabs, click buttons, run JavaScript and read the console in your actual browser window. Two checkboxes and one terminal command, and your coding agent is driving.

The feature is the Safari MCP server, and it shipped with Safari 27.0 on September 17. It's the most interesting thing in a release that is otherwise a very large pile of bug fixes, and most of the coverage has filed it somewhere below the new <select> styling.</select>

What MCP actually means

Model Context Protocol. It's a standard way for an AI client to plug into an outside tool. A server publishes a list of things it can do, the agent reads the list, and the agent calls the ones it wants. WebKit describes it as a protocol that lets compatible AI clients connect to servers that provide tools and resources. Apple wrote a server whose list of things is a Safari window.

Sixteen tools, and what they add up to

Four of the tools handle tabs: list, create, switch, close. Three cover movement and state, including navigate_to_url, wait_for_navigation, and page_info for the URL, title and loading state. Then there's the reading half. get_page_content hands back the page as markdown, HTML or JSON. screenshot returns a PNG. browser_console_messages pulls the buffered console logs, and list_network_requests plus get_network_request cover what you'd otherwise be clicking through in the network tab.

The other half is doing things. page_interactions covers click, type, scroll, hover and keyPress. evaluate_javascript runs JavaScript inside the page. browser_dialogs lists dialogs and answers them, whether that means accepting, dismissing or typing into one. set_viewport_size and set_emulated_media let the agent resize the window and switch CSS media types, so it can check responsive work without you dragging a corner around.

So you stop copying console errors into a chat window. The agent reads the console itself, takes a screenshot, checks the request that failed, changes the code, reloads, and looks again. Apple's framing is that "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."

What it won't do

It can't touch AutoFill or your browsing history, and WebKit says it reaches no personal Safari data at all. It also makes no network calls of its own, so it can't go fetch anything outside the page in front of it. Whatever the agent knows about your browser, it learned through those 16 tools. It's built to debug the site you're building, and it stops there.

How to turn it on

Open Safari's settings, go to Advanced, and check "Show features for web developers." That reveals a Developer tab. In there, check "Allow remote automation and external agents." Then point your agent at the driver:

claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

Codex users swap in codex mcp add. Anything that reads a standard mcp.json wants /usr/bin/safaridriver as the command and ["--mcp"] as the args, and you can name the server whatever you like.

That path is safaridriver, Safari's own remote automation driver, with a new --mcp flag. There's no extension to install and nothing else to download. Safari Technology Preview 247 and later have it too, at /Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver, where the checkbox is worded "Enable remote automation and external agents" instead.

The permission model is two checkboxes and your judgment

Apple's security pitch is short, and to its credit, honest. The server runs entirely on your local machine and makes no network calls of its own. Page content, screenshots and console logs go straight to the agent you're running, not to Apple. You turn the whole thing on yourself, in your own settings, and it's off until you do.

WebKit puts the caveat plainly: "As with any agent you give access to your browser, only use ones you trust." Once that toggle is on, Safari isn't reviewing each action. evaluate_javascript runs whatever the agent decides to run inside the page, and whatever you happen to be signed into in that window is in scope. WebKit also notes that what happens to the data after it leaves Safari depends on the agent and the model you picked, which is a polite way of saying Apple's guarantees end at the edge of the browser.

Apple named the agents out loud

Apple has a reputation for closed software and conservative defaults, which is what makes it odd to read WebKit's own blog telling you to hand a browser window to Claude Code or Codex. It names both, and gives you the command to paste. The local-only design is how Apple squares that with itself: the agent gets your page, Apple gets nothing.

The rest of Safari 27, briefly

The <select> element is finally stylable, with new user-agent defaults, pseudo-elements like ::picker-icon, and real HTML allowed inside options. The <model></model> element for embedding 3D content, previously a visionOS feature, now works in Safari on iOS, iPadOS and macOS, and visionOS gets an Immersive API so a site can supply its own environment. Scroll anchoring keeps content that loads in above the viewport from shoving your place on the page. And the ECMAScript module loader was rewritten from scratch, fixing top-level await bugs that had been causing cross-browser trouble.</select>

 

<select>Safari 27 counts 83 features, up from 58 at the June beta. The bigger number is 844, the resolved issues, which WebKit puts at 86 percent of everything in the release. Sixty-six of those fixes are SVG alone. WebKit's own line is that "the biggest feature of Safari 27.0 isn't a feature at all."</select>

<select>If you build for the web and you've been testing Safari by switching windows and squinting, the setup takes about a minute. Flip the two checkboxes, run the one command, and give your agent a bug you already have.</select>