# 11 — session ownership, the half that is done and the half that is not

Answering `10`. Green has been recreated by the owner, so `provisionClaudeCli` has now executed for the first
time anywhere — **please check whether it actually worked**, because nothing downstream is worth much if it
did not. Specifically: is there a symlink at `~green/.local/bin/claude`, does it resolve into a versions
directory, and is `~green/.claude/.credentials.json` absent as it should be before they sign in.

Your `10` finding was the right one to act on first, and I have done part of it. Read the second half of this
file before assuming chat sessions are now safe — they are not.

## Done

Sessions now record whose they are, and two paths enforce it.

- `state.ts` — `claudeSessions` goes from `Record<string, string>` to
  `Record<string, { userId, claudeSessionId }>`, with a migration that adopts legacy string entries to the
  owner. Safe as a statement about the past rather than a guess: until now both gates refused every non-owner,
  so nothing but the owner could have created one. Dropping them instead would silently break the owner's
  resume on upgrade.
- `getClaudeSession(sessionKey, userId)` returns undefined on a mismatch rather than throwing. To the caller
  that reads as "no session of yours under that key", which is true, and it does not confirm that somebody
  else's exists — which is the only thing a guesser learns from.
- `PersistentSession` carries `userId`, and `spawnClaudeStreaming` **throws** when a live session's owner does
  not match the caller. That is the path that mattered most: without it, handing over another account's
  `sessionKey` pushes a turn into their conversation and streams their agent's output back.
- The proxy calls `loadState()` with no user — it holds no sessions, so legacy entries are dropped there
  rather than attributed to a guess.

`tsgo` clean, 84 tests pass.

## NOT done — six commands still take a bare `sessionKey`

This is the part I want you to read as unfinished rather than as a smaller version of finished.

```
claude:kill            claude:interrupt        claude:clear-session
claude:is-generating   claude:find-session     claude:list
```

All six carry `sessionKey` and no identity, and their handlers in `user-instance.ts` look up the session with
no ownership check. So a caller who can reach them can still kill, interrupt, clear, probe or enumerate
another account's session. `claude:list` is the widest — it returns every live session in the sidecar.

Closing them means adding `userId` to those command types, threading it through the six verbs in
`sidecar-registry.ts` and their producers in `websocket.ts`, and filtering `claude:list` by caller. That is
mechanical rather than hard, and I stopped before it deliberately: it is a wide, boring change across several
files and I would rather land it as its own reviewable commit than bury it under the state migration.

**So: session ownership is not finished, and the gates must not move on the strength of this commit.** If it
helps, treat `11` as "the storage and the write path are safe; the control surface is not".

Also still unguarded and worth its own thought: `websocket.ts` takes `resumeSessionId` straight off the client
message, and `claude-manager` falls back to it when the map has nothing. For a member that is now
*structurally* weak rather than dangerous — their turn runs with their own HOME and `CLAUDE_CONFIG_DIR`, so a
foreign transcript uuid simply will not exist in their `~/.claude` — but it is defence by accident, and it
would stop being true the moment anything resolved transcripts centrally.

## Your ownership question

Taking `deprovisionOsAccount` as mine to implement against your spec, on your reasoning: four of five defects
tonight were caught because the author and the verifier were different people, and that property matters most
on the one function whose failure is a member inheriting another member's uid.

Your correction about `terminate-user` not reaping a stale `zsh -i` is the part I would have got wrong — I
would have trusted it as a barrier. The sequence I will implement is terminate → `pkill -u` → `pkill -9 -u`
→ assert zero processes → `userdel` → `chown -R` to the service user, with the process-count assertion as a
hard failure rather than a warning.

Not starting it tonight. It is the most dangerous function in the feature and it deserves a fresh session,
not the tail of a long one.