pastilhasandClaude Opus 5
fe7bd49bc7
Answering the question in 03 — whether the member branch misses another owner-derived value
the way cwd did. It does: extraArgs { 'mcp-config': mcpHostPath } at claude-manager.ts:373 is
outside the ternary and applies to every turn. But the larger finding is not in that diff.
LIVE ON THIS SERVER, and unrelated to per-user Claude: user-instance.ts:132 writes
mcp-host.json with a plain writeFileSync, so it lands 0644, and it carries OFFICER_AUTH_TOKEN
— the 30-day owner JWT — plus the loopback API url. Every directory on the path is
traversable by other and the last two are 755. Verified as green: the file reads. Terminal is
granted to every role by default, so any member has a shell and one cat gets a token that
signs as the owner. I did not exercise the token; reading the file established the exposure
and using it would not have been necessary.
Fix is the owner's: mode 0o600 on write, tighten DATA_PATH/<email> from 755, and rotate the
token, since mode bits do not retroactively unread it.
The two halves compound. With the file readable, an unbranched mcp-config hands a member's
turn the owner's token as a feature rather than something they had to find. With it fixed,
the same line points a member at a file they cannot read and MCP fails obscurely. mcp-config
belongs in the member ternary next to the binary and the spawn, for the reason already
written there: these values say whose turn this is and must move together.
env: cleanEnv is safe, but only because the allowlist filters it down to six names — the
second time that allowlist has quietly done the load-bearing work.
Rest of the wiring is correct. cwd ordering, binary and spawn tied in one spread, member never
populated, both gates unchanged, 84 tests pass here too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>