Devices

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.

┌────────────────┐  ┌────────────────┐  ┌──────────────────┐
│  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

Owletto Mac appPairs as the macos device — screen time, local files, and shell, behind a GUI.macosOwletto Chrome extensionDrives your real logged-in Chrome — timelines and internal tools with no public API.via the Mac applobu daemonRegisters any machine as a headless device; mints its own durable token from lobu login.headless

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 — flags, auth, and unattended setup
• Device connectors — pairing Owletto and capability gating
• Automations — the jobs devices execute