Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/safari-mcp/issues.md or /mcp/safari-mcp/issues.json, or Pod over MCP.

Reported issues for safari-mcp

Pod holds 11 of 11 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to safari-mcp.

Most discussed

Feature: opt-in SAFARI_MCP_ALLOW_USER_TABS to act on the user's existing tabs (default off)

Context

The server has a deliberate tab-ownership model: once it has opened its own tab, it refuses to read/click/navigate/inject into tabs the user opened, and refuses to fall back to the frontmost ("user") tab if tracking is lost. The code is careful about this, and for the default case that's the right safety posture.

Use case that the current model blocks

Some workflows want the MCP to act on tabs the user already has open, on purpose: "read the article in my current tab", "fi

Read the thread · 2026-08-17 · open · external user · 1 comment

WebKit memory guard is inert in multi-instance setups — only the port-9224 winner may sweep, and only its own tabs

Summary

The WebKit memory guard in _startMemoryMonitor returns early for every instance that is not the extension host. The extension host is whichever instance wins the race to bind port 9224 — one process, machine-wide. So in any multi-instance setup the guard runs in exactly one process and is inert everywhere else.

That would still be fine if the host could sweep on everyone's behalf. It cannot: it sweeps from its own _openedTabs, which contains only the tabs it opened. Tabs open

Read the thread · 2026-08-04 · closed · external user · 1 comment

Support isolated tab/window lanes for concurrent MCP clients

Use Case

I run multiple Pi sessions/subagents against my normal Safari profile in parallel. Sharing its cookies and logins is intentional, but the agents can step on each other because they rely on shared active-tab state.

Proposed Solution

Add first-class lanes or explicit targets:

Read the thread · 2026-07-27 · open · external user · 12 comments

Missing transport.js in published tarball since 2.14.0 → ERR_MODULE_NOT_FOUND on clean install

Summary

Every published release since 2.14.0 (including current @latest = 2.15.1) is missing transport.js from the npm tarball, but index.js imports it at the top level. The package therefore fails to start on a clean install with ERR_MODULE_NOT_FOUND.

Environment

Steps to reproduce

npx -y safari-mcp@2.15.

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/50) · 2026-07-04 · closed · external user · 1 comment

### Allow the mcp to choose which profile it uses when browsing

**Use Case**

I have multiple safari profiles. I want the mcp to use a specific one.

**Proposed Solution**

The profile is an optional argument on each command.

**Alternatives Considered**

There are no easy workarounds.

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/26) · 2026-04-30 · open · external user · 1 comment

### Safari extension does not appear in Extensions list after README script run: "Allow Unsigned Extensions" is not sufficient, signed build required

## Bug Description

Following the README's [Installing the Extension](https://github.com/achiya-automation/safari-mcp#installing-the-extension) instructions exactly — `xcodebuild`, opening the `.app`, enabling **Safari → Develop → Allow Unsigned Extensions** — results in **the extension not appearing in Safari → Settings → Extensions**. Nothing to enable, even after step 2.

## What the README Says to Do

```bash
xcodebuild -project "xcode/Safari MCP/Safari MCP.xcodeproj" \
  -scheme "Safari MCP

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/17) · 2026-04-10 · closed · outside contributor · 3 comments

### Apple Events tools fail with "Not authorized" when running as stdio MCP from VS Code/Cursor — Automation permission is never granted

## Bug Description

Tools that use Apple Events (`safari_navigate`, `safari_analyze_page`, and others backed by `safari-helper`) silently fail when `safari-mcp` is started as a `stdio`-type MCP server from VS Code, Cursor, or Claude Code:

Not authorized to send Apple events to Safari.


## Root Cause

macOS requires **Automation → Safari** permission (System Settings → Privacy & Security → Automation) for any process that sends Apple Events to Safari. This permission **cannot be pre-gran

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/16) · 2026-04-10 · closed · outside contributor · 8 comments

### Switch tab & Screenshot don't working even the permissions Granted.

**Environment**

- macOS version:26.3
- Node.js version: 25.9.0
- Safari version:26.3
- MCP client (e.g., Claude Code, Cursor, Windsurf): Claude Code(Extension on VS Code)

**Steps to Reproduce**

1.new tab.
2. switch tab.
2. Resize for desktop view
3. Screenshot to tmp folder

**Expected Behavior**
take a usable Screenshot.
What you expected to happen.

**Actual Behavior**
OUT: screencapture failed — Screen Recording permission may have been lost. Grant permission in System Settings → Privacy &

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/14) · 2026-04-06 · open · external user · 4 comments

## Most recent

### Ownership file loses entries between concurrent instances — read-modify-write race on ~/.safari-mcp/owned-tabs.json

### Summary

`~/.safari-mcp/owned-tabs.json` is shared by every safari-mcp instance on the machine, but
`_saveOwnershipFile` serializes only the writing instance's in-memory `Set` and renames it over
the file. It never re-reads what is on disk. When two instances are alive at once, the second
writer silently drops every entry the first one added after the second one started.

This is **fail-safe, not a safety hole** — a dropped entry means ownership is *lost*, so a tool
refuses to act on a tab i

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/82) · 2026-08-04 · closed · external user · 1 comment

### Profile window poll never backs off — an osascript subprocess every 3s, forever, when the profile window is closed

### Summary

When `SAFARI_PROFILE` is set and the matching profile window is not open, the background
verification poll in `safari.js` retries at a fixed 3-second cadence forever. Each failed
attempt spawns a full `osascript` subprocess and appends a warning line to
`/tmp/safari-mcp-profile.log`.

The poll never backs off, and the failure is a steady state, not a transient: if the user has
not opened that profile's window, the instance stays in this loop for its whole lifetime.

### Where

`safa

[Read the thread](https://github.com/achiya-automation/safari-mcp/issues/81) · 2026-08-04 · closed · external user · 1 comment

### Can't start 'safari-mcp'

**Environment**

- macOS version: 15.7.5
- Node.js version: v20.11.0
- Safari version: 26.4
- MCP client (e.g., Claude Code, Cursor, Windsurf): <NO>

**Steps to Reproduce**

1. install 'safari-mcp' (brew)
2. start 'safari-mcp'

**Expected Behavior**

Server starts fine.

**Actual Behavior**

❯ safari-mcp [Safari MCP] HTTP server listening on port 9224 (extension host) safari-helper crashed (restart #1, retrying in 500ms) safari-helper crashed (restart #2, retrying in 1000ms) safari-helper c

Read the thread · 2026-04-09 · open · external user · 1 comment

The remaining reports are on the project's issue tracker.