Summary
memoryManager exposes createState, listStates, and loadState, but not archiveState or deleteState. The --include-archived flag on listStates confirms that state archiving exists as a concept internally; it is just not reachable through the public CLI surface.
This makes it impossible to manage obsolete states from automated flows. Operators today must either live with the accumulation, or edit data.json directly with Obsidian closed (lossy and fragile — the plugin owns data.json at runtime, so manual edits get overwritten on autosave).
Reproduction
toolManager.getTools({ tool: "memory" })
Returns (for state operations):
createStatelistStatesloadState
No archiveState / deleteState. But:
useTools({ tool: "memory list-states --include-archived" })
…accepts the flag, so archived-state plumbing exists internally.
For comparison, memoryManager does expose archiveWorkspace on the workspace side:
memory archive-workspace <name> [--restore]
The asymmetry between workspaces (archivable via CLI) and states (not archivable via CLI) is the surface gap.
Impact
Concrete instance: a ThinkBox flow on 2026-05-22 produced an obsolete state (a "pre-INI" placeholder superseded by a retroactively-created INI). With the canonical INI established, the placeholder state had no further use, but there is no CLI path to retire it. The state remains visible in listStates indefinitely; the only options are tolerate accumulation or close Obsidian and hand-edit data.json.
Suggested API surface
Symmetric with the workspace side:
memory archive-state <name> [--restore]
That covers archive + restore in one tool, mirroring memory archive-workspace. Internal storage already handles archived vs non-archived (per the --include-archived flag).
If delete-state is desirable for truly disposable states, that's a separate decision — archive alone closes the immediate gap.
Version
Observed on plugin manifest 5.9.6 (current fork build deployed as ThinkBox baseline; patched main.js per #214). The CLI surface in question is upstream behavior, not fork-specific.
Context
ThinkBox uses Nexus as the primary MCP for vault operations. State accumulation is a normal flow side-effect, and operational hygiene benefits from being able to retire obsolete states without dropping out of the CLI envelope.
Summary
memoryManagerexposescreateState,listStates, andloadState, but notarchiveStateordeleteState. The--include-archivedflag onlistStatesconfirms that state archiving exists as a concept internally; it is just not reachable through the public CLI surface.This makes it impossible to manage obsolete states from automated flows. Operators today must either live with the accumulation, or edit
data.jsondirectly with Obsidian closed (lossy and fragile — the plugin ownsdata.jsonat runtime, so manual edits get overwritten on autosave).Reproduction
Returns (for state operations):
createStatelistStatesloadStateNo
archiveState/deleteState. But:…accepts the flag, so archived-state plumbing exists internally.
For comparison,
memoryManagerdoes exposearchiveWorkspaceon the workspace side:The asymmetry between workspaces (archivable via CLI) and states (not archivable via CLI) is the surface gap.
Impact
Concrete instance: a ThinkBox flow on 2026-05-22 produced an obsolete state (a "pre-INI" placeholder superseded by a retroactively-created INI). With the canonical INI established, the placeholder state had no further use, but there is no CLI path to retire it. The state remains visible in
listStatesindefinitely; the only options are tolerate accumulation or close Obsidian and hand-editdata.json.Suggested API surface
Symmetric with the workspace side:
That covers archive + restore in one tool, mirroring
memory archive-workspace. Internal storage already handles archived vs non-archived (per the--include-archivedflag).If
delete-stateis desirable for truly disposable states, that's a separate decision —archivealone closes the immediate gap.Version
Observed on plugin manifest 5.9.6 (current fork build deployed as ThinkBox baseline; patched main.js per #214). The CLI surface in question is upstream behavior, not fork-specific.
Context
ThinkBox uses Nexus as the primary MCP for vault operations. State accumulation is a normal flow side-effect, and operational hygiene benefits from being able to retire obsolete states without dropping out of the CLI envelope.