Dozens of long-lived caches moved onto objects so a session can be reset inside one process.
What's wrong with this entry?
Across dozens of subsystems, loose file-scope variables were moved onto single state objects or small classes, covering terminal capability detection, plugin and marketplace caches, skills loading, git directory lookups, org policy status, the teammate mailbox, agent observer pairings, computer-use state, voice recording, the global config cache and child-process tracking. Behaviour is meant to be identical; the point is that this state can now be reset per run rather than living for the life of the process.
- Some memoised dynamic imports were deliberately de-memoised back to a plain promise each time.
- Terminal backends such as tmux and iTerm are now cached singletons instead of being rebuilt on every call, and settings-file parse caches are held per store rather than process-wide.
VoiceRecorderState.reset() called while a recording is live; call stopRecording() first, AA.shouldAutoEnable, synchronizedOutputSupported
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.235
Process-wide caches are now scoped per host
Both mention state
-
v2.1.235
Per-session state replaces process-wide globals, and the render root takes explicit dependencies
Both mention state
-
v2.1.235
More file-scope variables replaced by accessor-backed containers
Both mention state