Permissions
On macOS, the real state of each permission Sirio can use, how to ask for one, and where notifications come from.
A command-line tool or an agent in a Sirio pane runs inside Sirio’s macOS privacy envelope. macOS treats a screen capture or an Apple Event from claude in a pane as Sirio’s own, and grants or refuses it on Sirio’s behalf. Settings → Permissions shows where that envelope stands and lets you change it.
The six permissions
On macOS the page lists six permissions under macOS Permissions, in this order:
| Permission | What it is for |
|---|---|
| Notifications | Alerts when agents finish or need input |
| Screen Recording | Screenshot, visual automation and UI inspection tools |
| Accessibility | Keystroke injection, window control and UI automation tools |
| Full Disk Access | Projects or worktrees that touch folders macOS protects |
| Automation | Apple Events from scripts that control other local apps |
| Local Network | Finding and reaching development servers on your network |
The states
Each row shows its state in lower-case words:
- granted: macOS allows it.
- denied: macOS refuses it.
- not requested: Sirio has never asked. For Notifications and Automation, macOS has not shown its prompt either; for Screen Recording and Accessibility, a tool in a pane may already have made macOS ask.
- check manually: macOS gives no reliable answer. Local Network always reads this, because no public API reports it. Full Disk Access reads granted when Sirio can open the privacy database that only Full Disk Access unlocks, and check manually otherwise. Automation asks about System Events, and reads check manually while System Events is not running.
For Screen Recording and Accessibility, macOS answers the same way whether you refused the prompt or never saw it. Sirio remembers whether it has asked, so once it has, a row without the permission reads denied.
A row reads checking… until the first answer arrives. After you press Request or Trigger Prompt, the row reads asking… and hides its button until Sirio reads it again.
When the page reads again
The page reads every permission again when you open it, when you press Refresh, and each time you come back to Sirio while the page is on screen. That last one covers a switch you flip in System Settings: return to Sirio and the row shows the change.
One button per row
Each row offers one action, and the permission and its state decide which.
- Request shows macOS’s own prompt. Notifications, Screen Recording and Accessibility offer it while they read not requested.
- Trigger Prompt makes macOS ask about Automation or Local Network, which have no request API and only prompt on first use. Automation offers it until it reads granted or denied, and Local Network always does. For Automation, Sirio sends System Events a harmless Apple Event from
osascript, the way an agent script would, and that launches System Events when it is not running. For Local Network, Sirio sends one Bonjour query for the services on your network. - Open Settings opens the matching pane of System Settings. Full Disk Access always offers it, because macOS has no prompt for it. Every row that reads granted or denied offers it too: macOS shows each prompt once, and after that only the switch in System Settings changes the answer. Notifications also offers it when it reads check manually.
After Request or Trigger Prompt, Sirio reads that row again. For Notifications and Automation it waits for your answer first. If the Notifications prompt sits unanswered for two minutes, Sirio stops waiting and reads the row anyway, and the prompt stays up. Screen Recording and Accessibility come back at once, so they read denied until you turn their switch on in System Settings.
At startup
Sirio asks for nothing when it starts. At launch it reads the Notifications state once, which never shows a prompt, to decide how to deliver notifications. Sirio itself asks only when you press a button on this page. A tool in a pane can still make macOS ask on Sirio’s behalf the first time it uses a permission.
Where notifications come from
Once you allow Notifications, notifications come from Sirio itself. They carry Sirio’s icon, follow Sirio’s switch in System Settings → Notifications, and show as a banner even while Sirio is the app in front. Sirio still raises none for an agent in the tab you have open while its window is active; Tray, notifications and persistence covers when a notification fires.
Until you allow them, notifications go through Script Editor, so they carry its icon and follow its switch. If you deny them, Sirio honours your answer and shows none.
Sirio picks the route from the last Notifications state it read, at launch or on this page. If you change the switch in System Settings, open this page or restart Sirio so it reads the new state.
A Sirio you build with cargo runs outside an app bundle, so its notifications always go through Script Editor and its Notifications row reads check manually. Scripts/build-app-bundle.sh <binary> <version> <output.app> wraps a build in an app bundle; see Build from source.
Linux and Windows
The Permissions category appears on every platform. On Linux and Windows it holds only the browser origin grants below, since the six rows above belong to macOS. Sirio posts notifications there with notify-send on Linux and as a notification-area balloon on Windows.
Browser origin grants
Browser origin grants lists every origin you have let an agent reach in the in-app browser, with Revoke beside each one and Revoke all at the top. An origin is a scheme and a host, plus the port when the address names one, such as http://localhost:4321. While it holds none, the list reads “No browser origins have been granted.”
The grants come from a prompt in the browser tab itself. It appears only in a tab the control socket has flagged as agent-driven: when such a tab heads for an origin with no grant, it stops and asks “Allow agent browser access to http://localhost:4321?”, with Allow and Deny beside the question. Allow saves the origin, so the agent’s next try goes through. Deny saves nothing, and the next try asks again.
Sirio keeps the grants in its database, so they survive a restart, and a revoke reaches open browser tabs at once. Browser automation covers driving the browser from a script.