Product

A phone-sized control plane for the agents on your computers.

DevOS Mobile is the iPhone app; a browser can pair with it and show the same inbox. DevOS Companion is the Mac app that makes a computer reachable and runs the bridge to its agents. Both are in beta.

Three ways to use it on a computer

Three ways to use DevOS on a computer
AspectDevOS Companion (app)Command line + browserAnother computer’s browser
What it isThe Mac app, which runs the bridgeThe same bridge as a background service, managed from a page in the Mac’s browserA second screen for computers already running DevOS; it runs nothing itself
Agents, terminals, files, review, push, sandboxesYesYesShows them from the computers it is paired with
Remote control of the Mac’s screenYesNo: needs the app’s Screen Recording and Accessibility permissionsThrough a Mac that runs the app
Menu barYesNoNo
UpdatesOne clickRun the install command againAlways the relay’s newest page
KeychainItems only the signed bridge readsThe same signed bridgeKeeps none of a Mac’s keys

Source: the product README.

Walkthrough

The app, one step at a time

Scroll, press the arrow keys, or use Previous and Next. The screens are recreated from the app’s own SwiftUI views with sample data. Illustrative, recreated from the app UI; replace with captured screenshots.

Step 1 of 11

Shipped Invites

Invite a person by link, from anywhere.

Send a one-time link by any channel. The invited device joins through the relay, so it does not need your Wi-Fi and nobody scans anything at your Mac. You approve a link by matching a four-digit code; a QR code is for in person.

A person is still in the loop: you make the invite and approve the link. Your own first pairing still starts with a setup code shown on the Mac.

Illustrative: recreated from the app’s views, with sample data.

Invite a person by link, from anywhere

An invite is a link or a QR code. The owner makes it on the Mac or the phone and can send the link by any channel. The invited device joins through the relay with a handshake that mixes the invite secret into the end-to-end keys, so it does not need the same Wi-Fi and nobody has to scan anything at the Mac. A link waits for the owner to approve after the two sides match a four-digit code. The owner’s own first pairing still starts with a setup code shown on the Mac. The relay sees that a join happened and which computer it was for, not the secret.

  • Sealed end to end
  • Same machine, SSH or setup step
  • Shipped
  • Trust boundary

What still needs a person

  • The owner makes the invite
  • The owner approves a link after matching a four-digit code
  • The owner’s own first pairing: a setup code shown on the Mac

What it no longer needs

  • The same Wi-Fi
  • Scanning anything at the Mac
  • The relay seeing the invite secret

Parts: hover, focus or press one for what it does and what it can see

Read this diagram as text

Layers, top to bottom

  1. The owner (a human step).
    • 1. Owner makes an invite, shipped, Invite someone, or devos user add. On the Mac’s desk, under a Mac’s Phones on the owner’s phone, or with devos user add. Pick Member or Guest. A guest sees only chosen projects or sessions until an end date the Mac enforces. Can see: Nothing yet.
    • 2. Share a link, or show a QR, shipped, link: by any channel. A link works once and lasts 24 hours; send it by Messages, email or anything else. A QR code is for in person and lasts 10 minutes. Can see: The channel you chose sees the link, so pick one you trust.
  2. The invited person (any network).
    • 3. Opens it in DevOS Mobile, shipped, or the relay’s browser client. The link opens the app. The device makes its own key and joins through the relay. The Mac’s key comes from the link, so the relay cannot put its own in. Can see: The device and the Mac, nobody else.
    • 4. Reads back a four-digit code, shipped, link invites only. Both sides show the same four-digit code taken from the handshake. The invited person reads theirs to the owner, in whatever way suits them. Can see: The two devices.

    Trust boundary below this layer. Everything after the # in the link stays on the device. The relay is told only a hash of the invite id.

  3. Relay (carries the sealed join).
    • Join passes through the relay, shipped, sealed, not readable. The relay forwards the handshake to the Mac that listed the invite’s hash. Without the secret it cannot finish the handshake or swap a key in. It sees routing, timing and that a join happened. Can see: A hash of the invite id; Routing and timing; That a join was asked for.
  4. Back on the owner’s side (a human step).
    • 5. Owner approves, shipped, after matching the code. The companion and the owner’s phones show: Bo wants to join Studio as a Guest, code 4821. Approve only when the code matches what Bo reads out. Deny cancels the invite. A QR invite admits at once and tells the owner’s phones afterwards. Can see: The owner decides.
    • Role and end date, shipped, member, or guest until a date. The new device gets a role. A guest’s end date is enforced on the Mac, which removes the device when it passes. In the first release, guests can watch; guests who can reply are off. Can see: Only what the role allows.

