Session state moved off process-wide globals into per-session holders, so two sessions in one process stay separate.
What's wrong with this entry?
Mutable state that used to sit at module level, shared by everything running in one process, now lives in lazily created holders keyed on the session, reached through getters rather than read directly. Two sessions in the same process no longer share it. Alongside that, the top-level UI provider and the message list take their dependencies explicitly instead of pulling them from ambient state or from long prop lists.
- The top-level UI provider now receives the session, storage, the message queue, initial state and a
keybindingsflag; transcript export renders with keybindings switched off. - The message list takes one combined search object plus a pause-animation flag, replacing five separate props.
- State moved per session covers background daemon beacon tracking, raw stdin capture, the sync and retry engine, background job state, in-flight monitor state, the plan file cache and plan slugs, the design tool's plan store, approved plans, the design-consent cache, verified project grants, the background rendezvous socket server, marketplace and checkout state, and the OAuth callback listener, submitter and active-flow maps.
- Functions that previously read one of these globals now take the session or its state as their first argument.
keybindings, verifiedProjectGrants
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
Process-wide state replaced by per-session containers
Both mention state
-
v2.1.236
Agent, MCP and UI caches scoped per session
Both mention state
-
v2.1.236
The command queue is now passed around instead of being a global
Both mention state