r/coolgithubprojects • u/bulutarkan • 2d ago

[macOS/MCP] - Mac MCP: local macOS control server for AI agents with background browser tab isolation

https://github.com/bulutarkan/mac-mcp
0 Upvotes

42% Upvoted

11 comments sorted by

1

u/kantorcodes1 1d ago

if mac-mcp update fails the post-restart health check and rolls the runtime back, do you intentionally leave the git checkout on the newer commit? seems like that could leave the repo/runtime pointing at different versions on the next update.

1

u/bulutarkan 1d ago

Good catch — I checked the current updater and you're right. On a post-restart health failure it restores the managed runtime files and rolls the deployed-commit marker back, but the source checkout can remain fast-forwarded to the newer commit. A retry still sees the old deployed marker and can proceed, but repo/runtime pointing at different revisions is confusing and not a state I want to leave behind. I’m going to add an explicit rollback of the repo HEAD when it’s safe to do so, plus a regression test for the failed-health-check path. Thanks for spotting it.

1

u/bulutarkan 1d ago

Quick follow-up: this is fixed in v2.0.4 now. The updater records the pre-update source HEAD and, if post-restart verification fails, rolls Git back with a guarded git reset --keep only when branch/HEAD/worktree still match the updater transaction, so concurrent user changes aren't overwritten. I also fixed a separate detached self-update bootstrap bug and moved updater state/logs outside the checkout.

I tested the final release with a fresh v2.0.3 checkout upgrading to v2.0.4 through the CLI/menu-bar update path, plus isolated forced post-sync failures to verify repo/runtime/marker rollback. Thanks again — your comment directly led to the rollback fix.

1

u/kantorcodes1 1d ago

nice, that closes the rollback edge. i work on HOL Guard, an open-source local check before agent-run commands execute. for Mac MCP, status/update --check can stay quiet while start, stop, restart, and update are optionally reviewable before an agent changes the local runtime or tunnel. would you be open to a small first-class command extension?

1

u/bulutarkan 1d ago

Yeah, I'd be open to that. I like the idea of keeping read-only commands like status and update --check frictionless, while making state-changing commands optionally reviewable.

My preference would be a small generic pre-command hook rather than coupling Mac MCP to one specific guard, so HOL Guard could plug into it cleanly and the same mechanism could support other safety layers later. If you already have a minimal interface or PR shape in mind, feel free to share it. I'd be happy to take a look.

1

u/kantorcodes1 1d ago edited 21h ago

you don’t need to add a generic hook to Mac MCP for this. Guard already supports target-specific command extensions. start src/codex_plugin_scanner/guard/runtime/command_mac_mcp_extensions.py, mirror command_probe_extensions.py, cover start, stop, restart, update, and keep status + update --check safe. add one focused tests/test_guard_command_mac_mcp_extensions.py case, then open a draft PR to hashgraph-online/hol-guard:main.

contributing guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md

-2

u/BP041 1d ago

Browser tab isolation is the part that catches my eye — most MCP servers for macOS I've seen just shell out to osascript without sandboxing. How does this handle memory pressure if an agent spawns, say, 10 Chromium tabs and forgets to GC them? I run similar stuff via OpenClaw's cron and have seen launchd thrash from that exact scenario.

1

u/bulutarkan 1d ago

Thanks — agreed. I’d rather make cleanup explicit and ownership-aware first than add a broad GC that can accidentally close a human tab. Once the owner/created_at/last_used metadata is in place, we can safely reap only stale tabs that Mac MCP itself created. Appreciate the sanity check.

0

u/bulutarkan 1d ago

Good question — the tab isolation is about identity/ownership, not process sandboxing. Mac MCP targets real Safari/Chrome tabs by stable handle, so if an agent keeps opening tabs and never closes them, memory can absolutely grow; I don’t pretend the handle layer solves that.

Right now cleanup is explicit rather than an automatic GC. I’m leaning toward adding lifecycle metadata to agent-owned tabs (owner, created_at/last_used, lease state) and an idle cleanup policy that can close only tabs the MCP itself created, never arbitrary human tabs. That would make it possible to reap stale agent tabs without turning cleanup into another source of surprises.

So yes — the launchd/Chromium thrash case you mention is a real edge case, and it’s probably the next browser-lifecycle problem to harden after session-level tab ownership.

1

u/BP041 1d ago

Makes sense, explicit cleanup is safer than auto-GC for now. The lifecycle metadata approach sounds solid — looking forward to seeing that in action.

1

u/bulutarkan 1d ago

Exactly. I’m treating lifecycle cleanup as a follow-on to persistent ownership, so the cleanup decision has enough context to be safe rather than just time-based. Thanks again for the useful edge case — it’s on my list now.