pastilhasandClaude Opus 5
288679af09
host's finding on 6b7aad91. claudeLoginState ran two `runAs` probes in parallel,
and each is a `sudo -n setpriv` fork/exec that writes a line to
/var/log/auth.log. It is reached from /agent-status, which sits on a grant every
role holds by default, so a polling UI would have cost two sudo spawns and two
auth-log lines per poll per member — cheap individually, unbounded in aggregate,
and the auth log is where a real sudo event has to stay visible.
One call answering both questions with markers instead of two exit codes. Did
not take his second suggestion of caching `installed`: one call per request is
cheap enough that a second mechanism with its own invalidation is the worse
trade, and that judgement is recorded in COMMS so a polling UI can revisit it.
Also carries the verify list he asked for, including the pertento host key I
accepted on first use so git could reach his remote — he can compare it against
the server, which I cannot.
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.