---
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: done
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.

---

**Fixed 2026-08-22.** `GET /chat/sessions/:id` now reports `isCommander`, derived from the session's own cwd
by the same `isCommandersDir` the list and `/chat/live` already used — so the answer travels with the
conversation instead of with the screen showing it.

The composer reads ONE value, `manager.isCommander`, true when either source says so. Both are needed and
neither is sufficient: the SCREEN knows when Command HQ starts a commander, before a session or a transcript
exists for any route to report on, and the SESSION knows once it does, wherever it is opened. Screen-only
was this bug; session-only would have lost the brand-new composer.

Verified on a real commander: `172cdd8c` resolves `cwd=…/commanders` and `isCommander=true`.