Connections

  • 1. Owner makes an invite to 2. Share a link, or show a QR: On the same machine or link
  • 2. Share a link, or show a QR to 3. Opens it in DevOS Mobile: On the same machine or link (link or QR)
  • 3. Opens it in DevOS Mobile to Join passes through the relay: Sealed end to end (sealed join)
  • Join passes through the relay to 5. Owner approves: Sealed end to end (asks the owner)
  • 5. Owner approves to Role and end date: On the same machine or link

In short

  • What still needs a person: The owner makes the invite; The owner approves a link after matching a four-digit code; The owner’s own first pairing: a setup code shown on the Mac.
  • What it no longer needs: The same Wi-Fi; Scanning anything at the Mac; The relay seeing the invite secret.

iPad

In a regular-width window the iPad shows two columns: the inbox or the computers on the left, the open screen on the right. A narrow window keeps the phone’s single stack. Every iPhone screen is available on iPad.

System architecture

Phones, tablets and a browser reach your computers through a relay on Cloudflare. Agents run on your computers, never on the relay. Session payloads are sealed end to end between your devices and your computers. The relay still sees routing, pairing and push metadata, and Apple delivers the push notification.

  • Sealed end to end
  • Metadata the relay can see
  • Same machine, SSH or setup step
  • Planned link
  • Shipped
  • Planned, dashed with a badge
  • Trust boundary

Sealed end to end

  • Chat, terminal, files, screen sharing and saved logins
  • Notification text, sealed for your phone

The relay still sees

  • Routing: which device talks to which computer
  • Pairing: random IDs, names and hashed device keys
  • Push metadata, and when connections happen and how large they are

Parts: hover, focus or press one for what it does and what it can see

Read this diagram as text

Layers, top to bottom

  1. Your devices (hold keys).
    • iPhone, shipped, DevOS Mobile. Holds its own keys in the system keychain. Starts, follows, answers and reviews agent sessions on your computers. Can see: Everything in your sessions, decrypted on the phone.
    • iPad, shipped, same app, portrait and landscape. The iPad app does what the iPhone app does. It holds its own keys and pairs with your computers the same way. Can see: Everything in your sessions, decrypted on the iPad.
    • Browser, shipped, web app, paired from a phone. A browser paired from the phone shows the same inbox. It runs nothing itself. Can see: What you open in it.

    Trust boundary below this layer. Payload keys stay on your devices and computers. The relay carries sealed envelopes.

  2. Relay and push (no payload keys).
    • Relay on Cloudflare, shipped, forwards sealed envelopes. Forwards end-to-end encrypted traffic and cannot read it. It does keep each computer’s random ID and name, hashed device keys and who is paired with what, and it sees when connections happen and how large they are. Can see: Routing; Pairing records (hashed device keys); Push metadata; Timing and sizes.
    • Apple push, shipped, APNs. Notification text is sealed for your phone. Apple and the relay see the push token, the time, the kind of alert, a session-grouping identifier and the size of the sealed text. Can see: Push token; Time and kind; Random conversation ID.

    Trust boundary below this layer. The relay hands sealed envelopes to your computer. Only the bridge opens them.

  3. Your computers (hold keys, run the agents).
    • Mac: companion + bridge, shipped, the only part that starts agents. DevOS Companion runs the signed devos bridge. The bridge opens sealed envelopes, checks who is asking, and is the only authority over its own machine. Its API keys sit in the Keychain, readable without a prompt only by the signed bridge. Can see: Your sessions, files and keys on that Mac.
    • Linux over SSH, shipped, added through a Mac. Other computers, such as a Linux server, join through a Mac that adds them over SSH. They keep working while that Mac sleeps. Can see: The sessions you run there.
    • Sandbox desktops, shipped, a Linux desktop per session. A Linux computer of its own for a session’s agent. It runs apart from the Mac and nothing of the Mac is shared with it. Can see: Only what you put in it.
    • Agents, shipped, Claude Code, Codex, Grok, Cursor, Gemini. Run in a project folder on their own logins, with your user’s power on that computer. Listed as options, not partners. End-to-end encryption does not protect a compromised computer. Can see: Whatever your user can reach.
    • DevOS ADE, planned, optional runtime, design only. Planned. An optional local workbench that would be reached only through the companion on the same Mac, never directly from the phone. Nothing is built, and it shares no code with the bridge or relay today. Can see: Nothing yet: not built.

