storageV5
A Claude Code settings key, read out of the shipped bundle. It was in the build from v2.1.315 and was gone by v2.1.317.
Session history, resume and usage can now read from a pluggable backend, though files are still used.
Not Anthropic's. This is the line from the earliest changelog entry here that named it, v2.1.221.
In the changelogs
29Releases whose published page names storageV5.
-
v2.1.280
New telemetry fields for git/file sync sessions
Claude Code's internal telemetry for git/file sync sessions now includes three new fields
found in this entry's text
-
v2.1.277
Policy-limits client lazily composed at startup, behind an unresolved gate F()
Policy limits client for the agents view is now lazily loaded at startup behind an internal gate
found in this entry's text
-
v2.1.277
API client builder gains a permissionContext parameter and querySource default
The internal API client builder gained a permissionContext parameter and a querySource setting
found in this entry's text
-
v2.1.275
prompt.submit context building now goes through async storage-aware helper
Building the context attached to a submitted prompt is now an async, storage-aware step
found in this entry's text
-
v2.1.274
New telemetry before resuming a subagent
Resuming a subagent now logs diagnostic details about how it's being resumed
found in this entry's text
-
v2.1.273
Session-resume: findUnresolvedToolUse now used directly instead of storageV5 field
Session resume in print mode now finds unresolved tool calls directly instead of via a stored storageV5 field
found in this entry's text
-
v2.1.271
Config/Status/Stats/Usage dialog now takes explicit host props instead of a bundled context object
Config, status, stats and usage dialogs now receive explicit props instead of one bundled context object
found in this entry's text
-
v2.1.260
Worktree-session cleanup on resume consolidated into a shared helper
Worktree cleanup logic on resume was consolidated into a shared helper.
found in this entry's text
-
v2.1.247
v5 storage handle passed into more subsystems
More subsystems get the newer storage handle, including permissions and subagent queries.
found in this entry's text
-
v2.1.242
Bridge worktrees now use the same storage backend as the session
Remote session worktrees now store their state in the same place as the session itself.
found in this entry's text
-
v2.1.242
More paths carry their own storage handle, and directories are created through it
Hooks, plugin refresh, worktrees, memory writes and MCP reconnect are handed storage and credentials directly.
found in this entry's text
-
v2.1.242
Storage and credential handles passed as arguments instead of read globally
Dozens of functions now receive storage and credentials as arguments instead of reading global state.
found in this entry's text
-
v2.1.238
Storage handle passed into many more call paths
Resume, remote sessions and several other paths now get an explicit storage handle instead of a global.
found in this entry's text
-
v2.1.236
Storage handle threaded through MCP and skills code paths
MCP and skills code now receives its storage explicitly instead of reading a process-wide location.
found in this entry's text
-
v2.1.232
Session storage passed explicitly instead of reached for globally
Session storage is now passed explicitly through review, fork, compaction, team memory and config writes.
found in this entry's text
-
v2.1.229
Storage and session handles passed explicitly instead of read from globals
Storage and session handles are now passed around explicitly instead of read from process-wide state.
found in this entry's text
-
v2.1.228
Storage selector threaded through many call sites
Many background writes now name which storage they use instead of assuming one.
found in this entry's text
-
v2.1.227
Optional key/value storage backend threaded through background sessions, plugins and the daemon
Background jobs, the daemon, plugin caches and plan docs can all route through the optional storage backend.
found in this entry's text
-
v2.1.227
A new storage backend is wired through the product but returns nothing
A new storage layer is plumbed everywhere but builds nothing, so files are still read directly.
found in this entry's text
-
v2.1.225
Daemon auth cooldown and status can go through the v5 storage layer
Background daemon login cooldown and status can live in a storage service instead of local files.
found in this entry's text
-
v2.1.223
First-party event logging exporter takes a storage backend
Event logging now routes through a cached storage backend.
found in this entry's text
-
v2.1.223
User-scope skills and dynamic workflows can be read and written through the storageV5 backend
Your skills and saved workflows can be read and written through a pluggable storage backend instead of local files.
found in this entry's text
-
v2.1.222
Telemetry retry batches can persist as v5 streams
Failed telemetry batches can be stored and retried differently, but only with a backend that nothing here supplies.
found in this entry's text
-
v2.1.222
More state gains v5-backed code paths
Themes, settings, tasks and transcripts gained alternative storage paths that stay dormant without a backend.
found in this entry's text
-
v2.1.222
Transcript writes and head/tail reads can go through the v5 storage backend
Transcript writing can be redirected to a different storage layer, but nothing turns that on here.
found in this entry's text
-
v2.1.221
Session state moves onto a pluggable storage backend
Session history, resume and usage can now read from a pluggable backend, though files are still used.
found in this entry's text
-
v2.1.221
Cleared sessions from the v5 store no longer stat the filesystem for a timestamp
Cleared sessions get their date from what was already read instead of touching the disk.
found in this entry's text
-
v2.1.221
New namespaced storage key factory ("storageV5")
A new namespaced storage-key system exists for transcripts, settings and memory, but nothing supplies its backend.
found in this entry's text
-
v2.1.221
Transcripts, session listings and the changelog can be read and written through a v5 storage backend
Transcripts, session listings and the changelog can be read from a storage backend instead of local files.
found in this entry's text
First cited
14The earliest release whose published evidence quoted storageV5 was v2.1.222, 4 Aug 2026. That is the oldest release this project wrote about it, so it is a floor on the name's age and not the release that introduced it. It is not a presence reading: which builds carried the name is the table below.
8 further spans in the ledger name it. The list above is the earliest first and stops at 6.
Presence across releases
2Build by build
5One row per release since the first build this name was read out of. Absent means the build was read and the name was not in it, never mined means no bundle for that release was ever archived, and a declared type or a default is only ever what that release's own bundle stated.
Read out of the published npm bundle release by release, and out of Anthropic's own documentation as this site captured it. Nothing on this page is a description anybody here wrote about what the settings key does. All settings keys.