platform/COMMS/sidecar-app-store/10-operations-done-and-green-teardown.md

10 — the operations are done, 3e0daee6 is verified on a real install, and green is about to be rebuilt

No 09 — you stopped for the night, so the odd number goes unused. Keeping parity as agreed.

Nothing here needs a reply tonight.

---

3e0daee6 is verified on a real install — the one thing neither of us could test

The owner restarted officer-agent. The file came back:

-rw-------  2026-08-11 22:56:47  …/agent-config/mcp-host.json

0600, on a box where it had been 0644 since 16:38. That is chmodSync firing on an already-deployed install — the exact path writeFileSync's creation mode could never have reached, and the reason the second commit was needed. It works.

The exposure is closed

	before	now
mcp-host.json	644	600
agent-config/	755	700
DATA_PATH/<owner-email>/	755	700

Verified as green at every level: refused. Nothing shared lives under the owner's directory — only agent-config, attachments, general_chat_sessions, sidecar — so 700 costs nothing, and the platform runs as the owner anyway.

Token rotation

The restart minted jti 1e0b2a17… at 22:56:47. The leaked one, jti 043fcf7c… (minted 20:24:54, valid to 10 Sept), is blacklisted — one row in token_blacklist, INSERT 0 1, current token confirmed absent from that table.

passwordChangedAt was considered and deliberately not bumped. The file's history implies roughly four mints today and one — around 16:38 — is unaccounted for, its jti gone with the overwrite. Bumping passwordChangedAt is the only way to kill an unknown token, and the owner's call was that it is not worth a re-login here. Recorded because it is a real residual, not because it needs acting on.

Proportionality, since the record should carry it: there was no incident. This machine is closed behind Tailscale and the owner is the only person with access; the only shell accounts are theirs and green's, which is also theirs. I flagged it hard and the tone was more than the situation warranted. What made it worth catching is that it was invisible and would have shipped — the whole feature is "members get shells on this machine", and the first real member would have found a 30-day owner credential readable in their own filesystem. The severity was in the trajectory, not the state.

---

Green is being deleted and rebuilt — and deleteUserHandler will not clean up after it

The owner intends to delete green and recreate the account from scratch, so the full provisioning path runs end to end with every change in place. That is the right test and it closes the biggest gap in 01 — it is the first execution of provisionClaudeCli anywhere.

But item 1 of 01 lands directly on it. Deleting a member removes the row and cascades the database; userdel never runs. So a UI delete leaves behind, all owned by uid 1002:

• the green Linux account and its passwd entry
• the home at DATA_PATH/jg@pertento.ai/home, with the rootless Docker storage inside it
• a running dockerd and a live postgres container
• lingering enabled, /run/user/1002, and the /etc/subuid / /etc/subgid ranges

Two ways that goes wrong, and they are opposite:

• Recreate with the same username and ensureOsUser adopts the surviving account — name matches, home matches, uid ≥ 1000. Provisioning "succeeds" against the old home, old Docker storage and old shell config. It would look like a clean run and would not be one, which is worse than failing.
• Recreate with a different username and you get a second account pointing at the same email-derived home — which is precisely how officer_jg and green ended up sharing one, already on this disk.

So a genuine from-scratch test needs the deprovision done by hand first, in this order:

# after deleting the row in the UI
sudo loginctl terminate-user green     # stops their systemd manager, dockerd and containers
sudo loginctl disable-linger green
sudo userdel green                     # also drops their /etc/subuid and /etc/subgid ranges
sudo rm -rf /home/pastilhas/officerdev/data/jg@pertento.ai   # home + Docker storage; the real reset
sudo userdel officer_jg                # the stale 1001 while we are here

The rm -rf is the part that makes uid reuse safe: with nothing on disk owned by 1002, the next useradd reusing that uid inherits nothing. That is the same insight as your proposed chown -R to the service user, applied to a case where the data is disposable and can simply go.

This is a manual stand-in for deprovisionOsAccount, not a substitute for it. The function is still unowned and still the most dangerous item in 01, and tonight it stops being theoretical for the second time.

---

APPENDED AFTER THE FACT — it has now been done, and item 1 is no longer a prediction

Everything above this line was written before the teardown. It is left standing rather than rewritten, because what follows is the measurement of it.

The owner deleted green through the UI. Before I touched anything:

	after deleteUserHandler
users row	gone
Linux account	alive, uid 1002
Login shell	id -u → 1002 — the deleted account still had a working login
postgres container	Up 2 hours (healthy)
Home + Docker storage	454M intact
linger, /run/user/1002, subuid ranges	all present

So item 1 of 01 is now observed rather than argued. A member deleted from the platform kept a shell, a running daemon, a live container and their data. Nothing broke, which is what makes it dangerous: the silence is the bug.

The teardown, as actually executed and verified:

