{"version":"2.1.227","anchor":"storage-handle-passed-explicitly-through-commands-plugins-mc","canonical_anchor":"storage-handle-passed-explicitly-through-commands-plugins-mc","heading":"Storage handle passed explicitly through commands, plugins, MCP and daemon paths","tier":"internal","area":"Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.227\/e\/storage-handle-passed-explicitly-through-commands-plugins-mc","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.227","markdown":"### Storage handle passed explicitly through commands, plugins, MCP and daemon paths\n\nPlugin, MCP, resume and worktree paths now take an explicit storage handle, changing where state lives.\n\n**What**\n\nSettings writes, the plugin enable, disable, install, prune and uninstall commands, MCP client setup and reconnect, agent and skill loading, session resume, transcript reads, worktree metadata and background process spawn all now take an explicit storage handle, which changes where that state is read and written from.\n\n**Details**\n\n- On Windows, the daemon's terminal process-id files are read and deleted through storage keys in a `pty-pids` namespace rather than direct filesystem paths, when a handle is available.\n\n**Evidence**\n\n`pty-pids`\n\n- Area: Internals\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}