Repository navigation
Description
Where did this happen?
Desktop app (macOS)
Version
1.17.0
What happened?
The running-agents chip on a workspace row (agent avatar + count) is two things at once:
- a
HoverCardTrigger— hovering it for 150ms opens the card that lists each running agent, which is how you check what a workspace is doing; and - a
<button>whose entireonClickishandleStopAll()— kills every agent in that workspace, immediately, with no confirmation and no undo.
So "let me see what's running here" and "kill everything running here" are the same 18px target, separated only by whether your finger comes down.
The only visible difference between the safe state and the destructive one is a cross-fade of the count into a 10px ×, which appears only while hovering:
// DashboardSidebarAgentsChip.tsx:99-107
<span className="grid shrink-0 items-center …">
<span className="transition-opacity group-hover/chip:opacity-0">{agents.length}</span>
<LuX className="size-2.5 opacity-0 transition-opacity group-hover/chip:opacity-100" … />
</span>At text-[9px] in an h-[18px] chip, that is not a legible destructive affordance. The aria-label is honest — "${agents.length} running agents — stop all" — but nothing on screen is.
The hover card has the same problem at the other end: Stop all agents is the row immediately below the last agent, separated by a Separator className="my-1" (4px). Overshooting the agent list by one row kills everything.
What "stop" actually costs
useDashboardSidebarAgentKill.killAgents() calls terminal.killSession per agent. Server side (packages/host-service/src/trpc/router/terminal/terminal.ts:243-283) that is disposeSessionAndWait(...) + markTerminalExited(...) — the terminal session is disposed, not backgrounded. The agent process is gone, its scrollback is gone, and there is no "resume that session" anywhere in the app. Whatever a Claude Code session was 40 minutes into is not coming back.
The success path is a toast.success("Stopped 3 agents"). No confirm before, no undo after.
This one plus #5989 are why I've moved my daily terminal off Superset for the moment — two adjacent hover targets on the same sidebar row, both irreversible, both firing on a single unconfirmed click. Writing them up rather than just leaving, because the rest of the app is genuinely good.
Steps to reproduce
- Have a workspace with 2+ agents running.
- Move the pointer toward the agents chip on that workspace's sidebar row — the natural thing to do, since hovering it is how you see what is running.
- Click.
- Every agent in the workspace is killed. One toast. No way back.
Variant: hover the chip, let the card open, move down the agent list past the last row, click. Same outcome.
Logs, screenshots, or recordings
The chip is the ✳ × at the left, mid-cross-fade — that × is the entire warning that clicking it kills all three sessions. Workspace names are redacted.
Suggested fixes
- Make the chip non-destructive. Click should open the card (or focus the agent); stopping should live only inside the card, per-agent plus an explicit all. A hover-to-inspect target and a kill-everything target should not be the same element. This is the important one.
- If click-to-stop stays, confirm it — at minimum when
agents.length > 1. An undo toast is the nicer pattern and is already used in this codebase, but a disposed PTY can't be undone, so a confirm is the honest control here. - Separate
Stop all agentsin the card from the agent list by more than 4px, style it as destructive (red), and confirm it. - Make the
×state legible if it stays: it currently renders atsize-2.5inside a 9px chip, hover-only, in muted foreground.
Related: the − "Remove from sidebar" button on the same row is separately destructive — filed as #5989.
Happy to send a PR for (1) + (3) if that's useful.

Activity
fix(desktop): make the running-agents chip inspect-only and confirm s…
2solarmax commentedon Jul 27, 2026
Additional evidence: the app already has the exact guard this chip skips.
Closing a single terminal pane, or closing a tab, goes through
confirmCloseTerminals(...), which:terminal.hasRunningProcessfor each terminal about to close (probeTerminalRunning),hasTerminalBackgroundIntent(...)(deliberately backgrounded ones),alert(...)with a Cancel and a "Don't ask again" checkbox, persisted asterminal-close-confirm-v1.The comment on the helper says it is "used by both single-pane close and tab close so the guard can't be bypassed by the tab-close gesture."
So closing one pane running an agent asks for confirmation. Clicking the agents chip kills all of them —
killAgents→terminal.killSessionper id — and never touchesconfirmCloseTerminalsorhasRunningProcessat all. The larger-blast-radius gesture is the unguarded one, and it's also the smaller click target.That seems more likely to be an oversight than a decision, and it makes the fix cheap: route
handleStopAll(and theStop all agentsrow) through the sameconfirmCloseTerminalspath that pane and tab close already use. The dialog, the running-process probe, and the "Don't ask again" escape hatch all exist already.Verified against the shipped 1.17.0
app.asar.Cal-Morris commentedon Jul 28, 2026
Agreed on this, the previous behaviour was cleaner in my opinion. At present, when I click on the codex icon to select the row, I am now clicking the
xbuttton which is killing all running processes.