---
summary: "PeekabooBridge integration for macOS UI automation"
read_when:
  - Hosting PeekabooBridge in DaoCore.app
  - Integrating Peekaboo via Swift Package Manager
  - Changing PeekabooBridge protocol/paths
  - Deciding between PeekabooBridge, Codex Computer Use, and cua-driver MCP
title: "Peekaboo bridge"
---

DaoCore can host **PeekabooBridge** as a local, permission-aware UI automation
broker. This lets the `peekaboo` CLI drive UI automation while reusing the
macOS app's TCC permissions.

## What this is (and is not)

- **Host**: DaoCore.app can act as a PeekabooBridge host.
- **Client**: use the `peekaboo` CLI (no separate `daocore ui ...` surface).
- **UI**: visual overlays stay in Peekaboo.app; DaoCore is a thin broker host.

## Relationship to Computer Use

DaoCore has three desktop-control paths, and they intentionally stay separate:

- **PeekabooBridge host**: DaoCore.app can host the local PeekabooBridge socket.
  The `peekaboo` CLI remains the client and uses DaoCore.app's macOS
  permissions for Peekaboo automation primitives such as screenshots, clicks,
  menus, dialogs, Dock actions, and window management.
- **Codex Computer Use**: the bundled `codex` plugin prepares Codex app-server,
  verifies that Codex's `computer-use` MCP server is available, and then lets
  Codex own native desktop-control tool calls during Codex-mode turns. DaoCore
  does not proxy those actions through PeekabooBridge.
- **Direct `cua-driver` MCP**: DaoCore can register TryCua's upstream
  `cua-driver mcp` server as a normal MCP server. That gives agents the CUA
  driver's own schemas and pid/window/element-index workflow without routing
  through the Codex marketplace or the PeekabooBridge socket.

Use Peekaboo when you want the broad macOS automation surface and DaoCore.app's
permission-aware bridge host. Use Codex Computer Use when a Codex-mode agent
should rely on Codex's native computer-use plugin. Use direct `cua-driver mcp`
when you want the CUA driver exposed to any DaoCore-managed runtime as a normal
MCP server.

## Enable the bridge

In the macOS app:

- Settings → **Enable Peekaboo Bridge**

When enabled, DaoCore starts a local UNIX socket server. If disabled, the host
is stopped and `peekaboo` will fall back to other available hosts.

## Client discovery order

Peekaboo clients typically try hosts in this order:

1. Peekaboo.app (full UX)
2. Claude.app (if installed)
3. DaoCore.app (thin broker)

Use `peekaboo bridge status --verbose` to see which host is active and which
socket path is in use. You can override with:

```bash
export PEEKABOO_BRIDGE_SOCKET=/path/to/bridge.sock
```

## Security and permissions

- The bridge validates **caller code signatures**; an allowlist of TeamIDs is
  enforced (Peekaboo host TeamID + DaoCore app TeamID).
- Prefer the signed bridge/app identity over a generic `node` runtime for
  Accessibility. Granting Accessibility to `node` lets any package launched by
  that Node executable inherit GUI automation access; see
  [macOS permissions](/platforms/mac/permissions#accessibility-grants-for-node-and-cli-runtimes).
- Requests time out after ~10 seconds.
- If required permissions are missing, the bridge returns a clear error message
  rather than launching System Settings.

## Snapshot behavior (automation)

Snapshots are stored in memory and expire automatically after a short window.
If you need longer retention, re-capture from the client.

## Troubleshooting

- If `peekaboo` reports "bridge client is not authorized", ensure the client is
  properly signed or run the host with `PEEKABOO_ALLOW_UNSIGNED_SOCKET_CLIENTS=1`
  in **debug** mode only.
- If no hosts are found, open one of the host apps (Peekaboo.app or DaoCore.app)
  and confirm permissions are granted.

## Related

- [macOS app](/platforms/macos)
- [macOS permissions](/platforms/mac/permissions)
