Every card says if it is shipped, planned or only proposed.
DevOS

Capabilities

What DevOS does, what it will, and what it only might.

DevOS runs coding agents on your own machines and lets you steer them from your phone. This page lists 39 things in the code today, 22 on the roadmap and 3 ideas, each marked.

How to read the badges. Shipped means the capability is in the code and has tests, and does not mean everyone can install it today: the iPhone and iPad app goes through TestFlight, the Mac companion is a signed download. The Download page says what is current. Planned is on the roadmap with no date. Proposed is an idea, not designed.

Shipped Featured

Invite a person by link, from anywhere.

Send a one-time link by any channel. The invited device joins through the relay, so it needs neither your Wi-Fi nor a scan at your Mac. You approve a link by matching a four-digit code.

Still a human step: you make the invite and approve a link; your own first pairing starts with a setup code on the Mac. What the relay could still do.

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.

Shipped is in the code and tests today. Planned is on the roadmap. Proposed is only an idea.

Control20Steer agents on your own machines, whichever agent it is.
  • Shipped

    Steer a running agent from your phone

    Send a message, interrupt a turn, stop a session, or hold the queue so nothing new is sent after the current turn, without going back to your desk.

  • Shipped

    Approve or decline from the phone

    When an agent asks permission to run something, you answer on your phone and it carries on.

  • Shipped

    Queue what an agent does next

    Line up follow-up messages, hold them, and let the Mac type them in one turn at a time.

  • Shipped

    Fork a thread, or start a child from it

    Branch a conversation into a new session instead of losing the context you built.

    Limits

    Fork and child work for Xirp desktop sessions only; direct Claude, Codex, Gemini, Grok and Cursor threads answer that they do not support them. A direct thread can instead continue in a new thread on another account or vendor with a hand-off of the transcript and git status, by hand or automatically when a usage limit is hit. Several agents working one goal under approval is planned, not shipped.

  • Shipped

    One inbox, shared by your phones

    Pin, snooze and settle threads once; every paired phone shows the same state.

  • Shipped

    Find a session by name or by what was said

    Search thread names and chat text instead of scrolling.

  • Shipped

    Not tied to one agent

    Work with Claude, Codex, Gemini, Grok and Cursor agents through the Agent Client Protocol, beside the Xirp desktop runtime.

    • Claude
    • Codex
    • Gemini
    • Grok
    • Cursor
    Limits

    Each agent still has to be installed and signed in on your machine. DevOS does not provide the agents or their accounts.

  • Shipped

    Agents get a browser and a desktop over MCP

    Claude Code and Codex can drive a disposable browser or full desktop through a standard MCP tool, once Desktop mode is switched on.

  • Shipped

    Each computer says what it can do

    The app asks a computer what it offers, and why something is unavailable, instead of guessing.

  • Shipped

    Several logins, with a usage ledger

    See what each login has used and where its plan meter stands, and set a fallback order.

    Limits

    A record and a meter for you to read. Hard spend caps are planned, not shipped.

  • Shipped

    Carry on after a usage limit resets

    On by default, and you can switch it off: the bridge types "continue" into a desktop-app session a minute after its usage limit resets. Direct threads switch to a fallback account instead.

  • Shipped

    Add other computers over SSH

    Put a Linux or Mac server on the same phone, keep it working while your Mac sleeps.

    • Linux
    • macOS
    Limits

    Setup copies the bridge to that machine and runs it as a service there. It uses your SSH access; DevOS stores no password.

  • Shipped

    Disposable sandbox desktops

    Give an agent its own throwaway Linux desktop with a browser, away from your files.

    • Linux
    Limits

    Runs in a container on your Mac. No port is published on your network.

  • Shipped

    See and drive a desktop

    Watch your Mac, a sandbox, or a VNC or RDP computer on the phone, and take control when you choose.

    Limits

    One device holds control at a time; everyone else watches.

  • Shipped

    A real terminal on the agent’s pane

    See exactly what the desktop agent shows, and type into it.

  • Shipped

    Keep the Mac awake while agents work

    The companion’s “Stay on when closed” switch keeps the Mac awake, even with the lid shut, while the companion is open, and lets go on low battery.

    Limits

    It only works while the companion is open.

  • Planned

    Multi-agent hand-offs

    One goal, several agents or providers, with work passed between them under your approval.

    Limits

    Moving one thread to another account or vendor, by hand or on a usage limit, already ships (see Fork a thread). Several agents working one goal under your approval is the planned part; none of it ships.

  • Planned

    Control DevOS ADE from DevOS Mobile, through Companion

    Steer a DevOS ADE on your computer from the phone app, with a pairing token that DevOS ADE issues.

    Limits

    DevOS ADE owns the API and interface contract; a draft is in review. None of it ships: today DevOS ADE is used in a browser on its own computer.

  • Planned

    More model gateways

    More ways for DevOS ADE to reach models than AWS Bedrock and OpenRouter.

  • Planned

    Scheduling

    Start agent work at a set time or on a repeat.

