macOS companion app
macOS permissions
macOS permission grants are fragile. TCC associates a permission grant with the app's code signature, bundle identifier, and on-disk path. If any of those change, macOS treats the app as new and may drop or hide prompts.
Requirements for stable permissions
- Same path: run a release app from
/Applications/OpenClaw.app; keep development builds at one fixed path such asdist/OpenClaw.app. - Same bundle identifier: OpenClaw's bundle ID is
ai.openclaw.mac; changing it creates a new permission identity. - Signed app: unsigned or ad-hoc signed builds do not persist permissions.
- Consistent signature: use a real Apple Development or Developer ID certificate so the signature stays stable across rebuilds.
Ad-hoc signatures generate a new identity every build. macOS forgets previous grants, and prompts can disappear entirely until the stale entries are cleared.
Accessibility grants for Node and CLI runtimes
Prefer granting Accessibility to OpenClaw.app, Peekaboo.app, or another signed helper with its own bundle identifier instead of a generic node binary.
macOS TCC grants Accessibility to the code identity of the process it sees. If a Homebrew, nvm, pnpm, or npm workflow causes a shared node executable to receive Accessibility, any JavaScript package launched through that same executable may inherit GUI automation privileges.
Treat a node entry in System Settings as broad permission for that Node runtime, not as permission for one npm package. Avoid granting Accessibility to node unless you trust every script and package launched through that exact Node install.
Accessibility approval does not enable activity sharing. Settings -> Permissions -> Active computer detection is a separate, off-by-default control for sharing bounded idle duration with your Gateway. Turning it off clears retained activity without revoking Accessibility or disconnecting the node.
If you accidentally granted Accessibility to node, remove that entry from System Settings -> Privacy & Security -> Accessibility. Then grant the signed app or helper that should own UI automation.
Separate Computer Control grants
macOS keeps Accessibility, Event Posting, input listening, and Screen Recording in separate TCC buckets. One successful grant does not prove the others are usable. OpenClaw's Computer Control status checks Accessibility, Event Posting, and Screen Recording separately; this is why screenshots can succeed while clicks and typing fail.
An Accessibility row can also remain visibly enabled while its code requirement is pinned to an older build. When OpenClaw reports Accessibility grant may be stale, select OpenClaw under System Settings -> Privacy & Security -> Accessibility, remove it with -, then re-add /Applications/OpenClaw.app. Quit and reopen OpenClaw afterward because Accessibility trust can remain cached in the running process.
Recovery checklist when prompts disappear
- Quit the app.
- Remove the app entry in System Settings -> Privacy & Security.
- Relaunch the app from the same path and re-grant permissions.
- If the prompt still does not appear, reset TCC entries with
tccutiland try again. - Some permissions only reappear after a full macOS restart.
Example resets (using OpenClaw's bundle ID, ai.openclaw.mac):
sudo tccutil reset Accessibility ai.openclaw.macsudo tccutil reset ScreenCapture ai.openclaw.macsudo tccutil reset AppleEventsFiles and folders permissions (Desktop/Documents/Downloads)
macOS may also gate Desktop, Documents, and Downloads for terminal/background processes. If file reads or directory listings hang, grant access to the same process context that performs file operations (for example Terminal/iTerm, LaunchAgent-launched app, or SSH process).
Workaround: move files into the OpenClaw workspace (~/.openclaw/workspace) if you want to avoid per-folder grants.
If you are testing permissions, always sign with a real certificate. Ad-hoc builds are only acceptable for quick local runs where permissions do not matter.
