OpenLogi macOS Permissions Triage

4. Responsible process

macOS attributes a TCC request to the responsible process, which for a plain child process is the parent. An agent spawned directly by the GUI therefore asks with the GUI's identity, and the user's grant to OpenLogi Agent appears to do nothing.

The launch paths that break the chain live in openlogi-desktop/src/services/ipc/launch.rs and run in this order:

• registered login item → launchctl kickstart gui/<uid>/<service label> (launchd spawns it directly: its own responsible process, plus crash respawn from the service plist's KeepAlive). The registration itself is SMAppService in openlogi-desktop/src/platform/registration/macos.rs, driven by the launch_at_login setting.
• packaged helper, not registered → /usr/bin/open -g -n <bundle> (LaunchServices parents it under launchd, so it is its own responsible process — but unsupervised)
• bare dev binary → disclaim::Command (wraps responsibility_spawnattrs_setdisclaim)

Never spawn a helper with plain std::process::Command on macOS. Check with:

sudo launchctl procinfo $(pgrep -x openlogi-agent) | grep -i responsible

It must name the agent itself. OpenLogi.app or Terminal.app there means every grant on that machine is being ignored.

5. What the APIs actually do

• IOHIDCheckAccess — queries only. Never prompts, and never registers the app in System Settings, so an app that only ever calls this cannot be granted: the user has no row to tick.
• IOHIDRequestAccess — prompts. Blocks the calling thread until the user answers, so it must not run on the async runtime. It is also not real-time: after a grant or revoke the calling process keeps seeing the old answer until it restarts. That is why the agent calls binary_watch::relaunch_after_input_monitoring_grant().
• IOHIDDeviceOpen — denial is silent. There is no TCC-specific error, so the transport pairs every open failure with openlogi_hid::permissions::has_access() and says which case it is (§1). Keep it that way: a bare Failed to open device is not reportable.

6. Invariants — do not break these

1. Only the agent holds the long-running app's HID/input permissions. Any UI that reports permission state must read it from the agent over IPC, never by querying its own process. Direct CLI diagnostics are a separate, explicit identity and must not be used to infer the agent's grant.
2. Every helper launch establishes its own responsible process (§4), and the spawn result is checked — a silently failed disclaim leaves the agent running under the GUI's identity, which is invisible until a user reports it.
3. TCC matches the full designated requirement. A bundle-identifier or signing-identity change can invalidate every existing grant. The Verify production bundle identities step in .github/workflows/build.yml is load-bearing; do not weaken it.
4. Sign inside-out. The helper needs its own stable designated requirement so its grant survives updates; --deep cannot give it one. See xtask/src/commands/macos/bundle/signing.rs.
5. Prompt from the process that needs the permission, not from whichever process happens to be running. A TCC grant is scoped to the identity that asked.

7. Check current evidence

Do not carry a "currently fixed/broken" snapshot in this skill. Query the current tracker and latest release notes, identify the reporter's release, and read the matching report, comments, current code, and logs. Treat the report's diagnosis as a claim until the provenance and direct evidence in §§1–4 establish the root cause. Re-check linked upstream transport issues before attributing a probe timeout to them.

8. What this cannot fix

Say so plainly rather than promising a fix:

• Apple's + picker not browsing into bundles.
• IOHIDDeviceOpen's silent denial — we can only infer it by checking access separately.
• A stale tccd decision that needs a full logout, or an MDM policy.
• Ad-hoc-signed local builds: their designated requirement is cdhash-based, so the grant goes stale on every rebuild. Use an Apple Development identity for dev bundles.