pastilhasandClaude Opus 5
92e014c19f
The plumbing is right where it matters: userId comes from ws.data, the authenticated socket, never the client message. Gates up, tests pass, path inert. The resolution is not. Three inputs collapse to undefined, and undefined means "run as the server owner": the caller IS the owner (correct), resolveHomeDir FAILED, and the account has no os_user. The last two are "I could not determine whose this is", and they are answered with the owner's binary, the owner's ~/.claude credential, the owner's HOME, and — since mcp-config branches on the same field — the owner's MCP config carrying OFFICER_AUTH_TOKEN. 23's own text says the caller must not fall back to running as the owner, and names a wrong answer here as the one thing that must not happen by accident. The code does exactly that. The no-os_user case is not hypothetical. provisionOsAccount is non-fatal at every stage and provision-os.ts records the account either way; provisioning failed three separate ways on a real member tonight while the row continued to exist. Such a member, once the gates lift, does not get an error — they get the owner's agent. Suggested a discriminated result — owner | member | refuse — so that the owner's identity can only be reached by positively establishing it, never by failing to establish anything else. resolveHomeDir already returns isOwner as a positive fact; only the funnel through undefined throws it away. Of everything tonight this is the one I would least want to discover after the gates moved, and I would fix it before the history layer: that one is a correctness bug when it lands wrong, this is a credential boundary that fails silently and looks like success. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>