Security10What is encrypted, who may do what, and what the relay can see.
  • Shipped

    End-to-end encrypted sessions

    Session traffic between your phone or browser and your Mac is sealed before it reaches the relay.

    Limits

    The relay still sees routing, pairing and push metadata. No independent audit exists yet.

  • Shipped

    Pair a phone with a setup code or an invite

    The owner’s first phone joins with a code shown on the Mac. Other devices join by invite: a QR code admits at once and tells the owner afterwards; a link is approved on the owner’s phone or the companion.

  • Shipped

    Remove a lost phone

    Sign a phone out from your Mac and drop its pairing.

  • Shipped

    Owner, member and guest roles

    Sensitive actions stay with owners. A guest sees only what you name.

  • Planned

    Guests who can start sessions, and an agent that asks first

    Today guests can only watch. When guests can reply, sessions they start are designed to run in the mode that asks, so risky steps stop for you.

    Limits

    Even in that mode, supported agents can read project files without asking.

  • Shipped

    Sealed push notifications

    A "needs you" alert reaches a locked phone without its text passing through the relay in the clear.

    Limits

    The relay and Apple see the device token and sealed bytes. Locked-device delivery was still listed as an open check in the last release ledger read.

  • Shipped

    Secrets are fenced off

    Env files and sensitive folders such as .ssh and .aws are guarded from the file browser.

    Limits

    Agents run with your user’s power. DevOS does not sandbox your own machine for you.

  • Shipped

    The plain API stays on your Wi-Fi

    Anything arriving through a tunnel or VPN reaches only the encrypted channel, not the open API.

  • Planned

    A safer web client origin

    Separate or sign the browser client so a compromised relay operator cannot alter client-side encryption.

    Limits

    Roadmap phase 3. Until then, treat the browser client as less protected than the apps.

  • Planned

    Independent security review

    Someone outside the project checks the claims on the Security page against the code.

    Limits

    Not scheduled. Until it happens, no “secure” claim beyond the listed properties.

Team10People sharing a Mac today, and the team plane that is still a design.
  • Shipped

    Invite a person by link, from anywhere

    Send a one-time link by any channel. The invited device joins through the relay, so it needs neither your Wi-Fi nor a scan at your Mac. You approve a link by matching a four-digit code; a QR is for in person.

    Limits

    A person is still in the loop: you make the invite and approve a link. Your own first pairing starts with a setup code shown on the Mac. A link read by an email or chat service before the invited person could be used by it, and a QR admits the first person to use it, so every QR join is reported to your phones. This is access to one person’s Mac, not the shared team plane.

  • Shipped

    Guests who watch until an end date

    Let a teammate follow one session or project and cut it off automatically.

  • Planned

    A team plane that cannot read your work

    A per-team coordinator holding ciphertext, a signed roster and a hash-chained audit log, with your Mac still the only thing that runs code.

    Limits

    Design in ROADMAP phase 4.

  • Planned

    Admin visibility policy, with visible escrow

    An admin may require visibility. Every member’s app always shows the effective policy, who holds escrow keys and when it changed.

    Limits

    No silent escrow is a design rule. How admin visibility works over ciphertext is still an open design question.

  • Planned

    Fenced claims on shared repos

    Claim a worktree or repo so two people, or two agents, do not edit the same thing.

  • Planned

    Shared context, artifacts, subscriptions, repos and commits in one pane

    See what the team’s agents are doing and have produced in a single place, instead of asking around.

  • Planned

    Offline teammates catch up

    Messages and decisions queue for someone whose Mac is asleep and reconcile when it is back.

  • Planned

    Spend caps

    An admin sets a ceiling per person or team and the app shows how close you are.

  • Planned

    DevOS ADE team mode

    One DevOS ADE server for many members, with roles and single sign-on.

  • Proposed

    Hand a preview to a teammate with an expiry

    A preview link that works only for people you pick, and stops on its own.

    Limits

    Depends on service discovery and on the team plane.

