Oko PTY Relay

Persistent WebSocket relay for internet terminal sharing.

The relay is intentionally dumb: it authenticates each WebSocket, groups connections by session, and forwards bytes/messages between:

role=publisher: the Oko that owns the broker PTY
role=viewer: a remote Ghostty attach client
role=control: one-shot control messages such as resize or input from UI

It never starts, owns, or inspects Claude/Codex processes.

Run

The relay starts only on a host with the exact oko-pty-relay / token grant for consumer oko-pty-relay-service at ~/.stado/oko-pty-relay-service-skarbiec-token. It resolves the value through the local Stado CLI and retains it only in memory:

bash

deno run --allow-net --allow-env --allow-run relay/pty-relay.ts

Production deployment must use TLS. Trusted Oko clients independently resolve the same relay item through the exact oko-pty-relay-client grant.

Stado-managed service

The production relay is a long-lived service on a registered Stado host. Oko does not call a provider deployment API and does not select the backing cloud.

Before deployment, stage a target-local executable wrapper that starts relay/pty-relay.ts with Deno. The --from path is on the registered target; stado service deploy does not upload a local workstation path.

bash

stado service deploy oko-pty-relay \
  --host <registered-host> \
  --from /absolute/target/path/oko-pty-relay
stado service status oko-pty-relay

The managed unit resolves its relay credential through its exact local Skarbiec grant; neither launchd nor the service environment contains the bearer. Give clients only the Stado-managed TLS endpoint as non-secret configuration:

bash

export STADO_PTY_RELAY_URL=wss://<stado-managed-relay-endpoint>

Keep one managed relay instance for this service: session pairing is in process memory, so every publisher, viewer, and control socket for a session must reach that same instance.

Supabase remains useful for session discovery/presence. Terminal bytes do not flow through Supabase tables or Storage.