Transactional write safety
Preconditions, idempotency keys and a ledger that separates verified from indeterminate.
LorisLabs · Developer Tools
Developer Preview 0.6.42
Apple silicon · macOS 15+
Human-approved browser actions for macOS.
Up to three independent native WebKit pages for your MCP tasks, sharing your saved sign-ins, with explicit native approvals and observable action results. Developer Preview 0.6.42 for supported Macs.
macOSSwiftWKWebViewSource available
The browser runs on your Mac. Observations go to your MCP client and potentially its model provider. External Safari login cannot resume this MCP session.
Illustrative provider receipt — capabilities vary by site and version.
The problem
“The click ran” is three different claims.
Most automation reports the first and hopes for the other two. WebKitUI MCP treats them as separate facts, each with its own proof.
CLAIM 1
A click was dispatched
A JavaScript call fired an event. The page may have seen it — or ignored it as synthetic.
Did anything even happen?
CLAIM 2
The browser reports a trusted event
Native input can produce trusted browser events. This does not prove that a person approved the action.
How was this action authorized?
CLAIM 3
The observed state changed
A postcondition verifies the observed page state. A server-side commit needs independent backend evidence.
Can you prove it afterwards?
The workflow
Bind. Approve. Dispatch. Verify.
Four states most automation stacks conflate, kept strictly separate: what exactly was requested, who authorized it, how it was dispatched, and what proves it happened.
-
01
Bind
Every write binds to one exact target, arguments and idempotency key, with a short expiry. Change anything, and the binding is void.
-
02
Approve
A human approves that exact binding. Approval is a decision, not an action — the model cannot mint or forge it.
-
03
Dispatch
Only then does native AppKit actuation run the write, in a real WKWebView, against a freshly re-resolved semantic target.
-
04
Verify
Exact page-state postconditions are checked and a durable receipt recorded. Backend persistence requires separate evidence.
An indeterminate action is reconciled by re-observation of its postcondition. It is never blindly replayed.
Fit
Built for the writes you can't afford to guess about
Ideal for
- Authenticated administrative consoles
- Billing and developer portals
- Low-concurrency, high-value mutations
- Workflows needing local human authority and audit evidence
Not designed for
- Web scraping at scale
- High-concurrency browser farms
- Anti-bot bypass
- A general replacement for Playwright, Selenium or cloud browsers
Those are different, legitimate jobs — with better tools for them. See the comparison below.
Comparison
Different tools, different optimization targets
| Dimension | WebKitUI MCP | Playwright MCP · Selenium | Managed cloud browsers |
|---|---|---|---|
| Local human authority | Built in — exact per-write approval on your Mac | Scriptable; typically runs unattended | Remote, policy-based controls |
| Input mechanism | Native AppKit actuation in a real WKWebView | Browser automation protocols; event behavior depends on the action | Depends on provider and browser backend |
| Direct state verification | Postconditions + durable receipts, by default | Assertions you write and maintain yourself | Varies by provider |
| Scale & concurrency | Deliberately low — bounded sessions per client | High — parallel contexts, grids, CI | Very high — elastic fleets |
| Ecosystem breadth | Focused: macOS, WKWebView, MCP | Very broad: every major engine and language | Broad APIs and integrations |
| Managed infrastructure | None needed — runs on your Mac | Self-managed or CI-hosted | Fully managed by the provider |
Pick Playwright, Selenium or a cloud fleet for breadth, scale and CI coverage. Pick WebKitUI MCP when a small number of writes must be approved, trusted and proven on a Mac you control. Many teams will use both.
Trust boundaries
What we don't claim
- No exactly-once guarantee. An uncooperative website can always leave a write indeterminate; the runtime proves what it can and stops.
- No universal site compatibility. Capabilities vary by site and version; provider behavior must be revalidated as its own gate, on the installed build.
- No anti-bot or stealth guarantee. There is no bypass tooling and no undetectability claim, deliberately.
- Low-concurrency by architecture. Sessions are bounded per client. This is a precision instrument, not a fleet.
- Indeterminate writes are reconciled, never replayed. Reconciliation may prove a late postcondition; it never re-dispatches the action.
- Credentials stay isolated. Secrets are released through SiliconPass on the Mac and are never returned to the MCP client.
Authentication
Touch ID guards secrets, not clicks
Ordinary navigation and approved clicks don't ask for Touch ID — you'd never accept the friction, and they don't need it.
Releasing a credential is different. SiliconPass requires fresh device-owner authentication at the moment of release, using whichever method your Mac has available.
Availability is checked locally at the moment of release and is never inferred from lid state. If macOS offers no method, no secret is released and there is no automatic retry.
Device-owner authentication
- Touch ID
- Apple Watch
- macOS login password
Fresh at the moment of release — never cached approval, never a stored token handed to the model.
Pricing
Evaluate free. One plan when it earns.
Commercial access on request. Uses outside the BUSL grant need a separate agreement.
Evaluation
30 days
- Full runtime, on your own Mac
- Evaluate against your real consoles
- No account, no payment details
WebKitUI MCP Team
€299 per organization · per year · excl. tax
- Up to 5 authorized developers
- Up to 10 Macs
- Internal commercial production use
- Commercial OEM, redistribution and hosting outside the BUSL grant: separate agreement
Contact LorisLabs for an agreement. This preview does not require an activation key; the licence defines permitted use.
BUSL-1.1 governs the preview. Commercial rights require a separate accepted agreement.
Evidence
Tested where it matters, published where you can read it
The public repository carries the architecture docs, the test suite and the benchmarks behind each of these categories — reproducible on your own machine.
Native actuation
AppKit-dispatched gestures in a real WKWebView, measured rather than assumed.
State postconditions
URL, checked, selected, enabled, attribute, value, dialog, option or semantic evidence — never “the UI looked right”.
Reconciliation
Indeterminate writes re-observed until proven or abandoned — never blindly replayed.
Credential isolation
SiliconPass release under fresh device-owner authentication; secrets never reach the MCP client.
Provider compatibility evidence
Site-by-site behavior recorded as dated evidence, revalidated per version — not marketed as universal.
FAQ
Questions developers actually ask
Why not Playwright?
Playwright provides broad browser coverage, automation and assertions. WebKitUI MCP focuses on a local WKWebView, native confirmation of specific actions and receipts for observed postconditions. Choose according to your workflow; neither event trust nor a UI receipt alone proves a backend commit.
Does WebKitUI require Touch ID?
Not for ordinary navigation and approved clicks. Only SiliconPass credential release requires fresh device-owner authentication — Touch ID, Apple Watch, or your macOS login password, whichever is available. If none is, no secret is released and nothing retries automatically.
What happens with the MacBook lid closed?
WebKitUI does not infer authentication availability from the lid. It asks macOS locally at the moment of use; the available device-owner method is device- and policy-specific. If macOS cannot present confirmation or authentication, the step fails closed, caches no approval and retries no write.
What happens when a write is indeterminate?
It stays indeterminate until reconciliation proves it. The runtime re-observes and may confirm a late postcondition, but it never re-dispatches the write — a retry is a new, separately approved transaction with its own idempotency key.
Does it work on every website?
No, and we won't pretend otherwise. Capabilities vary by site and version; each provider's behavior is revalidated as its own gate on the installed build. There's no anti-bot bypass, and cross-origin frame contents stay opaque.
Is commercial use allowed?
Personal noncommercial and qualifying uses stay free under the source-available grant, and evaluation is free for 30 days. Internal commercial production requires WebKitUI MCP Team — €299 per organization per year (excl. tax), up to five authorized developers and ten Macs. Commercial OEM, redistribution and hosted services outside the BUSL grant need a separate agreement. Earlier copies retain the licence supplied with them.
Where do credentials go?
They stay on your Mac. Secrets are isolated in SiliconPass, released only under fresh device-owner authentication, and are never returned to the MCP client. Password values are omitted from observations, and confirmations never expose a cookie or credential value.
Get started
Prove your next write.
Run it against your own consoles for a month. If the receipts earn their keep, license it.
Developer Preview 0.6.42
Apple silicon · macOS 15+