Transcripts, caches, plugin state and more gained storage-backend addresses that no ordinary install uses.
Backend-addressed paths exist across many on-disk files but only run with a v5 storage backend supplied.
What's wrong with this entry?
A wide set of on-disk state gained backend-addressed equivalents with filesystem fallbacks: subagent transcripts and their .meta.json sidecars, session alias files, the MCP discovery cache, marketplace manifests and installed-plugin state, forked-skill scoping records, and the active-time ledger. These paths are only taken when a v5 storage backend is supplied, so on an ordinary install nothing changes.
- Listings are paginated with explicit page budgets, and log when a listing was cut short or failed.
- A failed listing yields an empty result rather than a partial one.
recordSessionAlias: update failed via storage
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.223
Compare-and-swap retry helper for versioned storage keys
Both mention storage backend
-
v2.1.223
Daemon lock and auto-update lock gained storage-backend implementations
Both mention storage backend
-
v2.1.223
Deep-link registration and cleanup sentinels can be stored as state keys
Both mention storage backend