naps62/maestro
Archived
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Web and TUI disagree on whether killing a session confirms #160

New Issue
Closed
opened 2026-09-03 17:29:05 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-09-03 17:29:05 +01:00
Collaborator
Copy Link
Copy Source

The command bar gives both clients a kill path from the same place, and they
disagree about confirmation:

  • Web: DELETE /api/sessions/:id goes straight through. The force dialog
    exists only for a kill_guarded refusal — web/src/killDialog.ts says so
    outright: "A kill the daemon accepts never reaches here."
  • TUI: x raises OverlayKind::KillConfirm first, every time.

Neither is new — the sidebars have always differed this way — but the bar makes
it reachable by the same three keystrokes in both clients, which is where the
difference starts to read as a bug rather than as two independent designs.

Pick one and make both follow it. The argument for the TUI's behaviour is that
a kill is destructive and unattended agents live in these sessions; the
argument for the web's is that the daemon already refuses the dangerous cases,
so a confirmation on the safe ones is friction that trains people to dismiss
dialogs.

docs/COMMAND-BAR.md defers to "the flow it already has" for each client, so
whichever way this goes, that line and docs/SIDEBAR.md need to say which flow
that now is.

The command bar gives both clients a kill path from the same place, and they disagree about confirmation: - **Web**: `DELETE /api/sessions/:id` goes straight through. The force dialog exists only for a `kill_guarded` refusal — `web/src/killDialog.ts` says so outright: "A kill the daemon accepts never reaches here." - **TUI**: `x` raises `OverlayKind::KillConfirm` first, every time. Neither is new — the sidebars have always differed this way — but the bar makes it reachable by the same three keystrokes in both clients, which is where the difference starts to read as a bug rather than as two independent designs. Pick one and make both follow it. The argument for the TUI's behaviour is that a kill is destructive and unattended agents live in these sessions; the argument for the web's is that the daemon already refuses the dangerous cases, so a confirmation on the safe ones is friction that trains people to dismiss dialogs. `docs/COMMAND-BAR.md` defers to "the flow it already has" for each client, so whichever way this goes, that line and `docs/SIDEBAR.md` need to say which flow that now is.
naps62-yolo added this to the Command bar milestone 2026-09-03 17:29:05 +01:00
naps62-yolo added the difficulty/mediumtype/feat labels 2026-09-03 17:29:05 +01:00
naps62-yolo commented 2026-09-03 22:11:03 +01:00
Author
Collaborator
Copy Link
Copy Source

Resolved in favour of the TUI: every kill confirms first, in both clients.

511fed4 gives the web a confirmation dialog that shares the force prompt's
shell. It names the blockers the card already knows about — the daemon will
refuse an unforced kill over such a worktree, so saying so before the attempt
is cheaper than a refusal — and keeps the focus on Cancel, so nothing dies on a
stray Enter. The guarded refusal still opens its own prompt behind it.

All three web kill paths funnel through requestKill in catalog.ts, so the
✕ button, the x key and the command bar's action page get the same dialog.

docs/SIDEBAR.md gains a "Killing a session" section stating the rule;
docs/COMMAND-BAR.md's drill-in list now points at it.

Verified against a live daemon: the dialog opens from both the ✕ button and
the bar's action page, Cancel leaves the session running, and confirming
removes it.

Resolved in favour of the TUI: every kill confirms first, in both clients. `511fed4` gives the web a confirmation dialog that shares the force prompt's shell. It names the blockers the card already knows about — the daemon will refuse an unforced kill over such a worktree, so saying so before the attempt is cheaper than a refusal — and keeps the focus on Cancel, so nothing dies on a stray Enter. The guarded refusal still opens its own prompt behind it. All three web kill paths funnel through `requestKill` in `catalog.ts`, so the `✕` button, the `x` key and the command bar's action page get the same dialog. `docs/SIDEBAR.md` gains a "Killing a session" section stating the rule; `docs/COMMAND-BAR.md`'s drill-in list now points at it. Verified against a live daemon: the dialog opens from both the `✕` button and the bar's action page, Cancel leaves the session running, and confirming removes it.
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/android
area/cli
area/config
area/daemon
area/protocol
area/tui
area/web
code-review
difficulty/easy
difficulty/hard
difficulty/medium
epic
Tracks a multi-issue epic / parent work item
 tui
type/docs
type/feat
type/fix
type/refactor
type/test
No labels difficulty/medium type/feat
Milestone
No items
No Milestone Command bar
Projects
Clear projects
No projects
Assignees
Clear assignees
hermes (Hermes (agent)) naps62-yolo (naps62-yolo (agent)) resende (Resende) naps62 (Miguel Palhas)
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: naps62/maestro#160