pastilhasandClaude Opus 5
530e5880e1
Closed: - fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a server list it has to read rather than one baked into it. All three verified facts in the item earned their place; two things it did not anticipate are now new items. - fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out. The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by accident, because every document about deploying contains it, so the trigger needs rules about where in a subject line it sits and a rule like that is one somebody eventually gets wrong. Opened, all from tonight and all with the evidence attached: - a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself - the commander cannot finish its own host, so one machine is always a build behind - the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time - plugins:update restarts every sidecar, so a report naming only officer understates what moved - an agent spawned by a background job is invisible in the UI while being perfectly readable - AskUserQuestion can fail to parse its own call - a commander opened from /chat loses its commander controls, because isCommander comes from the screen rather than the session Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
31 lines
1.7 KiB
Markdown
31 lines
1.7 KiB
Markdown
---
|
|
id: known-bugs/a-commander-opened-from-chat-loses-its-context
|
|
title: 'A commander opened from /chat loses its commander controls'
|
|
theme: known-bugs
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 4
|
|
---
|
|
|
|
**A commander opened from `/chat` reports the ordinary chat context, so the composer hides every control
|
|
that only exists for a commander.** The visible symptom is the background-job dialog offering "Stop when
|
|
it fires" and "Keep going" but not **"Exit and hand back to the agent, then re-arm"** — the one a watcher
|
|
actually wants, and the dialog's own default inside a commander.
|
|
|
|
Introduced 2026-08-21 by a deliberate UX change: a commander in the Live list opens in `/chat` rather than
|
|
navigating away to Command HQ, because being thrown out of the page you are reading costs more than the
|
|
metadata you did not ask for. That change is right and should stay.
|
|
|
|
The defect is that `isCommander` is derived from **the screen** rather than from **the session**:
|
|
`isCommander={manager.context === 'command-hq'}`, and `/chat` passes no such context. A commander is a
|
|
commander wherever it is rendered.
|
|
|
|
The fix is to carry it on the session. `ClaudeSessionSummary` and `/chat/live` both already have
|
|
`isCommander`, derived server-side from the cwd; `GET /chat/sessions/:id` does not, and that is the one the
|
|
chat detail reads. Adding it there and letting the composer take it from the session rather than the route
|
|
closes this and makes the same thing work in any future surface that renders a chat.
|
|
|
|
Related: the same `context` name means two different things either side of `EmbeddableChat` — a `useChat`
|
|
option and a component prop, neither reading the other's — which is what hid the original bug twice.
|