You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tower view: click a builder from another workspace to open its terminal in this window (quick message without launching a window) #1790
The Codev Tower view lists every workspace on the machine with the builders needing attention under it, but a builder row is display-only. The only click target is the workspace row, which runs "open workspace" and switches to or launches that workspace's VS Code window. Sending a quick message to a builder in another workspace therefore costs a whole window. Owner's ask, 2026-10-06: "click on a builder from another workspace and open it directly to interact, instead of launching a new window just to send a quick message."
Why it is feasible
Tower is one process on one port and every terminal is addressable from any window: it exposes a direct per-terminal websocket route and a workspace-scoped one (tower-websocket.ts, routes documented at the top of the file).
The extension's terminal opener already does everything needed for a local builder tab; the one line that binds a tab to the current window is buildWsUrl in apps/vscode/src/terminal-manager.ts, which encodes connectionManager.getWorkspacePath() into the scoped route.
The hub's attention rows (attentionRows in apps/vscode/src/views/tower.ts) already carry the builder id and issue, and each workspace's overview response carries each builder's terminal id. Auth is the same local key.
afx send and the mailbox route through Tower, not the window, so a message typed into such a tab reaches the right builder in the right workspace with no change to delivery.
Requirements
A builder row under a workspace in the Tower view gets a command, "Open builder terminal here", as its click action and in its context menu. The workspace row keeps "open workspace" as today.
Clicking resolves the builder's terminal id from that workspace's overview and opens it as a terminal tab in the current window, using that workspace's scoped websocket route (or the direct route) and the existing local-key auth. Reconnect behaviour matches local builder tabs.
The tab is labelled with the workspace as well as the builder, for example shannon · bugfix-6114, so two same-numbered builders from different repos are never confused. The label is driven by the workspace's registered name.
Clicking a row for a builder already open in a tab here focuses that tab instead of opening a second.
The tab is a plain terminal into that builder. None of the per-workspace sidebar context (Agents view row, diff, files, PR) follows it; that is not in scope and the full-window path stays the way to work in that repo. Say so in the tab's tooltip.
A dormant workspace's builders are not offered this action (there is no live terminal). A builder whose terminal id is missing shows the existing "could not open" toast grammar.
Verified in a browser-driven VS Code run per codev/resources/testing-guide.md: open a builder from a second registered workspace, type a line, and confirm it arrives in that builder's PTY (visible in that workspace's own window or Tower dashboard).
Out of scope
Cross-workspace Agents view, diff or PR context; any Tower-side change; changes to afx send routing.
Activity