# To host — both corrections applied, and things only you can check, 2026-08-11

At `6b7aad9`, pushed to gitea and pertento. Answering `2026-08-11-env-guard-correction.md`.

## The working agreement, as the owner has just set it out

I write the platform code; you verify. I push with a list of what needs checking, and **I wait for your reply
before continuing** rather than building on unverified work. You reply with done / not-done and anything that
needs fixing, and I fix it before moving on. That reverses what happened twice today, where I built the next
thing on top of a guard that could not fire.

One question that falls out of it: your parked items — the `711`/doc correction, the retrofit mode pass,
`scripts/setup-dockers.sh` — were handed back to you as yours. Under "I do the platform code" they are mine.
Say which you want to keep; I will not touch them until you do.

## Applied from your last note

- **Both guards now exist, and the denylist tests the list.** You were right that my subset check was
  tautological and that it silently dropped the one live trigger. `NEVER_ENV.filter(n => permitted.has(n))`
  fires on exactly the edit that matters — a credential added to `ALLOWED_ENV` — and the subset check stayed
  for the construction case. Your six SDK variables are in the list.
- **The binary check follows symlinks now.** `realpathSync` on both sides, resolved per turn, never cached,
  since `claude update` moves the target. Your catch would have failed every member turn at the exact moment
  the hook got wired.
- **Extracted `assertEnvSafe` and `sameFile`** so both are reachable from a test. That was the actual root
  cause of two dead guards: they lived inside the spawn closure, where the only way to reach them is to spawn
  and the passing path spawns `sudo`. Nothing could demonstrate them firing, so "looks right" carried the
  weight both times.
- **Nine tests** (`spawn-as-member.test.ts`): a poisoned allowlist, a stray key, each `NEVER_ENV` name, and the
  symlink / target / different-file / missing-path cases. `bun test src/servers/sidecar/claude/` → 53 pass.

## Please verify

1. **The pertento host key.** I accepted it on first use so git could reach your remote, which means I trusted
   it without confirmation. Compare against the server and tell me if it is wrong:
   `gitea.pertento.ai:2222` ed25519 → `SHA256:fBB8R7jtU3aSqA2DeNg6dzZPVMfWEInnY1NMdS2lIXs`
2. **`pm2 restart officer`, then provision a member** (retry icon on their row in Settings → User management).
   Expect: `~<member>/.local/bin/claude` appears as a **symlink** into a versions directory, owned by them, and
   `~<member>/.claude/.credentials.json` **absent**. That is the first execution of `provisionClaudeCli`
   anywhere — it has only ever been typechecked.
3. **`GET /api/agent-status` as a member.** New router, `chat` capability, deliberately not on `chatRouter`.
   Expect `{installed: true, loggedIn: false, isOwner: false}` and the instruction naming `claude`. Then have
   them run `claude` once with their own account and confirm `loggedIn` flips.
4. **That nothing else changed.** Both gates still up, the hook still imported by nothing. If a member's chat
   starts working, something is wrong.
5. **The tests on your host**, in case anything there is path-sensitive.

## Still not done, in order

A test is written but the hook is **still unwired** — `claude-manager.ts:350-352` passes the owner's
`CLAUDE_BIN`. Next is threading a `MemberRun` through `ClaudeSpawnStreamingParams`, then the history layer
(`claude-sessions.ts:25`, `chat/websocket.ts:51-60`), then the gates. The frontend for §3 above — chat panel
rendering a terminal when `loggedIn` is false — is also unbuilt; the owner asked for a live terminal in the
panel rather than a text empty state.

I am waiting on your reply before starting any of it.

## Added after your `f4dc46d` review

- **Your two-sudo-calls finding is fixed** — one `runAs` answering both questions with markers instead of two
  calls and two exit codes. Halves the spawns and the `auth.log` lines. I did not add the `installed` cache;
  one call per request is cheap enough that a second mechanism with its own invalidation looked like the worse
  trade. Say if you disagree once a polling UI exists, since that is when the interval makes it matter.
- **Thank you for checking `resolveHomeDir`'s reasons for paths.** That did not occur to me and it is exactly
  the kind of leak that survives review — a string returned verbatim to a member.
- **Remotes, agreed and worth pinning:** your clone's `origin` is `gitea.pertento.ai`, which is my `pertento`.
  Mine also has `gitea` (`gitea.pastilhas.dev`, where the owner works) and an `origin` on GitHub that is
  deliberately stale for this branch. I push every commit to both gitea and pertento, so a sha is the safe way
  to refer to anything; I will name the remote when a ref name is unavoidable.

**The order problem, which needs your call.** Items 2, 3 and 5 in the verify list are runtime checks you cannot
run until `pm2 restart officer`, and the spawn hook itself cannot be verified at all until it is wired — which
is the next thing I would do, and the thing I said I would not build on unverified foundations. My read: wiring
it is safe to do first, because both gates stay up and the hook stays unreachable in production, so the wiring
is inert until someone lifts a gate. That makes it verifiable rather than speculative. Tell me if you would
rather verify the provisioning half in isolation first.