From 6c21037eabe5a31a4650a821d2fc9f9789138e15 Mon Sep 17 00:00:00 2001 From: Claude Code Bot Date: Wed, 12 Aug 2026 15:16:18 -0700 Subject: [PATCH] docs: clarify Automation permission dialog appears on every client, unattended MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The existing docs described how to manually pre-grant the permission but didn't call out that macOS shows the dialog on the client's own screen the first time it locks after being provisioned — even though lock-guard is invoked non-interactively over SSH — and that this happens on every client automatically, not just one set up by hand. Claude-Session: https://claude.ai/code/session_01Sasr2N9Rj9n8rv2sjwN2YJ --- CLAUDE.md | 5 ++++- README.md | 15 ++++++++++++--- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 13b3cbc..d7d4b7e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -47,7 +47,10 @@ All slices shipped. Install with `bin/install`; uninstall with `bin/uninstall`. `lock-guard`'s Google Meet detection drives Chrome via `osascript`. The first time this runs on a client, macOS prompts for Automation permission -(System Settings > Privacy & Security > Automation). Because `lock-guard` +(System Settings > Privacy & Security > Automation) — this dialog appears +on the client's own screen the moment its first lock cycle fires, even +though `lock-guard` itself is invoked non-interactively over SSH; expect it +on every client, not just the one set up manually. Because `lock-guard` runs non-interactively over SSH from launchd, there is no interactive session to click "Allow" in — grant this manually once per client, by running `~/.local/bin/lock-guard` interactively at a local Terminal on that diff --git a/README.md b/README.md index 524d5b6..cc8010d 100644 --- a/README.md +++ b/README.md @@ -75,9 +75,18 @@ Absent file uses the built-in default. Present file replaces it entirely `lock-guard`'s Google Meet detection requires macOS Automation permission. Clients don't need the repo cloned or `bin/install` run on them — `lock-fanout` pushes `lock-guard` to each client automatically over SSH the first time it -locks that client (see "How clients get `lock-guard`" below). After that's -happened once, grant the Automation permission by running the provisioned -copy interactively at a Terminal on the client: +locks that client (see "How clients get `lock-guard`" below). + +**Expect a permission dialog on the client's screen the first time it locks +after being provisioned.** macOS shows the Automation permission prompt on +the client machine itself — even though `lock-guard` is invoked +non-interactively over SSH — the first time it tries to talk to Chrome. This +happens automatically on every client, not just the one you set up manually. +Until someone is at that client to click Allow, Meet-tab detection silently +skips there (the process-list and microphone checks still work; see below). + +After that's happened once, grant the Automation permission by running the +provisioned copy interactively at a Terminal on the client: ```sh ~/.local/bin/lock-guard