DevOS
A per-team coordinator
Each team gets its own coordinator that holds ciphertext, a signed membership roster and a hash-chained audit log. Members’ devices hold the keys. The coordinator is designed so that it cannot read session payloads.
Planned Team plane
A team plane that shows its own rules.
The paid product is planned for small teams. It is a design, not a release. No date, no price commitment and no availability claim is made here.
Status: not built, not available, no ship date. Where this page says “will” or “is designed to”, read it as a plan.
What is planned
Admin-set visibility
An admin may enforce visibility org-wide or leave it to members, per scope: sessions, artifacts, repos, usage. Policy changes are signed and appear in the audit log.
Fenced claims
Claims and leases on shared repos and worktrees, so two people or two agents do not edit the same thing unknowingly. Each claim carries a fencing counter.
Your machines stay the authority
The Mac bridge remains the only part that starts agents and decides who may use its machine. Offline teammates reconcile through an inbox and outbox.
Team plane (planned)
Planned, not built. Each team would get a coordinator that holds only ciphertext, a signed roster, a hash-chained audit log and fenced claims. An admin sets a signed visibility policy. Anyone who can read members’ sessions is a named escrow recipient that every member’s app shows. Nothing runs from the team plane: execution stays on each member’s own computer.
- Same machine, SSH or setup step
- Planned link
- Planned, dashed with a badge
- Trust boundary
The coordinator would hold
- Ciphertext and wrapped keys
- A signed roster and a hash-chained audit log
- Claim counters
The coordinator would still see
- Who is in a team and which devices
- Activity timing and sizes
- Push metadata
Parts: hover, focus or press one for what it does
Read this diagram as text
Layers, top to bottom
- Members’ devices (hold the keys).
- Members’ apps, planned, phone, tablet, web. Planned. Each member’s app shows the effective policy, who holds escrow keys and when it last changed, always, with no way to hide it. A second channel to the coordinator would carry the team feed, alongside the existing sealed channel to each Mac.
- Admin, planned, signs the policy. Planned. A team role, separate from per-Mac owner. Admin changes are signed and appended to the audit log. There is no admin path into execution on a member’s computer.
Trust boundary below this layer. Keys stay on members’ devices. Below this line the coordinator side holds only ciphertext and signed records.
- Visibility policy (signed, shown to every member).
- Signed visibility policy, planned, what the team can read. Planned. Tiers run from presence only, through shared context and shared sessions, to escrow. A loosening applies only to sessions started afterwards, and the app says so.
- Named escrow recipients, planned, listed by name and key fingerprint. Planned. If an admin or auditor can read sessions a member did not share, they appear here by name with a key fingerprint, in every member’s app. The suggested recipient is a break-glass agent that releases keys only against a request on the audit log. That is an accountability control, not a cryptographic one. Whether this holds up is an open design question that needs independent review.
- Team coordinator, one per team (holds ciphertext only).
- Signed roster, planned, who is on the team. Planned. A chain of admin-signed entries: members added or removed, roles, device certificates, policy changes.
- Hash-chained audit log, planned, tamper-evident. Planned. Each entry is signed and carries the hash of the one before. Clients remember the last head they saw and compare it with teammates to catch a rewritten history. The log holds hashes and IDs, not content.
- Fenced claims, planned, who is working where. Planned. A claim on a repo scope carries a counter that only goes up. A computer refuses to push under a stale one. Claims are advisory by default and enforced at the push step. If the coordinator cannot be reached, the bridge says so and falls back to advisory.
- Ciphertext and key wraps, planned, events, per-device keys. Planned. Encrypted events and the team key wrapped for each device. Routing metadata stays readable to the coordinator: who is in a team, activity timing and sizes.
Trust boundary below this layer. The coordinator sequences and stores ciphertext. It never executes anything on a member’s computer.
- Members’ computers (the only place anything runs).
- Mac bridge, planned, publishes, checks fences. Planned. The bridge stays the only part that starts agents and decides who may use its machine. It would publish status, check claim fences and verify signed grants.
- Git forge, planned, source of truth for code. Planned. Code stays in git. The team plane records pointers such as branch and commit hashes, never repository content.
Connections
- Admin to Signed visibility policy: Planned (signs)
- Signed visibility policy to Signed roster: Planned (appended)
- Named escrow recipients to Ciphertext and key wraps: Planned (extra wrap)
- Fenced claims to Mac bridge: Planned (fence check)
- Mac bridge to Git forge: On the same machine or link (push)
In short
- The coordinator would hold: Ciphertext and wrapped keys; A signed roster and a hash-chained audit log; Claim counters.
- The coordinator would still see: Who is in a team and which devices; Activity timing and sizes; Push metadata.
What members would see
Sketches from the roadmap, not screens in the app. Field values are placeholders, not data.
Planned These screens are not in the app today. They show what the roadmap says they would carry.
Planned, not in the app
Visibility policy notice
Where an admin enforces visibility, members would always see the effective policy, who holds escrow keys, and when it changed.
Planned, not in the app
Team claims
A session claimed by one member at a time, with the claim visible to the team.
No silent escrow, ever
An admin may enforce who can see what. A member may not be left in the dark about it. Wherever an admin enforces a visibility policy, every member’s app is designed to show, always and in a way that cannot be hidden:
- the effective policy,
- who holds escrow keys,
- and when it last changed.
Enforced policy means members cannot opt out. It does not mean members cannot know. How admin visibility can work on ciphertext, through client-side policy, key escrow or per-field disclosure, is an open design question that needs independent review before any claim is made.
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
- 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.
- 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.
- 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 this page does not say
- It does not say the team plane exists, is in beta or has a date.
- It does not claim a security property of the team plane. Its threat model is not written yet, and independent review comes first.
- It does not list customers, logos or numbers. There are none to list.
Self-host is planned to be the default, with an optional hosted service. Neither is available now. For the likely shape of pricing, see the pricing hypothesis.