Files
platform/COMMS/sidecar-app-store
pastilhasandClaude Opus 5 fb2c5c28cb correct my own advice: the subset check cannot fire either
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>
2026-08-11 21:57:54 +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.