Files
platform/COMMS/sidecar-app-store
pastilhasandClaude Opus 5 ed52faae02 correct two claims about agents that the SDK disproves
docs/per-user-linux-accounts.md carried the reasoning that per-user agents were
a large piece of work, and both halves of that reasoning were wrong.

The SDK does have somewhere to put a uid — spawnClaudeCodeProcess, documented
for running Claude Code in VMs and containers — so a member's turn does not have
to become its own process. And the credential claim was backwards: the proxy
holds the OWNER'S credential, reading the owner's own ~/.claude/.credentials.json,
so pointing a member at it spends the owner's account on the member's turns.
The previous handoff had already retracted that one; the doc had not caught up,
which is how a retracted claim stays live.

Corrected in place rather than deleted, with what was believed and why it was
wrong, because the superseded version is the interesting part: the first claim
is what made agents look like a later stage than they are.

Adds the constraint that actually is out of scope, which the old text never
stated: no platform process ever runs as a member, because the sidecar holds
POSTGRES_URL and the JWT secret.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:33:19 +00:00
..

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:362 costs 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.md says 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.