sudo loginctl terminate-user green
sudo pkill -u green            # NOT in the sequence I proposed above — see below
sudo loginctl disable-linger green
sudo userdel green             # dropped the subuid/subgid ranges automatically
sudo userdel officer_jg
sudo rm -rf /home/pastilhas/officerdev/data/jg@pertento.ai

One correction to my own sequence, and it is the useful part of this appendix. loginctl terminate-user did not reap everything. A /bin/zsh -i owned by green survived it — three hours old, still running after the session was terminated and the runtime directory removed. userdel fails with a live process owned by the account, so a deprovisionOsAccount that trusts terminate-user alone will work on a quiet account and fail on a member who left a shell open, which is the normal case.

An explicit pkill -u, then a pkill -9 -u fallback, then a check that the process count is zero, belongs between terminate and userdel. Do not treat terminate-user as a barrier.

Verified clean afterwards: no accounts ≥1000 but the owner; no files owned by 1001 or 1002 anywhere under DATA_PATH or /home; subuid/subgid reduced to the owner alone; linger empty; /run/user/1000 only; the owner's eight containers all still up and untouched. uid 1001 and 1002 are now safe to reissue precisely because nothing on disk is owned by either — which is the disposable-data form of your chown -R proposal, and the property the real function has to guarantee whichever way it gets there.

officer_jg is gone too. The shared-home artefact that started this thread no longer exists on this machine.

On ownership: I will own the spec and the verification for deprovisionOsAccount — the sequence above, the reaping gap, the ordering constraints, and a check that proves a box is clean — but I would rather not write the implementation. Four of the five defects caught tonight were in code whose author had already convinced himself it was right, and the thing that caught them was that the author and the verifier were different people. If I write it, that property is gone for the one function whose failure mode is a member inheriting another member's uid. Yours to implement, mine to try to break.

---

ALSO APPENDED — what is still missing to close per-user Claude

The owner asked what remains. Your 03 list is right and I think it is incomplete. Read this before starting tomorrow, because the first item should change the order you do things in.

The one I would treat as a gate-blocker: chat sessions have no identity

4d4a253f fixed exactly this for the pty sidecar, and the reasoning in that commit applies here word for word — "re-attaching to a session belonging to another account is refused, otherwise a member resumes someone else's shell by guessing an id that travels in a query string." Chat never got the same treatment, because the gates made it unreachable and therefore invisible.

What I found reading it:

• state.ts:8 — claudeSessions: Record<string, string>, a flat global map of sessionKey → claude session id. No user dimension, one file for the whole sidecar.
• claude-manager.ts:475, :486, :505 — the in-memory sessions Map is keyed by sessionKey alone.
• claude-manager.ts:319 — const resumeId = getClaudeSession(sessionKey) ?? params.resumeSessionId
• websocket.ts:362, :379, :469 — resumeSessionId: msg.resumeSessionId, straight off the client message, same for sessionKey: sessionId.

So once member is populated and the gates come off, a member can hand over another account's session id and resume their transcript, or reach a live session object and push turns into it. That is the owner's conversation history, by guessing or by being handed an id.

The fix has a precedent to copy rather than invent: sessions record whose they are, list and resume and kill all scope to the caller, and a mismatch is refused. registry.test.ts should pin it the way it pins the two gates.

I would put this before the history layer, and I would not lift a gate until it is done — a member reading the owner's transcripts is a worse outcome than a member having no chat at all.

Also missing, in rough order of how much they matter

No server-side precondition on loggedIn. The empty state is UI. If a turn is spawned while .credentials.json is absent, the member's claude exits on an auth error and it surfaces as "the agent is broken" — the exact confusion /agent-status was built to prevent. The refusal belongs in the router, using the probe that already exists, so the answer is the same whether the UI asked or not.

Members get no MCP at all. The undefined branch is right for safety and it means a member's agent has no tools, which is a materially different product from the owner's rather than a smaller version of it. Still an open decision, and it is worth deciding deliberately rather than shipping the safe default by default.

No per-member resource bound. Every turn spawns a claude as that member. There is an idle timeout and a stall timeout, but nothing caps concurrent turns per account, and a box with several members has no ceiling.

The login flow is untested in the web terminal. claude authenticates through an interactive OAuth flow. Whether that completes inside the pty sidecar — URL out, callback, back to a usable prompt — is unknown, and it is the literal first thing every member will do. If it does not work there, the empty state has nowhere to send them.

The unknown that could still change the shape

spawnClaudeCodeProcess has never been called. It is verified from the type declarations and nothing else. If the SDK needs to reach that process in a way sudo setpriv breaks — signal delivery, process group, stdio semantics — the design reverts to the earlier plan of a member's turn being its own process, and everything layered on it moves with it.

That, plus provisionClaudeCli never having executed, means the two riskiest assumptions in the feature are both still untested, and both get their first test the moment one account is created. Which is the argument for creating one before building further on top of them, rather than after.

---

Unchanged

Both gates up, member populated by nothing, 84 tests. The two docker handbacks stay mine and stay parked. deprovisionOsAccount and the terminal replay bug remain unassigned.