Reach teammates' terminals through the gateway #11

Activity

1. iamnbutler

   added a parent issue on Oct 4, 2026

   • [Meta] Dogfood Ace end to end #5
2. iamnbutler

   removed a parent issue on Oct 5, 2026

   • [Meta] Dogfood Ace end to end #5
3. iamnbutler

   added a parent issue on Oct 5, 2026

   • [Meta] Extend work across hosts and devices #58
4. iamnbutler commented on Oct 6, 2026

   

   iamnbutler

   on Oct 6, 2026

   Last edited by iamnbutler

   ContributorAuthor

   More actions

   Read-only scope audit at main 6dc0f1c, linked to dogfooding #5 and distributed-work meta #58. These are code-path findings, not new runtime acceptance.

   Missing path: all four terminal operations are owner-only (gateway.ts); terminal open requires a local catalog record and has no peer/workspace forwarding (handler). The existing code does permit the owner's direct tailnet browser and hosted channels opened on their workspace host. Another gateway reaching that workspace remains unsupported; the hosted cell itself has no shell.

   Design required before implementation:

   • Creating a new shell in a teammate's checkout differs from discovering/attaching to their existing terminal. IDs currently live in client layouts; there is no session-discovery protocol.
   • Direct PTY access runs as the host OS user. Read, input, resize, and close rights are not defined by the existing switch, which controls only new agent invocations (team semantics). Preserve the tailnet trust model; don't silently broaden that flag.
   • Reattach and continuation operations currently trust terminal IDs. Peer exposure needs channel/participant binding and explicit existing-session semantics (terminal manager).
   • Define output/exit forwarding, reconnect/replay, simultaneous input/resize, close versus detach, orphan timeout, and kill/archive/delete behavior.

   Recommendation: no straight-proxy patch. An owner-only route through their other machines is a smaller possible first slice; teammate session access needs the decisions above. Validate the owner route on two machines and teammate rights with two people. #159 addresses transcript watches, while #53 addresses agent jobs; neither implements this terminal feature.
5. iamnbutler commented on Oct 15, 2026

   

   iamnbutler

   on Oct 15, 2026

   ContributorAuthor

   More actions

   Status on main (October 15, fb3ff46)

   This still doesn't work. Verified from the code; no new runtime test.

   What works: the host's owner, in the app connected to that host, opens a terminal in a chat's lane or the project checkout. For a hosted channel, that host is its workspace host.

   What's refused:

   Who opens the terminal	Result	Where
   A teammate, on any channel	Refused. terminal, terminal-input, terminal-resize and terminal-close are in localOps, which refuses every peer client and any user other than the owner.	apps/host/src/gateway.ts (localOps, the check localOps.has(op) && (client.peer || …))
   The owner, from their other Mac	Refused. The request reaches the other host as a peer, and peers "never act as its owner". The app's own host also answers "Terminals open on the channel's host".	gateway.ts case "terminal"
   Anyone, on a cloud compute channel	Refused: "A cloud compute channel's shell is in its container, not on this host". The compute runner has no PTY endpoint (#216, #417).	gateway.ts case "terminal"

   What changed since the October 6 audit

   • Sharing has a defined meaning: the toggle gates teammates invoking agents. The copy now says agents "run commands as you on this machine" (fix(app): mention Ace's macOS permissions in the sharing tooltip #389, fix(app): say desktop tools off still leaves shell with Ace's macOS permissions #380). So with sharing on, a teammate can already run arbitrary shell commands through the agent. A teammate terminal behind that same switch adds no new trust, only a better interface. The audit's "don't silently broaden the flag" still applies; this is now the decision to make, not a reason to keep terminals owner-only.

   • Relays exist: the app relays a channel's requests to its host through peers (fix(host): reach a hosted channel while its owner's host is unreachable #349, fix(host): say when a relayed channel's host isn't responding #387). Owner terminals from another machine could forward over that path once that host accepts an authenticated owner from another machine. Today it treats every peer as not the owner.

   • Cloud compute adds a third place a shell can live: the container. It needs a PTY endpoint in services/compute plus a relay through the host. That's separate from teammate access.

   • Still open from the audit:

     • terminal IDs live in client layouts, with no discovery;
     • reattaching trusts the terminal ID alone;
     • detach versus close, replay, and simultaneous input aren't defined.

     Agent jobs are Manage background and interactive jobs from channel tools #53.

   Suggested slices

   1. Owner terminals from another of their machines: recognise the same owner arriving from a peer (by Tailscale login), and relay terminal* to the channel's host.
   2. Teammate terminals on shared channels: a new terminal, not attaching to someone else's, allowed when sharing is on. Copy states it's a shell as the owner. Terminals are bound to their channel, and kill, archive and delete close them.
   3. Compute channel terminals: a PTY in the container, through the compute service.
6. iamnbutler commented on Oct 15, 2026

   

   iamnbutler

   on Oct 15, 2026

   ContributorAuthor

   More actions

   Cloud compute channels (#216, now closed) also fall under this issue, as #58 lists. Their workspace is a container on the compute service, and the host opens no terminal for a compute record (docs/architecture.md, Cloud compute (beta)). So today even the owner gets no terminal for a cloud channel.