Privacy Controls
Users can inspect, delete, or wipe anything the agent remembers. Three escalating tiers — each with stronger confirmation gates.
/memory statusPer-namespace counts, mode, recall toggle, owner_id/memory listAll semantic facts + episodic arcs/memory list factsSemantic facts only/memory list sessionsEpisodic arcs only/memory list rulesProcedural style rulesMemory control runs as a runtime branch
Explicit memory commands are now first-class runtime traffic. Turn triage routes natural-language memory commands like:
"what do you remember about me?"/"show my memories""forget #3"/"forget that I mentioned my therapist""turn proactive recall off"/"enable recall""remember that I prefer shorter replies"
When this route fires, the turn skips memory retrieval and therapeutic
response generation. The memory-control tool surface executes the operation
deterministically and returns a user-facing confirmation. Destructive
single-record deletes write a pending_action to memory_control state so
the next turn can confirm or cancel it through the same runtime branch.
Confirmation design
| Tier | Gate | Why |
|---|---|---|
| Inspect | None | Read-only, no side effects |
| Delete | Preview panel + next-turn y/N (default N) | Pending action carried in memory_control.pending_action until the user confirms or cancels |
| Wipe | Must type the literal word clear or purge | Muscle-memory y confirmation would be dangerous for namespace-wide deletion. y, yes, and CLEAR all cancel — only the exact lowercase word proceeds. |
/memory clear rules preserves settingsThe recall toggle (proactive_recall_enabled) is a user preference,
not content. Clearing rules wipes the directives but keeps the
toggle state.
Always-on subsystems
Two subsystems write regardless of memory mode — privacy asymmetry for safety and product quality:
| Subsystem | Incognito behavior | Retention |
|---|---|---|
| Crisis log | In-memory (dies at exit), user_id = None, opaque session_id (SHA-256) | Operator-driven — records persist until an operator purges them via /memory purge-crisis [days] (no automatic expiry) |
| Session feedback | In-memory (dies at exit), user_id = None, opaque session_id | Operator-driven — apurge_before(cutoff) exists, but no scheduled purge ships |
Retention is operator-configured, not automatic: the durable backends
expose a purge-before-cutoff path, and the crisis log adds a manual
/memory purge-crisis [days] TUI command. Choose a retention window that
fits your deployment's policy.
No user text is stored in either subsystem — only classification
labels, classifier provenance, and structural metadata. Both
subsystems live under agent/audit/
and agent/feedback/,
not agent/memory/, so they're explicitly excluded from prompt memory and
from user-facing memory recall toggles.
Recall toggle
/memory recall on # agent may reference past content proactively
/memory recall off # agent uses stored context only when user brings it up
Procedural rules always apply regardless of the toggle — the distinction is between content recall (referencing what was said) and directive application (following style rules).
Owner scoping
All destructive operations are scoped to session.owner_id():
| Flag | Scope |
|---|---|
Without --user-id | Thread_id (backward-compatible) |
With --user-id alice | Alice's memory only |
Cross-user deletion is not reachable through the CLI.