Connections

  • iPhone to Relay on Cloudflare: Sealed end to end (sealed)
  • Browser to Relay on Cloudflare: Sealed end to end (sealed)
  • Relay on Cloudflare to Apple push: Metadata the relay can see (push metadata)
  • Relay on Cloudflare to Mac: companion + bridge: Sealed end to end (sealed)
  • Mac: companion + bridge to Linux over SSH: On the same machine or link (SSH)
  • Mac: companion + bridge to Agents: On the same machine or link
  • Mac: companion + bridge to DevOS ADE: Planned (via companion)

In short

  • Sealed end to end: Chat, terminal, files, screen sharing and saved logins; Notification text, sealed for your phone.
  • The relay still sees: Routing: which device talks to which computer; Pairing: random IDs, names and hashed device keys; Push metadata, and when connections happen and how large they are.

Pairing and roles

The Mac shows an owner setup code and the phone scans it. The two agree end-to-end keys from the first message. The relay stores only hashed device keys and who is paired with which Mac. Roles are set per Mac, per device: owner, member and a time-boxed guest, and a Mac can have several owner devices.

  • Metadata the relay can see
  • Same machine, SSH or setup step
  • Shipped
  • Trust boundary

The relay stores

  • A random computer ID and name
  • A random account ID that groups your Macs
  • Hashed device keys and who is paired with what

The relay does not hold

  • Your email, name or contacts
  • The keys that open your sessions

Parts: hover, focus or press one for what it does and what it can see

Read this diagram as text

Layers, top to bottom

  1. Your Mac and your phone (hold keys).
    • 1. Mac shows a setup code, shipped, DevOS Companion. The owner setup code is shown only on your own Mac. Do not use a code from anywhere else. Can see: The code on screen.
    • 2. Phone scans it, shipped, or opens an invite. Scanning the code pairs the phone. An invite from an owner is another way in. Can see: The code.
    • 3. Keys agreed once, shipped, X25519, in the join. End-to-end encryption is set up from the first message as the computer. After that, frames are sealed with AES-256-GCM. Can see: Only the two devices.

    Trust boundary below this layer. The keys are agreed between your two devices. The relay is only told who is paired.

  2. Relay (no payload keys).
    • Relay keeps a record, shipped, hashed device keys only. The relay keeps a random computer ID and name, a random account ID, hashed device keys and who is paired. No email, no name, no contacts. That record is metadata the relay can see. Can see: Hashed device keys; Who is paired with what.

    Trust boundary below this layer. Owner is granted only at the Mac, by showing its setup code there. A phone cannot grant itself.

  3. Roles on that Mac (set per Mac, per device).
    • Owner, shipped, first approved phone. The first phone a Mac approves is its owner. Owners keep the sensitive actions and can remove a phone, which signs it out and deletes its pairing on the relay. Can see: Everything on that Mac they are allowed to.
    • Co-owners, shipped, more than one owner device. A Mac can have several owner devices. Owner is granted only at the Mac, never by a request from a phone. Can see: Same as an owner.
    • Member, shipped, a paired device, not an owner. A paired device without owner powers. Sensitive actions stay with owners. Can see: What owners let members use.
    • Guest, shipped, time-boxed: watch. A guest sees only what you name, for a limited time, to watch. Guests who can reply are not available yet. Can see: Only what you name, until it expires.

