@volter-ai-dev/supercode-teams

Teams has a server and machines. A machine daemon, one per OS user, serves this machine's doors: panes, launch, files, ports, attention, titles, a signed describe, and harness.v1. A Teams server retains a shared session catalog, membership and access rules, and routes callers to enrolled machines. It runs as a Node process (server/index.mjs) or as a Cloudflare Worker with one Durable Object (worker/); both host the same server/core.mjs. Existing OpenTelemetry pipelines can publish evidence without installing Supercode on each developer's machine. Start with the Teams guide; the design is Teams server, CLI and API.

The server uses SQLite and requires Node 22.13 or newer. Package exports: . (the daemon, channel and client), /machine, /client, /admission, /fleet, /server, /workspace-client, /connector, /connector/native-continuation and /contracts. The workspace client is browser-safe and takes explicit credentials. Native capture and execution use the matching harness SDK and native core; source capabilities and fidelity remain explicit. Fresh-session materialization supports Claude Code and Codex with requested value_lossless; telemetry alone does not establish resumable native history.

See the public client declarations, contracts, and implementation specification.

The machine daemon

supercode teams machine start runs it with its local door only; supercode teams connect runs the same daemon enrolled to the selected Teams context, adding catalog sync and the server link. The daemon owns one supercode harness serve and the tmux terminal host.

Two doors reach it:

• Local: an owner-only Unix socket, $SUPERCODE_HOME/teams/machine.sock (or, when that path is too long for a socket address, a per-user 0700 directory under /tmp). Whoever can open it is this OS user, an operator. The local CLI, the agent inside the machine and a service on the same box (RH2's connector) use it.
• Remote: the Teams server. The daemon holds one outbound WebSocket link; the server forwards a caller's channel over it after checking the caller's machine grants, and the daemon re-derives that admission from its own synced copy of the grants before every door.

The machine's custodian holds it as operator. Anyone else holds a machine grant: operate (the whole machine: harness.v1 and launch), or view, observe, interact, control, files, ports on named targets (pane:<key>, runtime:<id>, root:/path, port:<pane>/<n>, browser:<pane>).

supercode teams machine start                        # local door only
supercode teams launch --program bash --kind shell   # a pane; prints its contextKey
supercode teams attach <ctx> --mode control          # ctrl-] detaches
supercode teams input <ctx> "make test"
supercode teams title set <ctx> "rate-limit rescue"  # also names the owned tmux window
supercode teams suspend <ctx>                        # remote input refused; observe keeps streaming
supercode teams resume <ctx> --input "carry on"      # the input that hands the pane back
supercode teams log verify                           # the hash chain across every rotation

supercode teams machines access grant laptop --to user:usr_… --caps observe,control --on pane:<ctx> --ttl 1h
supercode teams attach <ctx> --machine laptop        # through the selected context's server
supercode discover --fleet                           # every reachable machine of the context
supercode harness start --on laptop --program claude --kind claude   # a pane on an enrolled machine

Files (under $SUPERCODE_HOME/teams)

machine.key|pub (the host key; it signs describe and nothing else) · machine.sock · machine.json · launches.jsonl · log.jsonl (hash-chained, rotating to log.<ts>.jsonl) · attention.json · titles.json · suspended.json · limits.json · workspaces/ (Teams contexts, credentials and connector enrollments).

limits.json is read when the daemon starts: maxAttachmentsPerPrincipal (16), protocolFloor (2), logRotateBytes (16 MiB), logKeep (8).