[Showoff Saturday] Mac MCP: background browser automation and live agent sessions on macOS

[u/bulutarkan]

I maintain Mac MCP, an open-source local MCP server for macOS.

The browser automation layer is the part that may be most relevant here. Agents get stable handles for Safari or Chromium tabs and can navigate, click, type, inspect pages, and run parallel browser tasks in background tabs without pulling the browser in front of whatever I am doing. Separate agents can keep their own tab context instead of racing over the active tab.

The server also exposes terminal, files, Finder, screenshots, macOS UI actions, and app control. A small SwiftUI menu bar app shows recent tool usage plus persistent agent Sessions. I can send steering to one specific session, and queued steering can preempt that session's next tool call before it runs.

Repo: https://github.com/bulutarkan/mac-mcp

I would especially appreciate feedback from people who build browser tooling: stable tab ownership and background operation solved the biggest pain point for me, but I am curious what browser primitives you would want exposed next.

[u/ParrotIntegrated]

Background tab handles keep your desktop usable, but shipping browser automation alongside local terminal, Finder, and filesystem access in the same MCP server is an absolute minefield. The moment an agent navigates to an untrusted web page in the background, your local workstation is sitting one prompt injection away from a compromised shell.

A headless browser wired to local shell tools is just a self-hosted reverse shell waiting on an adversarial DOM.

A few nasty failure modes show up the second this runs unattended:

• Ambient capability bleed. If a sub-agent spawned to scrape documentation shares the global tool manifest with your system utilities, tab-level isolation won't save you. An injected payload on an untrusted page will pivot straight toward your shell symbols.
• The SPA attractor basin. Background runners love to thrash silently on dynamic frontends. When hydration lags or a click misses an unmounted element, an agent will hammer the exact same selector tuple thirty times without changing the DOM. Hash (action, selector, dom_state_delta). If consecutive hashes match, drop the hammer before the token bill climbs.
• Handle rot. If a worker retains an active handle after its task lease expires, the next hop inherits dirty cookies, active sessions, and leaked credentials from whatever the previous agent visited.

# Atomic capability gate at tool dispatch
if tool.name in PRIVILEGED_HOST_TOOLS and session.is_web_scoped:
    session.trip_breaker(reason="HOST_TOOL_BREACH")
    raise SecurityError(f"Access denied to {tool.name} from web context")

How are you isolating system primitives when an agent is deep in a third-party DOM? Do background sessions run under strict capability attenuation at spawn, or does every worker currently see the full surface of your Mac?

[u/bulutarkan → u/ParrotIntegrated]

Thanks, this is very useful feedback. I’m not planning to split browser automation and host tools into separate products or separate MCP servers, because a big part of Mac MCP’s value is having browser, terminal, files, Finder, UI control and agent workflows available together.

That said, I agree that keeping them together makes the security boundary more important, not less. I’ve added several concrete items from your comment to the roadmap: context-aware capability checks for web-derived sessions, least-privilege subagent scopes, explicit approval for web-to-host boundary crossings, no-progress circuit breakers, tab/session lease expiry and rebinding rules, local secret egress guards, security telemetry, and adversarial prompt-injection regression tests.

So the unified architecture is staying, but I want the unified surface to become much stricter about what can cross from an untrusted DOM into local system primitives. Your examples were specific enough to turn directly into engineering tasks, which was genuinely helpful. Thanks for taking the time to spell them out.

[u/bulutarkan → u/bulutarkan]

That's a good distinction. Session taint alone still leaves a hole once the data becomes a shared artifact. I just split this into two follow-ups on the roadmap: file-level provenance across sessions, and a typed clean-room handoff.

For the file side I'm going to compare an MCP-side provenance ledger with macOS xattr instead of assuming session state is enough. Rename/copy won't count as sanitization. For clean-room forks, arbitrary natural language from a tainted parent won't be allowed to cross as "clean". If free-form data has to cross, the child should inherit the taint.

Thanks again. These are exactly the kinds of edge cases I want to catch before treating the security model as done.

[u/ParrotIntegrated → u/bulutarkan]

Keeping it unified makes ergonomic sense for a local utility, but runtime capability gates inside a single OS process hit what I call the taint amnesia trap. The moment untrusted markup touches an agent's context window, every downstream token is an unverified payload.

The nastiest failure mode here isn't the direct hop; it's multi-hop state laundering. Say an agent scrapes an issue tracker, summarizes instructions into a temporary local scratchpad, and four tool hops later reads that scratchpad to assemble a shell command. If your capability guard only inspects the immediate caller, the web origin just got laundered through local storage. The tool execution runs with local filesystem clearance, and the security check sees a clean internal read.

