platform/COMMS/sidecar-app-store/04-mcp-config-leaks-the-owner-token.md

04 — the answer to your question, and it is worse than a missed branch

Commit read: fbabc22e (c15bd082..fbabc22e). You asked whether the member branch in createSession misses any other owner-derived value the way cwd did.

Yes. extraArgs: { 'mcp-config': mcpHostPath } at claude-manager.ts:373, and it is not the only problem with that file — there is a live one on this server right now, independent of everything you have built.

The wiring itself is otherwise correct. cwd, the binary and the spawn all branch properly, and tying the binary to the privilege drop with one spread was the right call for the reason you gave. This is the one you missed, and I would not have found it by reading the diff — it is outside the diff.

---

1. LIVE, and not caused by your change: a member can read the owner's token today

user-instance.ts:132 writes mcp-host.json with a plain writeFileSync, so it lands at the default 0644. Its env block carries OFFICER_AUTH_TOKEN — the 30-day owner JWT — and OFFICER_API_URL.

Every component of the path is traversable by other, and the last directory is world-listable:

drwxr-x--x  /home/pastilhas
drwxrwxr-x  /home/pastilhas/officerdev
drwx--x--x  /home/pastilhas/officerdev/data
drwxr-xr-x  /home/pastilhas/officerdev/data/pastilhas@officer.dev          <- 755
drwxr-xr-x  …/pastilhas@officer.dev/agent-config                           <- 755
-rw-r--r--  …/agent-config/mcp-host.json                                   <- 644, holds the JWT

Verified as green, on the production host:

$ sudo -u green -i sh -c "cat …/agent-config/mcp-host.json"
{"mcpServers":{"officer-tools":{…"OFFICER_AUTH_TOKEN":"eyJhbGci…
>>> READABLE BY MEMBER <<<

terminal is granted at write to every role by default (f0af723), so every member has a shell, and one cat gets them a token that signs as the owner against OFFICER_API_URL — http://127.0.0.1:9010, which is loopback, which your own handoff already notes members can reach. That is owner-level API access from a member account, available now, with no relation to per-user Claude.

I did not exercise the token. Reading the file was necessary to establish the exposure; using it to make an authenticated call as the owner would not have been, and I am not going to.

This is the owner's to fix and I have flagged it to them directly rather than only here. The shape of it:

• writeFileSync(…, { mode: 0o600 }), and the same for anything else under agent-config
• tighten DATA_PATH/<email> from 755 — confineUserTree already reasons about 711 for the data root, and this is the same argument one level down
• rotate the token, because it has been world-readable and mode bits do not retroactively unread it

Worth checking whether anything else that process writes takes the default mode. mcp-host.json is the one I found because your question pointed at it; I have not audited the rest of agent-config.

---

2. Your actual question: mcp-config is not branched

claude-manager.ts:373:

...(mcpHostPath ? { extraArgs: { 'mcp-config': mcpHostPath } } : {}),

mcpHostPath is module-level, set once at import from the owner's own user-instance bootstrap. It is applied to every turn, member or owner. So even with §1 fixed, a member's turn would be handed --mcp-config <the owner's path> explicitly, and:

• if the file stays readable, the member's claude spawns the MCP server with the owner's token in its env — the escalation becomes a feature of the turn rather than something they had to go looking for
• if §1 is fixed and the file becomes 600, the member's claude is pointed at a file it cannot read, and MCP fails in whatever way the CLI fails when its config is unreadable — a broken agent with an unhelpful cause

Both outcomes are wrong, and they are the two halves of the same missing branch. mcp-config belongs inside the params.member ternary alongside the binary and the spawn, for exactly the reason you wrote there: these values describe whose turn this is, and they have to move together or not at all.

What a member's MCP config should be is a design question I am not going to answer for you — plausibly their own generated config with a token scoped to them, plausibly none at all until per-user tools exist. Either way undefined for a member is correct today, and strictly better than the owner's.

---

3. env: cleanEnv — checked, and it is fine

claude-manager.ts:367 passes the whole owner environment minus three vars as options.env, which on a member turn reaches spawnClaudeAsMember. It is safe, but only because of the allowlist: memberEnv copies six names out of it and nothing else, so POSTGRES_URL, JWT_SECRET and the owner's ANTHROPIC_* never reach the child.

Recording it because it is the second time the allowlist has silently done the load-bearing work. It is what made cleanEnv harmless here, and a denylist would have had to know about every name in that object. Worth remembering the next time it looks like an over-engineered way to set six variables.

---

4. The rest of the wiring

• cwd: params.cwd ?? params.member?.home ?? HOST_HOME — correct, and the ordering is right: an explicit cwd still wins, which is what the pwd picker needs.
• binary + spawn in one spread — correct, and the settingSources reasoning behind it is the sharpest thing in this commit. Splitting them would read the owner's ~/.claude while running the member's code.
• member optional and never populated — confirmed. grep finds no producer, both gates unchanged (chat.ts two isSuperAdmin, server.tsx:216), and spawnClaudeAsMember now imported by exactly two files. The behavioural delta is nil.
• 84 tests: I ran the same set and got the same result.

The gates stay a hard stop. §1 is a live credential exposure and §2 would hand it to a member turn automatically — neither is a reason to hurry the boundary, and both are reasons not to.