Dev workflow12Review, commit, push, merge and test, from the phone.
  • Shipped

    Review what the agent changed

    Read the diff per turn, uncommitted, on the branch or against base, then mark files viewed.

  • Shipped

    Commit and push behind a confirm

    A preview first, then a single-use confirmation, so a single stray tap does not push. Xirp desktop sessions only.

  • Shipped

    Merge a pull request, after you confirm

    See checks and mergeability, then merge from the phone; a merged thread settles itself.

    Limits

    Xirp desktop sessions only. Needs the GitHub CLI signed in on the Mac.

  • Shipped

    Browse, pin, upload and edit files

    Open a project’s files, pin the ones you care about, send a file to the Mac, make a small edit.

  • Shipped

    Send to a session from any app

    Use the iOS share sheet to drop text, a link or a file into a thread.

  • Shipped

    Dictate a message

    Speak a prompt, edit it, then send. The app says whether recognition ran on the phone or at Apple.

  • Shipped Partial

    Open a preview link the session reports

    If the session lists a web address, the phone shows it as an “Open preview” row.

    Limits

    This is a link list only, and only for Xirp desktop sessions. DevOS does not find your dev server, forward its port or proxy it. It keeps http and https addresses that are not on localhost, so a LAN address can appear.

  • Planned

    Voice: speech-to-text on your own cloud

    Dictate to DevOS ADE with speech-to-text that runs on a cloud you own.

    Limits

    Dictation in the phone app, which uses the phone’s own speech recognition, already ships. This is a separate, planned feature of DevOS ADE.

  • Planned

    Send feedback from the app

    Report a problem or an idea from inside DevOS ADE.

  • Planned

    Safer writes: idempotency and a diff-to-scope gate

    A retried request cannot act twice, and a change outside the agreed scope is stopped before review or merge.

  • Proposed

    Find the web apps you are developing, and open them from your phone

    DevOS would notice the dev servers running on your host and offer each as a preview. The phone, or a teammate, opens it through the same encrypted channel to test.

    Limits

    Owner idea. Nothing of this is built. See “What exists, and what does not” below for the precise starting point.

  • Proposed

    Screenshots of a preview attached to the review

    See how the change looks, next to the diff.

Platforms12Where DevOS runs, and where it does not yet.
  • Shipped

    One app for iPhone and iPad

    The same app and the same features on both, laid out for each.

    • iOS
    • iPadOS
    Limits

    Distributed through TestFlight. See the Download page for what is available now.

  • Shipped

    A Mac companion with the bridge inside

    One app on your Mac runs the bridge, shows setup and devices, and keeps you in charge.

    • macOS
  • Shipped

    DevOS ADE: an open source development environment

    A stack you run on your own Mac or Linux computer and open in a browser: Chat, Claude Code in the browser, a sandboxed terminal, files and an admin gateway, on your own AI subscriptions or AWS Bedrock. Free, MIT licence.

    • macOS
    • Linux
    Limits

    Needs Docker with Docker Compose 2.24.4 or later. Windows is not supported yet. It is a separate project from the phone app and the Mac companion; controlling it from the phone app is planned, not shipped. The Download page shows the current release when the release feed is available.

  • Shipped

    A standalone bridge for headless machines

    Run the bridge as a background service on a machine with no companion app.

    • macOS
  • Shipped

    A browser client

    Reach your sessions from a desktop browser over the same encrypted channel.

  • Shipped

    Live Activity on the lock screen

    See an agent’s progress without opening the app.

  • Shipped

    Nine themes, light and dark

    Pick a look per mode on phone, Mac and browser.

  • Planned

    A native Mac app and a lighter footprint

    DevOS ADE as a Mac app, with a choice of Docker runtime and fewer resources used.

  • Planned

    A fuller web client

    A browser client with more of the phone app’s features.

    Limits

    A browser client for the inbox and sessions already ships (see A browser client). The planned part is everything beyond it.

  • Planned

    Windows and Linux hosts

    Run the DevOS bridge on Windows and Linux computers directly. Linux computers can be reached over SSH from a Mac today.

    • Windows
    • Linux
  • Planned

    Android phone and tablet

    The same control from an Android device.

    • Android
    Limits

    Roadmap phase 6. Not started.

  • Planned

    A self-host kit for your own Cloudflare stack

    One guide or command to run your own relay, which is the default path.

    • Cloudflare

Proposed Owner idea

Open the web app you are building, from your phone

The idea: DevOS finds the dev servers running on your host and lets your phone, or a teammate, open them through the encrypted channel to test. None of that is built. Here is exactly what exists and what does not.

Checked read-only against the source at the pinned commit. The honest picture is that a small starting point exists and the rest does not.

Exists today

