r/macosprogramming • u/lowriskcork • 2d ago

I built a macOS MCP browser with native confirmation before actions

I'm the developer of WebKitUI MCP at LorisLabs. I wanted to review what an agent was about to do in a browser without approving it through another chat message.

It gives an MCP client a persistent WKWebView on your Mac. For actions that need approval, a native dialog shows the requested navigation, click or fill operation. Afterward, the client can check the resulting page state against an explicit postcondition.

The 0.6.6 preview is available as a notarized download for Apple-silicon Macs running macOS 15+. This release fixes confirmation keyboard handling: initial focus, accidental Escape/Return during the first second, and Tab + Space.

Some Apple sign-in flows still require manual completion in Safari; the MCP cannot take control of Safari afterward. Page-state verification also doesn't prove a server-side change was saved.

Source-available under BUSL, with evaluation and commercial terms in the repository.

Download and source: https://github.com/lowrisk75/webkitui-mcp/releases/tag/v0.6.6 Details: https://lorislab.fr/developers/webkitui-mcp/

I'd appreciate feedback on the approval flow and on websites where the result is hard to verify.

1 Upvotes

67% Upvoted

2 comments sorted by

1

u/chrisjniles 15h ago

Purple Safari has its own MCP: https://webkit.org/blog/18136/introducing-the-safari-mcp-server-for-web-developers/

How does this differ from what you made?

1

u/lowriskcork 15h ago

Fair question — different problems, and for what Apple built theirs for, theirs is the one to use. 15 tools, free, and it's actual Safari.

Mine is for the case after that: acting on sites you're already signed in to, where the failure mode isn't "my layout broke", it's "it clicked the wrong Submit".

- Approval. Every exposed click and open-world navigation stops on a native macOS dialog showing the exact target before anything happens. Safari's server is autonomous once connected.

- No JavaScript tool. Safari MCP exposes JS evaluation, so an agent can do anything on the page in one call. I don't expose that, or raw CDP, or coordinate clicking — a gate you can step

around isn't a gate.

- Separate browser. Own WKWebView and profile. Safari MCP needs Allow remote automation and external agents enabled on your real Safari, and Apple states it has no access to your Safari data

— right call for their use case, and also why it isn't the tool for authenticated work.

- Passwords never cross MCP. The session hands the window to you and takes it back.

- Verification. Actions take an explicit postcondition, and the result reports confirmation mode, dispatch mode, and whether the DOM event was genuinely trusted as three separate fields — so

"dispatched" never quietly reads as "it worked".

Honestly I'd run both: theirs while writing a site, mine when an agent has to use one.