Grant permissions
Autonomy asks macOS for two permissions: Accessibility and Screen Recording. Both are gates macOS itself enforces through Privacy & Security — Autonomy can’t act on your screen or read its structure without them, no matter how the agent connected to it is configured. This page explains why each one exists, how to grant it, and — because “I clicked yes” and “it actually took” aren’t always the same thing — how to check.
If you haven’t installed the app yet, start at Install first; permissions attach to that specific app bundle.
Why two permissions, and why they’re not optional
Accessibility is what lets Autonomy read the accessibility tree (roles, labels, values, focus, required/disabled state) and act through it — clicking a button by its semantic identity instead of guessing screen coordinates. This is the permission the accessibility model depends on for everything: without it, an agent has no reliable way to know what’s actually on your screen.
Screen Recording backs the visual-verification and vision fallback paths — confirming something rendered correctly, reading a value the accessibility tree doesn’t expose well, and the browser lane’s screenshot-based checks. AX-only review (reading forms, labels, and structure) can still work without it, but anything that needs to see the screen cannot.
Autonomy asks for both up front rather than lazily, because a mid-task permission prompt is exactly the kind of silent, unannounced interruption the product’s accessibility-first design is trying to avoid.
Granting them
The setup wizard that opens the first time you launch autonomy (a7y).app
walks you through a Permissions page as one of its seven steps (Welcome →
Choose your agent → Sign in → Permissions → How you work → What’s
connected → You’re set). Each row triggers the real system prompt when you
choose to grant it — the wizard doesn’t pre-answer anything on your behalf.
You can also grant, or double-check, both manually:
Open the Privacy & Security panes
System Settings → Privacy & Security → Accessibility, and System Settings → Privacy & Security → Screen Recording — labeled “Screen & System Audio Recording” on macOS 15 (Sequoia) and later. If you’d rather skip the navigation, jump straight there:
open "x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility"
open "x-apple.systempreferences:com.apple.preference.security?Privacy_ScreenCapture"Toggle the app on
Modern System Settings (macOS 13 Ventura and later) lists each app with a
per-app toggle — there’s no ”+” button here. Find autonomy (a7y) in each
pane and switch its toggle on. If it isn’t listed yet, it appears once it
first requests the permission, alongside an “Open System Settings” prompt.
Restart if Screen Recording needs it
Screen Recording requires quitting and reopening the app — the grant doesn’t take effect until you do, and macOS itself prompts with a “Quit & Reopen” button right after you toggle it on. Treat that as mandatory, not optional. Accessibility usually takes effect immediately for a process that’s already running; relaunch it only as a fallback if it still isn’t detected.
Verifying it actually took
The most reliable check is the doctor, covered in full on the next page:
"/Applications/autonomy (a7y).app/Contents/Resources/bin/a7y-cli" doctorLook for macos-accessibility and macos-screen-recording (or the
equivalent) under the macOS Permissions phase. You can also use the app’s
own Run Doctor command (in the toolbar or command palette) to see the same
output in a “Doctor Results” window without opening a terminal at all.
There’s a real, easy-to-miss distinction here. a7y-cli doctor’s
Accessibility/Screen Recording checks test the permission of whatever
process is running the CLI (your terminal, most likely) — they probe with
osascript/screencapture, not by asking the app bundle about its own
grant. That’s a different grant than the one the app bundle itself needs
and requests through its setup wizard. If doctor reports Accessibility as
missing from a terminal that has never been added to System Settings, that
failure is about the terminal, not about whether the app itself is
authorized. When in doubt, use the app’s own Run Doctor command or its
permissions output instead of a bare terminal invocation, and add your
terminal to both panes too if you plan to drive a7y-cli from it directly.
Optional permissions
Depending on the workflow you choose in the setup wizard, Autonomy may also probe for microphone, speech recognition, and Personal Voice access — these support voice input and Personal Voice output, and are requested only when relevant, not as a blanket ask.
Pitfalls
- Restart your terminal, not just the app, if you’re driving
a7y-clifrom a shell. A shell session opened before you granted its permission won’t see the update until it’s restarted. - Permissions survive reinstalls, but only if the app’s identity doesn’t
change. See Install for why
plugins/autonomy/scripts/install-app.shrefuses identity-changing replacements by default — that refusal is what protects the grants you just made here. - A denied Screen Recording grant doesn’t block everything. AX-only review (forms, labels, document structure) keeps working; only visual verification and vision-fallback paths degrade.
If either permission won’t stick, see Permissions missing or not taking effect. Otherwise, continue to Run the doctor.