I Stopped Merging Pull Requests to My Browser Tool. Contributors Still Ship.

Description and use

The author stopped automatically merging external pull requests in safari‑mcp to prevent unknown binaries and code from running with user permissions. He now reviews diffs only, runs code only in GitHub CI, rewrites accepted changes, and credits contributors in the changelog.

Problem

The author cannot safely merge external pull requests because they may contain malicious binaries or code that runs with the author's user permissions.

Outcome

Four contributor ideas were rewritten and shipped in v2.23.0, while the author maintained control over binary execution and user permissions.

Workflow

• 1. Review PR by inspecting the diff via gh pr diff <n> and the file list from the API.
• 2. Ensure no binaries, lockfiles, workflows, or generated code are present in the diff.
• 3. Verify the PR description matches the diff; otherwise reject.
• 4. Run tests only in GitHub CI, ensuring the PR has no secrets or deploy keys.
• 5. Rewrite accepted changes in the author's own commit, preserving tests.
• 6. Publish the rewritten changes to main and credit the contributor in the changelog.

Evidence

I maintain safari-mcp, an MCP server that lets AI agents drive Safari on macOS. Not a fresh browser in a sandbox. The user's own Safari, with their Gmail session, their bank tab, their cookies.

Source

If I had merged it because the description sounded reasonable and CI was green, every user's next npm install would have run a binary I had never seen, with the Accessibility permission they granted to mine.

Source

I wrote them down so I'd follow them on autopilot, including when I'm in a hurry: 1. Outside code never runs on my machine.

Source

The other three change how the extension handles windows and tabs. I want to see those in a real Safari with the extension rebuilt before they ship, not only in jsdom and stubs, so they wait.

Source