Confirmed the P1 and fixed it in a6f96dc.

The reviewer is right: the entry-time if c.running check was released before Snapshot(), and a turn starting inside that window (running still false) would then have its session replaced by the later SetSession — the guard only closed the "already running at call time" case, not "turn starts mid-rotation".

Fix: a rotation gate instead of a point-in-time read.

• beginRotation() atomically refuses when c.running OR another rotation is in progress, and sets c.rotating under c.mu; it stays held from before Snapshot() through the swap (NewSession and ClearSession both use it via defer endRotation()).
• runGuarded and RunTurn now also refuse to start while c.rotating. So turn-start and session-rotation are mutually exclusive in both directions — a rotation can't begin under a live turn, and a turn can't begin under an in-flight rotation. The run loop's session reference can no longer change under it.

Regression test TestNewSessionRefusesTurnStartedDuringSnapshot forces exactly the reported interleaving deterministically: it parks NewSession inside Snapshot()'s recovery callback (still holding the gate), then asserts a concurrent RunTurn is refused with ErrTurnRunning, running stays false, and the session is not mutated until the rotation completes. I verified the test fails without the c.rotating checks (panics at the RunTurn-refused assertion) and passes with them.

Verification:

• go test ./internal/control ./internal/bot ./internal/cli ./internal/serve ./internal/acp — green
• go test -race ./internal/control -run 'TestNewSessionRefuses|TestConcurrentSnapshots|TestRunTurn|TestClearSession' — green
• go vet ./internal/control ./internal/bot — clean

Extended the fix to close the same TOCTOU window in every other session-mutating entry point (252ff75).

Auditing all live-session mutations (SetSession/Session().Replace/CompactNow) turned up the identical bare-Running()-then-mutate-later shape in five more interactive commands, all dispatched from submit()'s synchronous slash-command path so they can race a streaming turn:

All five now go through the same beginRotation()/endRotation() gate, held from before the snapshot/load through the swap; runGuarded/RunTurn already refuse while c.rotating. Each keeps its original "cannot X while a turn is running" message on the running path and reports errRotationInProgress for the window this closes.

Safety checks I verified:

• No re-entrancy / deadlock: none of these is called from inside a turn body — all callers are the slash-command dispatch and Fork wrappers. Their internal Snapshot/Branches/SnapshotRewrite calls touch only snapshotMu, never rotating.
• Lock order unchanged: beginRotation holds c.mu only briefly to set the flag, then releases; the gate is a flag, not a held mutex, so no interaction with snapshotMu/c.mu ordering.
• Error shapes preserved: rewindFail wrapping, agent.BranchInfo{} returns, and every user-facing message are byte-identical on the running path.

Regression test TestSessionMutationsRefuseWhileRotating asserts all five (plus RunTurn) refuse while a rotation holds the gate with the live session untouched, and that the gate can't be claimed while a turn runs. Verified it fails when the rotating check is removed.

Verification: go test ./internal/control ./internal/bot ./internal/cli ./internal/serve ./internal/acp green; go test -race ./internal/control green; desktop build+tests green; go vet clean.

Confirmed and fixed in 203ab34. The finding is correct — and it was the worst instance of the class: summarizeAt rewrites the live session after a provider round-trip, so the unguarded window was seconds wide, not microseconds.

Why my previous audit missed it: I enumerated direct mutation sites in controller.go (SetSession / Session().Replace / CompactNow), but summarize delegates the Session.Replace to the agent layer (Agent.SummarizeFrom/UpTo in internal/agent/compact.go). I have now completed the audit from the opposite direction — every executor method the controller calls, classified by whether it mutates the session:

• SetSession ×7, CompactNow, SummarizeFrom, SummarizeUpTo — all now behind the rotation gate.
• PruneStaleToolResults — mutates the session, but its only caller is maybeColdResumePrune on the Resume path (session load, no concurrent turn on this controller), same class as Resume itself.
• ReplaceTodoState/SeedTodoState/RebuildTodoState — todo sidecar state, not the message log.

So the gated set is now closed over all user-triggerable live-session mutations: NewSession, ClearSession, forkNamed, Branch, SwitchBranch, Rewind, Compact, SummarizeFrom/UpTo.

Fix mirrors the others: beginRotation()/defer endRotation() from the boundary read through the post-rewrite SnapshotRewrite, original "cannot summarize while a turn is running" message preserved on the running path.

Test hardening: your finding also exposed that my TestSessionMutationsRefuseWhileRotating assertions were too weak — several checked only err != nil, which a bare-Running() revert can satisfy by failing later for an unrelated reason (e.g. missing boundary). Every gated method now asserts the errRotationInProgress sentinel specifically, plus the summarize entries and the "cannot summarize while a turn is running" running-path message. Reverse-verified: reverting summarizeAt to the bare check fails the test at exactly the SummarizeFrom assertion.

Verification: go test ./internal/control ./internal/bot ./internal/cli ./internal/serve ./internal/acp green; go test -race ./internal/control over the rotation tests green; desktop tests green; go vet clean.