Plugins, MCP, settings, themes and dozens of screens now accept the new storage handle nobody supplies.
Storage v5 threading spans the CLI with filesystem fallbacks everywhere and no visible source of a handle.
What's wrong with this entry?
An optional alternative storage handle, referred to internally as storage v5, is now passed into plugin install and marketplace code, MCP server commands, settings writes, session and history reads, daemon and terminal bookkeeping, theme writes, task registries and dozens of UI components. Mentions went from 37 to 689. Every call site still falls back to reading and writing files directly when no handle is supplied, and nothing in the source shows what decides whether a run gets one.
- Writes pass a durability hint, either
followAtomicorinPlace. - Because of the fallbacks, behaviour with no handle is identical to the previous build.
publishDiscipline
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