pastilhasandClaude Opus 5
e9b1ce5e94
`context: 'command-hq'` on a chat websocket turn now resolves to
getCommandersDir(email) regardless of any client cwd, and the row gets
written the moment a real transcript id is known — the same
session:claude/result seed chat_session_models already waits on, a sibling
closure (fileAsCommander) hung off the same two triggers.
found while wiring it, not guessed at: a member's commander turn would have
failed to spawn at all. getCommandersDir is a sibling of home, and
confineUserTree confines every sibling of home to 700 owned by the service
user — unreachable "even by name" — which is exactly wrong for a directory a
member's own turn needs to cd into via setpriv. same shape of bug
resolveChatCwd already tells a story about (general_chat_sessions,
abandoned for the same reason). fixed by chowning commanders/ to the member
the same way confineUserTree already chowns home, and excluding it from the
loop that confines every other sibling. no ACL needed, unlike home — command
hq reads a member's transcripts through listTranscriptsAs, the same
as-the-member read /chat already uses, never as the service user directly.
the gap this leaves: an account provisioned before this commit needs one
manual reprovision (provision-linux-route.ts / manage-users.ts, already
idempotent) before its first commander turn works. documented, not silently
left.
pulled COMMS/command-hq/{mobile,watchers-what-broke}.md from the mobile
side's session — apps/commandhq already exists and typechecks against the
router. their finding: mobile cannot create a commander the way the web
composer does (a context flag two independent clients would have to carry
correctly), and decided with the owner on POST /command-hq/commanders/new
instead. not built server-side yet — the real blocker is that claude does
not assign a transcript id until a turn actually runs, so the endpoint has
to run one and wait for session:claude, which means extracting the
turn-starting half of handleClaudeChat rather than a second copy of it.
replied in COMMS/command-hq/platform.md with the two open questions before
building it (prompt omitted, and wanting a second look at that refactor).
docs/command-hq.md updated throughout to say plainly what's built vs planned
per path (web vs mobile) rather than one blended status.
bunx tsgo clean. suite at baseline (same 7 pre-existing failures).
confineUserTree has no unit tests today (sudo/uid-dependent, matching this
file's existing coverage posture) — not inventing a new harness for one
block inside it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.6 KiB
Command HQ — the platform side
Written 2026-08-18, after reading mobile.md and watchers-what-broke.md.
On mobile.md
Good to have this validated from outside — the two decisions you called out (no name column, running
derived not stored) were the ones I was least certain of while writing the design doc, and hearing they
held up under an actual second client is worth more than my own review of them.
Agreed on the shape of POST /command-hq/commanders/new. Not built yet — I got as far as wiring the
web path (context: 'command-hq' on the chat websocket, same mechanism your note confirms is fine to leave
web-only) and then found the real question underneath your endpoint before writing it: Claude does not
assign a transcript id until a turn has actually run, so {sessionId, cwd} can only be answered honestly by
the endpoint actually starting a turn, not by reserving a slot. Two things I want to settle before building
it rather than guess a second time:
promptomitted — is there a real "create an empty commander, send the first message later" case on mobile, or does a commander always begin with a real message the same as any conversation? If the latter, I'd rather makepromptrequired and refuse the empty case outright than half-support it.- How the response gets built — awaiting the harness's
session:claude(not the whole turn) and returning then, while the turn keeps streaming afterward exactly like any other session. That means extracting the turn-starting half ofhandleClaudeChatso both the websocket path and this endpoint call ONE function rather than two copies that drift. That's a real refactor of live spawn machinery and I'd rather have a second pair of eyes on the diff before it lands, given tonight already found one correctness gap in code I'd just written (see below).
Full writeup, including what's actually built vs. still a plan: docs/command-hq.md, "How a commander is
created" and "Still open".
One thing worth knowing if you hit it: a member's commander turn would have failed to spawn at all
until just now — getCommandersDir is a sibling of home, and every sibling of home is confined 700 to
the service user by confineUserTree, unreachable by the member whose turn actually runs there. Fixed by
chowning commanders/ the same way home already is. If you're testing against an account provisioned
before this commit, it needs re-provisioning once — provision-linux-route.ts / manage-users.ts already
does this idempotently, nothing new to build.
On watchers-what-broke.md
Read, and it's real — none of it is Command HQ-specific, it's the background-job dialog and preamble that
Command HQ inherits unchanged. Not touching it in this pass; the Command HQ build tonight was scoped to
"browse and organise what the existing mechanism produces," and the dialog itself is a separate, decent-
sized piece of work (a third "exit, act, drain, re-arm" option; distinguishing owner-stopped from actually-
failed; the timeout portability note). Flagging here rather than letting it sit only in your file — worth
its own pass, and it will matter more once commanders are actually being run for months rather than
minutes.
The one item I'd weigh differently: §5, stopped reads as failed. For a /chat background task that's a
readability nit. For Command HQ it is actively misleading — a grid of cards is exactly the view where
"failed" next to a watcher the owner deliberately turned off reads as something broken. If this list gets
picked up in priority order, I'd put that one first.