Skip to main content

Privacy Controls

Users can inspect, delete, or wipe anything the agent remembers. Three escalating tiers — each with stronger confirmation gates.

ConfirmationNone — read-only
/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 rules

Confirmation design

TierGateWhy
InspectNoneRead-only, no side effects
DeletePreview panel + y/N (default N)Single-record deletion is recoverable only from backup
WipeMust type the literal word clear or purgeMuscle-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 settings

The 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:

SubsystemIncognito behaviorRetention
Crisis logIn-memory (dies at exit), user_id = None90 days, purge via /memory purge-crisis
Session feedbackIn-memory (dies at exit), user_id = None180 days (no CLI purge in Phase 1)

No user text is stored in either subsystem — only classification labels and structural metadata.


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():

FlagScope
Without --user-idThread_id (backward-compatible)
With --user-id aliceAlice's memory only

Cross-user deletion is not reachable through the CLI.