# A Durable Downgrade Must Also Be Live

The RC3 release gate raised a Codex Work Room to Full Access, then lowered the
outer Host mode to Auto. Storage did the safe thing: it reconciled the provider
profile back to Codex's workspace boundary and recorded a newer lifecycle
revision. The open Work Room still displayed Full Access for more than thirty
seconds.

That was not only stale presentation. A remote coding client is part of the
authority boundary. If it keeps showing broader access after the Host has
withdrawn it, the person cannot tell which policy governs the next instruction.
Reconnect happened to replay the narrower durable state, but reconnect is not
an acceptable security protocol.

The bug lived between two correct pieces. The atomic mode transaction already
appended every provider downgrade it caused. The WebSocket handler acknowledged
only `mode_changed`, so the current connection never received those appended
provider revisions. Persistence and streaming had different ideas of what one
completed transaction meant.

The handler now returns the provider permission revisions created by that exact
atomic update. It sends `mode_changed` first, followed by only those revisions.
The existing storage helper keeps its original return contract for other
callers, and repeating Auto does not manufacture another provider event.

A direct WebSocket regression starts with a committed Codex Full Access
profile, lowers the Host ceiling, and proves that the same connection receives
the newer `codex:workspace-ask` state with Full Access marked unselectable. The
adjacent permission, Work Room, mode, and version suites pass 95 tests; the full
suite passed 7,169 tests with 18 skips apart from a separately corrected docs
checkout version drift.

The release lesson is simple: durable state is the source of truth, but an open
client does not become truthful by waiting for reconnect. When one transaction
narrows authority, its live revision is part of the commit's observable result.