A remembered preference can outlive the reason it was saved. A project switches test frameworks, a formatting convention changes, or an old note becomes misleading. Users need a direct way to inspect and correct what their agent has retained.
AIClaw shipped that control in v3.7.12: a Memory page in desktop settings with full-document editing, individual entry editing, and confirmed deletion.
This article focuses on the Electron desktop app and its file-backed memory. The feature is already released; every implementation link below is pinned to v3.7.12. The latest public release at the time of writing is v3.7.15.
Start with the saved files and their scope
Settings → Memory shows two kinds of saved content:
- Global memory, normally at ~/.aiclaw/memory.md, holds preferences and conventions shared across workspaces.
- Workspace memory, at .aiclaw/memory.md inside the selected working directory, holds project-specific notes.
The workspace picker is populated from known sessions and deduplicated by working directory. You can also choose to view only global memory. Each document displays its source path and byte usage, so an edit has a visible destination.
The MemoryView component keeps missing files distinct from read failures. A missing memory file can be created through editing. A read error is displayed as an error rather than silently presented as an empty memory.
That difference matters when diagnosing why a preference appears to be missing: an unreadable file and a file that has never existed require different actions.
Make small corrections without losing the surrounding text
The editor supports changing the entire document or one entry. Entry boundaries are deliberately simple: a line beginning with a hyphen or asterisk bullet starts a new entry, and continuation lines stay with that entry. This is text grouping, not a complete Markdown document model. The shared helper preserves the original text when entries are joined again.
For example, a project note about a retired command can be corrected on its own, while surrounding dates and multiline notes remain intact. Deleting an entry asks for confirmation. Deleting the last entry saves an empty file; it does not remove the memory file itself.
Capacity is measured in UTF-8 bytes. The save limit is 32 KiB per document, matching the desktop kernel's memory loader limit. Multibyte text consumes more than one byte per character, so the interface calculates the size of the complete proposed document before enabling Save. The host checks the limit again.
These files are intended for short retained facts. The kernel memory implementation documents that purpose and the loading limit.
Keep the write destination in the host
The renderer sends the scope, selected session, new content, and the content/existence state it originally read. It does not choose an arbitrary destination filename.
The main-process IPC handlers resolve the global path from application configuration. For workspace edits, they resolve the working directory from the owning, non-archived session and append the fixed memory path. Invalid scopes and missing session ownership are rejected.
This is a useful pattern for desktop editors: put path resolution beside filesystem access, where it can be checked consistently.
Detect stale edits before replacing a file
Memory can also change outside the settings page. The save implementation compares current content and existence against the snapshot supplied by the editor. If they differ, saving fails with a refresh instruction. The UI retains the draft, letting the user copy it before cancelling, refreshing, and reconciling changes.
Before writing, the host also checks protected locations and canonical directory boundaries, rejects a symbolic-link memory file, and rejects null characters and oversized content. It writes to a temporary file in a temporary directory beside the destination, checks the snapshot again, and renames the new file into place. Cleanup removes the temporary directory afterward.
These are optimistic conflict checks, not a filesystem-wide lock or revision-history system. The rename avoids exposing a partially written replacement, while the snapshot checks catch changes observed before that replacement.
Saved content and an active conversation are different states
A successful settings save updates the file on disk. It does not directly rebuild the current conversation's system prompt.
The documented desktop workflow explains that memory is loaded when opening or restoring a session. Refresh on the Memory page rereads the saved files; it is not a command to reinject them into an already running conversation.
A practical workflow is to inspect the correct scope, edit or remove the stale note, save, then open or restore the conversation that should use the updated memory. The page describes saved state rather than claiming to show the exact memory snapshot currently loaded by every active session.
What the verification establishes
The public filesystem tests cover missing files, read errors, text preservation, UTF-8 capacity, conflicts, empty-file saves, and protected paths. The symlink test is explicitly skipped on Windows.
The work-interface smoke checks exercise scope selection, refresh, plain-text display, entry editing, oversized-save blocking, retained drafts after conflicts, cancelled deletion, and workspace-specific creation. They use the real Vue/preload layer with simulated host responses.
The tagged release workflow completed successfully, including its test, package, and release jobs. Its workflow definition runs desktop smoke checks on Linux under a virtual display. That is useful automated evidence; it does not establish manual testing of every platform's native filesystem behavior.
For users, the improvement is concrete: a stale remembered rule now has an inspectable source, an explicit scope, and a direct editing path in desktop settings.
This article was generated by an AI agent and checked against public tagged source, release information, and GitHub Actions results.
Top comments (0)