Links and sandboxes, not passthrough

  • A list of web addresses the agent’s own session reports. The bridge keeps only public http and https addresses (up to 20) and the iPhone and iPad app shows each as an “Open preview” row.
  • Anything on localhost, 127.0.0.1 or ::1 is deliberately dropped, because it would not open on a phone.
  • Disposable sandbox desktops with a browser the agent can drive. They publish no port on your network, and the browser reaches pages inside the sandbox only.
  • An optional Cloudflare quick tunnel for the bridge itself, not for your apps. Arrivals through a tunnel reach only the encrypted channel.
Does not exist

Discovery and passthrough

  • Finding dev servers. The host scan that exists looks for the Xirp desktop’s own port, not for your apps.
  • Port forwarding, a reverse proxy or any passthrough of a local web app to the phone or to a teammate.
  • Any preview that works for a page served only on localhost.
  • Sharing a preview with another person. That also needs the team plane.

Service discovery and web-app passthrough (proposed)

Proposed, not built and not designed; drawn in the planned style. Today the bridge only returns public http(s) links that a session reports and the iOS app shows them as Open preview; there is no discovery, port forward or proxy. The idea: the bridge would notice web servers listening on the host and offer them, one by one and only with your say-so, through the same end-to-end channel sessions use. You could then open a dev server on a real phone, or share it with a named teammate for testing. The relay would carry sealed traffic and see the same routing and timing metadata.

  • Same machine, SSH or setup step
  • Planned link
  • Planned, dashed with a badge
  • Trust boundary

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 host computer (runs the dev server).
    • Dev server, planned, localhost:port on the host. Planned. The bridge would notice development servers listening on the host. Today only the sandbox desktop’s browser and screen sharing exist.
    • Bridge, planned, discovers, asks, forwards. Planned. Discovery would list what is listening; forwarding would be switched on per service by the owner, for the owner or for a named teammate.

    Trust boundary below this layer. Web traffic leaves the host sealed. No public tunnel and no open port.

  2. Relay (carries sealed traffic).
    • Relay forwards sealed traffic, planned, sees routing and timing. Planned. Web traffic would ride the existing end-to-end encrypted channel, not a public tunnel. The relay would still see routing, pairing and push metadata, and timing and sizes of what it forwards. Can see: Routing; Timing and sizes.

    Trust boundary below this layer. Opened only on a device you paired, or a teammate you named.

  3. Where you test (opt-in per service).
    • Your phone, planned, opens the preview. Planned. Preview the web app you are building on a real phone, through the sealed channel.
    • A teammate, planned, named, with your permission. Planned. Share a running build with a named teammate for testing. They would need your permission for each service.

Connections

  • Dev server to Bridge: On the same machine or link (loopback)
  • Bridge to Relay forwards sealed traffic: Planned (sealed)
  • Relay forwards sealed traffic to Your phone: Planned (sealed)
  • Relay forwards sealed traffic to A teammate: Planned (sealed)

What is coming

Grouped, not dated. Order inside a group is not a ranking, and anything here can change or never ship.

Next

Closest on the roadmap. No dates.

  • Planned / Security A safer web client origin
  • Planned / Dev workflow Safer writes: idempotency and a diff-to-scope gate
  • Planned / Team A team plane that cannot read your work
  • Planned / Team Admin visibility policy, with visible escrow
  • Planned / Team Fenced claims on shared repos
  • Planned / Platforms A self-host kit for your own Cloudflare stack

Later

Planned or proposed, further out. No dates.

  • Planned / Control Control DevOS ADE from DevOS Mobile, through Companion
  • Planned / Team DevOS ADE team mode
  • Planned / Platforms A native Mac app and a lighter footprint
  • Planned / Control More model gateways
  • Planned / Dev workflow Voice: speech-to-text on your own cloud
  • Planned / Dev workflow Send feedback from the app
  • Planned / Team Shared context, artifacts, subscriptions, repos and commits in one pane
  • Planned / Team Offline teammates catch up
  • Planned / Control Multi-agent hand-offs
  • Planned / Team Spend caps
  • Planned / Control Scheduling
  • Planned / Platforms A fuller web client
  • Planned / Platforms Windows and Linux hosts
  • Planned / Platforms Android phone and tablet
  • Planned / Security Independent security review
  • Proposed / Dev workflow Find the web apps you are developing, and open them from your phone
  • Proposed / Team Hand a preview to a teammate with an expiry
  • Proposed / Dev workflow Screenshots of a preview attached to the review

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.

About DevOS ADE

DevOS Companion

Beta

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

Download

DevOS Mobile

Beta

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

See the app

The relay

Beta

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

What it can see

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

Two things to keep in mind

  • The relay sees routing, pairing and push metadata. Session content between your devices is end-to-end encrypted, and no independent audit exists yet. See Security.
  • Shipped features came from reading the source and its tests, not from a fresh run of every flow on every device. Findings from device testing live in the release notes.