Connections

  • 1. Mac shows a setup code to 2. Phone scans it: On the same machine or link (code)
  • 2. Phone scans it to 3. Keys agreed once: On the same machine or link
  • 3. Keys agreed once to Relay keeps a record: Metadata the relay can see (who is paired)

In short

  • The relay stores: A random computer ID and name; A random account ID that groups your Macs; Hashed device keys and who is paired with what.
  • The relay does not hold: Your email, name or contacts; The keys that open your sessions.

Five tabs in every session

Chat

The conversation. "Expand all details" in the session menu unfolds every tool call. A thread stacked after another starts only when that session ends; Start now starts it at once.

Files

What the agent made for you to open, keep or share: documents, pictures, PDFs, pages, media and archives, with previews and Share. Send from this iPhone puts a file, photo or video in the folder you choose on the computer.

Code

The session’s folder as an editor shows it: go to file by name, a list of what changed, line-numbered views. Text files edit in place and a save is refused when the Mac’s copy changed since you opened it. .env-style files show with a lock and masked values, open only for the owner on the Mac’s Wi-Fi or over the end-to-end link. Keys and logins never show.

Terminal

The agent’s live terminal. Take the keyboard to type into it. Without the Mac’s Wi-Fi or the end-to-end link it shows the agent’s screen as text that refreshes every second, with keys for answering prompts. Only the Mac’s owner can open it.

Desktop

The session’s sandbox desktop: a Linux computer of its own for the agent. If Docker Desktop is the runtime and is not running, the Mac opens it and the tab says it is starting.

Also in the box

Push

Notifications for “needs you” and “done”. The text is encrypted on your computer with a key shared only between your iPhone and that computer. Apple and the relay see the token, the time, the kind (including a join request), a session-grouping identifier and the size of the sealed text.

Dictation

The mic button dictates on the phone when the phone supports the language.

Phone first

The Mac ignores the phone for two seconds after any local mouse or keyboard input, so it does not fight whoever is at the Mac. Turn on Phone first when you are the one at both.

Owner and members

The first phone a Mac approves becomes its owner. The owner can remove a phone, which signs it out and deletes its pairing on the relay.

Works with

Claude Code, Codex, Grok, Cursor, Gemini, Claude on Amazon Bedrock and the Xirp desktop app, as options. ACP, MCP and git are the interfaces it uses.

  • Claude Code
  • Codex
  • Grok
  • Cursor
  • Gemini
  • Claude on Amazon Bedrock
  • MCP
  • Git

Not yet

Android phones and tablets, a team plane and a hosted service are planned. They are not part of what ships today.

The DevOS ecosystem

DevOS is a set of parts. ADE is a development environment on your computer. Companion, Mobile and the relay are for steering the agents on your computers from your phone.

DevOS ADE

Open source, MIT

An agentic development environment you run on your own Mac or Linux computer, opened in a browser. Free and self-hosted.

DevOS Companion

Beta

The Mac app that makes a computer reachable and runs the bridge to its agents.

DevOS Mobile

Beta

The iPhone and iPad app: one inbox to start, follow, answer and review agents.

The relay

Beta

Carries encrypted traffic between your phone and your computers. It sees routing, pairing and push metadata.

DevOS ADE is free and open source (MIT). Companion, Mobile and the relay are free to download during the beta; paid plans are planned and not yet available.

Planned Planned

Names only. Not built, not available, and no dates.

  • Control DevOS ADE from DevOS Mobile, through Companion
  • Team mode: one server for many members, with roles and SSO
  • A native Mac app and a lighter footprint
  • More model gateways
  • Voice: speech-to-text on your own cloud
  • Send feedback from the app
  • Agent teams and orchestration
  • A fuller web client
  • Android
  • Windows and Linux hosts
  • Scheduling