[iamnbutler]

AIDE runs desktop-tools' host as its own child process ("Computer Use"), so macOS charges the host's Accessibility and Screen Recording use to AIDE: one row in System Settings, no second app to approve (tccd log: AttributionChain: responsible=com.iamnbutler.aide … requesting=com.iamnbutler.aide.computer-use). Until now AIDE carried this as a patch; this PR moves it upstream so AIDE can pin a plain commit. Documented in docs/embed.md, "Run the host as an app's own helper".

Host flags (desktop-tools-host)

• --client <team>:<identifier>: serve only that signed client, by the peer's audit token.
• --protect <pid>: refuse agent input whose target is that process (SELF_TARGET_REFUSED), whether or not a caller handler is set. The embedding app guards its own prompts, so the on-screen own-window check applies only while caller approval is enforced (an app with a main window always has one open).
• --parent <pid>: exit when that process does.
• --tools: print {tools, instructions} and exit, so the app's tool list can't drift from the code.
• --overlays: draw the agent cursor and window outline, through the runtime (DesktopTools), as the menu bar app does.
• --confirm-stdio: ask the app to confirm agent-supplied passwords over stdout/stdin ({"confirm": id, "request": …} / {"answer": id, "allowed": bool}). The request now also carries agent, agent_name, app and web_host, so an app can word its own question.

With --overlays or --confirm-stdio the host serves through the runtime, so the client must be signed by the host's own team.

A request can name its agent

{"id", "tool", "arguments", "agent": {"key", "name", "kind"}}. One client serving many agents (AIDE: every thread's call comes from AIDE's process) now gets a cursor and outline per agent, named and colored for it, and the password confirmation names the agent. Hooks.Call and Hooks.TargetWindow carry it; Hooks.showPointer runs the pointer hook inside the call's task-local so the hook can read it.

SYSTEM_UI_REFUSED

Every host refuses agent input to System Settings and to the system's permission and password prompts (UserNotificationCenter, SecurityAgent, LocalAuthentication UI, coreautha, loginwindow). A Privacy & Security switch, Allow on a "would like to control this Mac" prompt, or an administrator password would give an agent more than the user did. Opening, reading, hiding and quitting still work. desktop_system_key is refused while one of them is frontmost.

The whole of System Settings, not only Privacy & Security, because the pane can't be told apart reliably: its titles are localized (on macOS 27 the Accessibility list is titled "Device Control and Data Access"), subpanes share titles with top-level panes (Accessibility), and the sidebar builds the selected row's button only while it's scrolled into view (checked by inspecting System Settings on this Mac).

Tests

swift test: 58 + 32 pass, including new AgentIdentityTests (named agent wins, kind picks the color, key per thread) and SystemUITests. Live verification through AIDE is in progress and will be added here before this leaves draft.

🤖 Generated with Claude Code