- Ya
- 4 Septemba 2026, 20:41 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 17b34b1
Two endpoints beside the terminal ones, and they follow the same rule those do: the Linux account is resolved from the CALLER'S OWN SESSION and no account name is ever taken from the request. A member can therefore only see or reopen their own sessions — there is no id they could supply that would reach somebody else's, because the account is not part of what they supply. unreachable dev machine comes back 200 with `unreachable: true` and an empty list, as the terminal listing does: "the machine is down" is something the tab can say, where an error leaves it able to say nothing. new session or resumes an existing one. Nothing runs when the POST returns. The machine writes the session down and hands back a receipt; the terminal window the console opens next presents its ordinary ticket, and the receipt is what turns that terminal into this session — the same hand-off Send-to-AI uses, through the same TerminalDispatchRegistry. The window id is named HERE because both halves need it: the console to open the window, the registry to key the receipt, and tmux to survive the reconnects it exists to allow. This endpoint cannot express a command, a model, an effort or a permission mode. Every one of those is the machine's to decide. What crosses the wire is which session, and nothing else — so `bypassPermissions`, which every one of these sessions runs with, is not a parameter here and cannot become one. TerminalSummary grows `coderSessionId`: the session a shell is running, read off the tmux user option the agent sets. It is what lets the console say "already open" instead of resuming a conversation that is live in another there is nowhere else this could come from. Opening one is audited exactly as opening a shell is — same event type, same HIGH severity — because it is one. Verified with `mvn test`; Java CI runs none, so a red repo would still deploy.