pastilhasandClaude Opus 5
6a85ca5d1f
Four fixes from the live server's review. One was a real defect.
THE BINARY WAS NEVER CHECKED. spawn-as-member passed `command` from the SDK
through untouched while a comment claimed the member's own install was what ran.
Since claude-manager resolves the OWNER'S CLAUDE_BIN at module load, wiring the
hook would have exec'd the owner's binary as the member — the precise confusion
this file exists to prevent, asserted in prose and enforced nowhere. Now throws
unless the command resolves to claudeBinIn(run.home).
NEVER_ENV COULD NOT FIRE. It tested an environment that memberEnv builds from
ALLOWED_ENV, so a denied name was already impossible; it was also missing six
credential variables the installed SDK reads. Replaced with the subset check the
reviewer proposed: anything not in ALLOWED_ENV or {HOME, CLAUDE_CONFIG_DIR} is a
leak whatever it is called. Complete by construction, and it cannot rot as the
SDK grows variables — which the denylist provably had already.
Also: one derivation of the binary path instead of two (install resolved from
the email, exec from the home — fine until they disagree), and the constraint
that ALLOWED_ENV may never hold a secret written at the list itself, since
`env K=V` in the argv is visible in /proc/<pid>/cmdline to every account.
Not acted on, and said so in COMMS: their finding that the 711 in 401dcb7 is
inert, and that a retrofit needs a mode pass. Both are theirs. Nor pulled chat
from DEFAULT_ROLE_CAPABILITIES despite agreeing a member currently sees a tile
that 403s — that is the owner's call, not a defect.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
COMMS/sidecar-app-store
A tracked channel between the agents working on the sidecar app store and per-user Linux accounts.
Why it is in the repo
Because the alternative was the owner relaying findings between us by hand, from memory, at the end of long
sessions. A file survives a context window; a message in a chat does not, and neither does the reasoning
behind it. The untracked COMMS/ at the workspace root is for state about one machine at one moment. This
one is for things any clone should carry.
How to use it
- One file per handoff, named
YYYY-MM-DD-<subject>.md. Dated, because "which of these is current" is the first question a reader has. - Write what you verified and what you assumed, separately and explicitly. A handoff that reads as confident about something untested is worse than no handoff — the reader will build on it.
- Name files and lines.
os-user.ts:362costs nothing to write and saves the reader a search. - Reply in a new file rather than editing someone else's. An edited handoff loses the record of what was believed when a decision was made, which is usually the thing that explains the decision.
- Delete a handoff when it is spent, the way
platform/CLAUDE.mdsays to delete finished checklists. Something still open belongs here; something done belongs in a commit message or a doc.
Where the durable reasoning lives instead
Handoffs are for coordination — what is broken, what is unproven, what needs deciding. Anything that will
still be true in a month belongs in docs/per-user-linux-accounts.md or next to the code, not here.