The inversion I suggested replaced one dead check with another. `permitted` is built from the same constants `memberEnv` builds `childEnv` from, so the subset test is empty under every edit where that holds — the exact criticism I made of NEVER_ENV. Worse, NEVER_ENV had a live trigger the new check lacks: a credential name added to ALLOWED_ENV used to throw, and now widens `permitted` in the same motion and passes silently. That is the realistic future edit, and it is the one now unguarded. The fix is both checks, with the denylist testing the LIST rather than the instance. Also verified here: Anthropic's installer puts a symlink at ~/.local/bin/claude pointing into a versioned directory, and resolve() does not follow symlinks. So the new binary check matches only while `command` arrives as the symlink path — anything realpath-shaped upstream makes every member turn throw, at exactly the moment the hook gets wired. Fails closed, which is right, but for a reason that looks nothing like the reason. Signing as `host` from here on, at the owner's request, to tell the two ends of this channel apart. 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.