# Devices

> Pair your machines so Lobu can run connector syncs, actions, and Automations on the device that holds the data — including your local Claude Code, Codex, or OpenCode sessions.

A **device** is one of your machines registered as a worker: your Mac, a home server, any box with the CLI. Cloud workers are stateless and sandboxed; a device can reach what no cloud worker can — local files, shell, logged-in browser sessions — and it is where your locally installed coding agents live.

```text
┌────────────────┐  ┌────────────────┐  ┌──────────────────┐
│  Automations   │  │  Pinned        │  │  Agent turns     │
│  schedule ·    │  │  connector     │  │  chat · MCP      │
│  event · run   │  │  syncs+actions │  │  clients         │
└───────┬────────┘  └───────┬────────┘  └────────┬─────────┘
        └───────────────────┼────────────────────┘
                            ▼
            ┌───────────────────────────────┐
            │  Lobu gateway                 │
            │  (cloud or self-hosted)       │
            │  queues work for its devices  │
            └───────────────┬───────────────┘
                            │ claimed on poll
                            ▼
                ┌───────────────────────┐
                │  lobu daemon          │
                │  (your machine)       │
                └───────────┬───────────┘
                            │
                ┌───────────┴─────────────┐
                ▼                         ▼
   ┌─────────────────────┐      ┌───────────────────────┐
   │ shell · files ·     │      │ Claude Code · Codex · │
   │ browser, gated by   │      │ OpenCode CLIs — or    │
   │ declared caps       │      │ the live session      │
   └─────────────────────┘      └───────────────────────┘
```

## Register a device


Every path lands on the **Devices** page in the web app. The CLI route is two commands: `lobu login`, then `lobu daemon` — it mints its own long-lived device token from that login and re-mints before expiry.

## What triggers device work

Three things land on a device, all claimed through the same poll:

- **Automations** — every activation mode: a schedule, a connector or workspace event, or a manual run. A device-pinned Automation executes where it is pinned, so the run happens next to your files and your installed agent CLIs.
- **Pinned connections** — a connection bound to the device collects its feeds there and performs its actions there, instead of on cloud workers.
- **Agent turns** — a chat message or an MCP client (Claude Desktop, Cursor, …) asking an agent for something local — run a shell command, read a file — becomes an action the gateway routes to the device advertising that capability.

## How work executes

1. **Register** — advertise platform, label, and capabilities (`os.shell`, `os.files`, …).
2. **Poll** — ask for work: connector syncs, actions, and Automations pinned to this device.
3. **Execute** — connector work runs in an isolated child on your machine; Automation runs spawn your installed agent CLI.
4. **Report** — output and exit status flow back through the same poll connection.

A device only ever claims work whose declared capability matches what it advertises, and credentials for device-pinned connections are delivered to that device alone over its user-scoped token.

## Local agents, two modes

Automations declare an agent kind. On a device, the daemon resolves that kind to the binary installed on *that* machine:

- **Headless** — each run spawns `claude`, `codex`, or `opencode` with the automation's prompt and the run-scoped session token. Nothing of yours is uploaded; the model call happens from your machine, under your subscriptions.
- **Interactive** — start `lobu daemon` inside a Claude Code, Codex, or OpenCode session and it detects that session automatically. Work for that agent kind is handed to the live session instead of spawning a child, so results land in the conversation you're already in. Each session registers its own identity; your host's durable device mapping is untouched.

## Pinning

Pin a connection's syncs/actions or an Automation to one device when the data lives there: local files, screen time, browser-only sources, or egress from your network. Unpinned cloud-capable connectors keep running on cloud workers. If a pinned device goes offline, its work waits until the next poll — nothing silently reroutes elsewhere.

## Next

- [`lobu daemon` reference](/reference/cli/#daemon) — flags, auth, and unattended setup
- [Device connectors](/connectors/data-tools/#device-connectors) — pairing Owletto and capability gating
- [Automations](/getting-started/automations/) — the jobs devices execute