Answers §1 of the per-user-accounts handoff and reviews the per-user-claude one.
A bind-mounted postgres:18-alpine starts, initialises and stays healthy under green's
rootless daemon — so 3bea46f's open question is closed. Two corrections though.
The mechanism in 401dcb7 is not the one doing the work. A container's inner uid never
traverses the host path: the daemon, running as the member who owns that path, resolves and
mounts it, and the container walks the result inside its own mount namespace. Measured here
with ~/.local/dockers at 770 — no x for other — and the container healthy anyway. What is
load-bearing is the DEFAULT-ACL removal, which is why directories created inside the bind
source come out 755. So the 711 is inert, and the file-browser access it costs is avoidable.
And the retrofit is incomplete: setfacl -R -b clears ACLs but not mode bits, so a member
whose ~/.local/dockers already holds data keeps 770 directories and stays broken. Green
cannot detect this — its data was recreated after the manual fix, so it reads as correct for
reasons that predate the commit.
On per-user-claude: NEVER_ENV cannot fire as written (it tests an allowlist-built object)
and is missing credential variables SDK 0.2.59 reads; memberClaudeBin is exported and never
used, so "their own binary" is enforced nowhere; the binary path is derived two different
ways; and env assignments ride in a world-readable argv.
VERIFIED: the mechanism, on this host, against a hand-applied fix.
NOT VERIFIED: 401dcb7's own provisioning path, which has never run here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
First half of per-user Claude. Provisioning and the privilege drop, not yet
wired to a turn — the chat gates stay up and behaviour is unchanged for
everyone. Committed unfinished on purpose so the reasoning is on the record
before the server agent runs any of it; the state is written up in
COMMS/sidecar-app-store/2026-08-11-per-user-claude-handoff.md.
THE CLAIM THAT CHANGED. docs/per-user-linux-accounts.md:226-229 says the Agent
SDK "has nowhere to put a uid", so a member's turn has to become its own
process — a change of shape rather than a flag. It is a flag:
sdk.d.ts:951 exposes spawnClaudeCodeProcess, documented for exactly this ("run
Claude Code in VMs, containers, or remote environments"), and node's spawn
already satisfies the SpawnedProcess shape it wants. So no second sidecar, no
PM2 entry, no inverted transport, and none of the registry rework a second
instance would have forced (registration is name-keyed and evicts its
namesake; the nine claude verbs resolve by capability with no selector).
THE PLATFORM NEVER RUNS AS A MEMBER. The tempting reading of "each member runs
their own Claude" is a second officer-agent under their uid, and it is wrong:
that sidecar needs POSTGRES_URL and the JWT signing secret, so a member-uid
process holding them could read every account and sign a token as the owner —
strictly more than their shell can do, and already forbidden by the .env boot
check. The harness stays the service user's; the thing that runs the member's
code and holds the member's credential is theirs. That is the pty sidecar's
shape, not a new one.
PER-MEMBER BINARY, deliberately, over one shared /usr/local/bin/claude. The
private part is the credential, not the executable — but claude updates itself,
and a root-owned binary is one a member cannot update, which turns "my agent is
a version behind" into a request to the owner. Same installer the owner's own
install uses, run as them, in their home. Idempotent by skipping when present
rather than re-running: the retry button reprovisions on every press.
ALLOWLIST, NOT A FILTER, for the child's environment. At the moment of the call
the calling process holds POSTGRES_URL, the JWT secret and the owner's
ANTHROPIC_API_KEY; setpriv --reset-env means nothing crosses unless written
into the argv, so an allowlist is the complete answer to what a turn can see,
and a denylist would have to be right about every variable added later.
NEVER_ENV throws rather than leaks if someone widens it.
Login is the member's own act against their own account. The platform cannot do
it for them and must not try — the alternative is lending them the owner's
credential. claudeLoginState only reports whether the credential has appeared,
and reads it as the member, so a true answer means their process can reach it.
NOT VERIFIED: any of it at runtime. tsgo passes; nothing has been provisioned
and the spawn hook has never been called. If it turns out setpriv breaks how
the SDK reaches the process, this approach is wrong and the fallback is the
earlier plan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Findings were being relayed through the owner by hand, from memory, at the end of long
sessions. A file survives a context window and carries its reasoning; a message does not.
The untracked COMMS/ at the workspace root stays what it is — state about one machine at one
moment. This one is in the repo because any clone should carry it.
First handoff covers what I would otherwise have asked the owner to pass on: the bind-mount
container test I could not run here and how to retrofit green, the setup-dockers.sh PG18
layout left deliberately alone, the terminal replay bug and the deprovision/uid-reuse hole
with a proposed fix, the shared-home question I cannot answer without the passwd and users
rows, and the four things most likely to surprise a reader — bootstrap-only default grants,
chat grantable but refused, Bun.spawn ignoring uid, and members never getting the owner's
anthropic proxy.
The README states the convention: dated files, verified separated from assumed, name lines,
reply in a new file rather than editing someone else's, and delete a handoff when it is
spent. Durable reasoning goes in docs/ or next to the code — this directory is for
coordination, not for the record.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5