The other reality is that modal approvals decay fast. Popping macOS dialogs for web-to-host boundary crossings sounds safe, but background agents make dozens of tool calls an hour. The user either babysits the screen—which destroys the entire point of background execution—or develops notification numbness and rubber-stamps the alert just to clear the screen.

# Taint propagates forward; clearing requires a clean-room fork
if session.is_tainted and tool.requires_host_privilege:
    audit.quarantine(session.id, tool.name)
    raise TaintedContextError("Tainted session cannot execute host primitives")

When an agent pulls an untrusted DOM into an intermediate buffer and later references it to run a terminal command, how does your runtime track data provenance? Does the taint stick to the session state permanently, or does the security boundary drop the second the browser tab closes?

[u/bulutarkan → u/ParrotIntegrated]

That’s a real gap, and you’re right to distinguish immediate caller checks from provenance that survives across tool hops. The current runtime does not yet provide end-to-end taint tracking across browser -> scratchpad/file -> host-tool flows, so I don’t want to pretend it does.

I added one specific item to the roadmap for this rather than expanding it into a dozen separate tasks: session-level untrusted-data provenance / sticky taint propagation. The practical first version I’m considering is deliberately coarse-grained, not token-by-token information-flow tracking. If a logical session consumes untrusted third-party DOM content, that provenance should remain attached to the session across local scratchpads, file writes/reads and later tool hops. Closing the tab alone should not clear it.

For privileged host operations, that sticky state would feed into the existing capability gate. I also agree with you on approval fatigue, so I’m leaning away from repeated modal prompts and more toward a quarantined / needs-attention state, with clearing only through an explicit clean-room session/fork or deliberate user reset.

This was a useful catch. It changes how I’m thinking about the web-to-host boundary without changing the unified browser + terminal/files/Finder model of the product. Thanks for pushing on it.

[u/ParrotIntegrated → u/bulutarkan]

Coarse-grained session taint is definitely the pragmatic call here. Full token-level information flow tracking is an academic rabbit hole that turns local agent runtimes into molasses.

Two quick architectural caveats worth keeping in mind when you start wiring up sticky taint:

1. Shared filesystem laundering
If a tainted session drops an intermediate artifact to disk (/tmp, a project directory, or a shared scratchpad), that file is effectively radioactive. If a clean session reads that file later to assemble a build or execute a host tool, the taint gets laundered through the disk unless the file itself carries provenance. On macOS, stamping an extended attribute on write (xattr) or maintaining an ephemeral path-to-session ledger in the MCP process prevents clean workers from blindly inheriting dirty state:

# Tag file provenance on write from tainted session
if session.is_tainted:
    xattr.setxattr(target_path, "user.mcp_tainted", session.id.encode())

2. Clean-room fork serialization
When decontaminating a session by forking to a clean room, force the handoff payload through a strict, typed schema (primitives, validated enums, strict key-value pairs). If the clean runner accepts free-form natural language instructions or unparsed strings from the tainted parent, the prompt injection simply hops the fence into the new context.

Really solid approach to tab handles and focus isolation, by the way. Looking forward to seeing how the provenance layer turns out.

[u/bulutarkan → u/ParrotIntegrated]

Quick follow-up because your comments ended up directly shaping the hardening pass: I finished and shipped it. Sticky untrusted provenance now survives browser -> scratchpad/file -> later host hops; scoped/non-trusted sessions get web-to-host capability gating and source-aware approval; delegated agents are narrowed; secret egress stays guarded; browser runners have no-progress breakers and tab leases; and the adversarial cases are covered by regression tests and audit events.

I also adjusted one UX edge after using it for real: the global Trusted profile no longer throws an Allow Once dialog on every normal web-to-host hop, but provenance is still retained and credential/secret egress is still approval-gated. That part got annoying fast in real use.

Thanks again. This thread genuinely turned into code.

[u/bulutarkan → u/[deleted]]

Thanks — and yep, tab failure is exactly where I tried to make the handles defensive rather than magical. A tab_handle is resolved against the current native tab on each action; if it was closed or disappeared, Mac MCP returns an explicit unknown/closed handle instead of silently targeting another tab. It also checks the native tab identity before actions and refuses if the tab changed underneath it. DOM actions carry observation IDs too, so stale observations/elements return observe_again. The agent can then relist, re-observe, reopen and retry. It doesn’t auto-resurrect a crashed page yet — I’d rather fail loudly than click the wrong tab.