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