live splits into Agents and Commanders, and the payload says which is which

A commander is a chat by every mechanism it uses, so it turned up in Live beside the conversations
somebody is actually having. With one deploy commander that is untidy. With a watcher armed per repo it
is a list where the thing you are looking for is outnumbered.

Two tabs inside Live, counts always shown. That last part differs from the badge on the Live tab above it,
which hides at zero because a standing `0` there says nothing. These two say a lot at zero:
`Commanders (0)` is how you find out the watcher is not running, which is usually why you looked.

The flag is derived server-side from the cwd, not from a `command_hq_sessions` lookup — every commander
shares one directory, so the directory IS the answer, it costs no query, and it is already right during a
commander's first turn, before any row exists.

It has to be in the payload rather than computed in the panel, and that is the point of the change: the
iPhone app swipes between LIVE chats and has no room for tabs. Filtering there needs the server to name
them. A deploy commander appearing in that swipe order is precisely what must not happen.

A commander row also now opens Command HQ instead of /chat. Same transcript either way, but /chat renders
it with nothing that makes it a commander legible — no category, no cost, no watcher state, and no way to
disarm it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/api/chat/chat.ts

@@ -27,6 +27,7 @@ import {
   stopBackgroundTask,
   claudeSessionContext,
   liveSessionTitle,
+  isCommandersDir,
 } from './claude-sessions';
 import {
   listOpenCodeSessions,
@@ -287,7 +288,21 @@ chatRouter.get('/live', async (ctx) => {
     // genuinely not been written yet.
     const transcriptId = session.claudeSessionId;
     const resolved = transcriptId && !isOpenCodeSessionId(transcriptId) ? liveSessionTitle(who, transcriptId) : null;
-    return { ...session, harness: 'claude' as const, title: resolved?.title ?? null, cwd: resolved?.cwd ?? null };
+    const cwd = resolved?.cwd ?? null;
+    return {
+      ...session,
+      harness: 'claude' as const,
+      title: resolved?.title ?? null,
+      cwd,
+      // Derived from the cwd rather than looked up in `command_hq_sessions`, for the same reason the
+      // history listing does it: every commander shares one directory, so the directory IS the answer and
+      // it needs no query. It also stays right for a commander mid-first-turn, before any row exists.
+      //
+      // This field is why the route changed at all. The iPhone app swipes between LIVE chats and has no
+      // room for tabs, so it can only exclude commanders if the payload says which ones they are — and a
+      // deploy commander turning up in that swipe order is exactly what it must not do.
+      isCommander: cwd ? isCommandersDir(who.email, cwd) : false,
+    };
   });
 
   // OpenCode rows carry less, and the shape says so rather than faking parity. `isGenerating` is always
@@ -326,6 +341,9 @@ chatRouter.get('/live', async (ctx) => {
       // shown a live row without a name.
       title: meta?.title && meta.title !== '(untitled)' ? meta.title : (getOpenCodePrompt(sessionKey) ?? null),
       cwd: meta?.cwd || null,
+      // Always false rather than absent: a commander is started through Command HQ, which runs claude.
+      // Stating it keeps the two row shapes answerable by one client filter.
+      isCommander: false,
     };
   });
 

src/servers/api/chat/claude-sessions.ts

@@ -1003,7 +1003,7 @@ export function listClaudeSessions(who: ChatIdentity, cwd: string): ClaudeSessio
  * different one — the cwd here comes from a transcript rather than from code, and transcripts record
  * whatever the process was actually in.
  */
-function isCommandersDir(email: string, cwd: string): boolean {
+export function isCommandersDir(email: string, cwd: string): boolean {
   try {
     return resolve(cwd) === resolve(getCommandersDir(email));
   } catch {

src/servers/api/chat/is-commanders-dir.test.ts

@@ -0,0 +1,37 @@
+import { describe, expect, it } from 'bun:test';
+import { resolve } from 'node:path';
+import { isCommandersDir } from './claude-sessions';
+import { getCommandersDir } from '../../data-path';
+
+const EMAIL = 'pastilhas@officer.dev';
+
+// The live payload's `isCommander` is derived from a cwd read out of a transcript, so it is whatever the
+// process was actually in — not a path this code composed. These are the shapes that arrive.
+describe('isCommandersDir', () => {
+  const dir = getCommandersDir(EMAIL);
+
+  it('recognises the commanders directory', () => {
+    expect(isCommandersDir(EMAIL, dir)).toBe(true);
+  });
+
+  it('survives a trailing slash and a .. hop', () => {
+    expect(isCommandersDir(EMAIL, `${dir}/`)).toBe(true);
+    expect(isCommandersDir(EMAIL, `${dir}/sub/..`)).toBe(true);
+  });
+
+  it('rejects a sibling and a child', () => {
+    expect(isCommandersDir(EMAIL, resolve(dir, '..'))).toBe(false);
+    expect(isCommandersDir(EMAIL, resolve(dir, 'nested'))).toBe(false);
+  });
+
+  // A commander's cwd belongs to the account that owns it. Reading one user's directory as another's
+  // would file their commanders under the wrong person and, in the iPhone swipe order, show them.
+  it('is per account', () => {
+    expect(isCommandersDir('someone-else@officer.dev', dir)).toBe(false);
+  });
+
+  it('never throws on rubbish', () => {
+    expect(isCommandersDir(EMAIL, '')).toBe(false);
+    expect(isCommandersDir(EMAIL, '\0')).toBe(false);
+  });
+});