MemoryGuard MCP server

Let agents write without turning shared memory into an unreviewed pile. MemoryGuard organizes each write, preserves the evidence behind changes, and keeps governance decisions reversible.

No account. No remote server. No remote telemetry. Local-only usage telemetry is optional and stores bounded, privacy-preserving aggregates locally.

What's New in v0.7.15

• Automatic CodeGraph builds: Trusted bootstrap starts a project's first build in a background process. Default and per-project switches persist; disabling automation preserves the graph. Supported file-write events trigger incremental refresh.
• Clear graph navigation: Switch between a file overview and symbols, filter by file, inspect neighboring relations, and use zoom controls.
• Bounded temporary storage: Ordinary graph queries read SQLite directly instead of retaining full-database copies. Validation and installation temporary files use the owning project/deployment cache and are cleaned up when the operation ends.

See the v0.7.15 release note and CodeGraph automation details. Reconnect or restart hosts after upgrading and repairing their provider integration.

Earlier governance improvements

v0.7.13 strengthens mandatory-rule replacement and recovery, improves audience-aware identity handling, and improves conflict resolution:

• Safe mandatory-rule replacement: Replacements validate the final mandatory package against audience matching, canonical rules, deduplication, sensitivity checks, and publication budgets. Equivalent unlocked predecessors retire in the same transaction; failed validation rolls back the complete update. See the replacement and recovery details.
• Native Agent/group audience matching: Matching and deduplication no longer split the same native audience solely by provider or runtime role. Distinct Agent identities remain separate, and project-scoped audiences retain their project boundaries. Provider repair uses the verified identity for its target provider.
• Readable, atomic conflict resolution: Conflict views preserve readable peer information, and resolution keeps peer groups intact while applying the selected changes atomically. Ambiguous conflicts remain unresolved.
• Cursor Hook protection: Cursor MemoryGuard Hooks now use a 30-second timeout, up from 15 seconds, with failClosed: true.

v0.7.14 only corrects release metadata for the GitHub repository rename; it does not change runtime behavior. See the v0.7.14 release note.

See the v0.7.13 release note and release history.

Earlier release details are kept in the Changelog and GitHub release records.

Token evidence and demo

Usage events distinguish measured_cached_input from measured_cache_write_input. measured_cache_coverage.cache_read and cache_write report complete, partial, or unavailable; measured zero remains 0, while missing provider data remains None/unavailable. Character-based estimates remain explicitly labelled estimated mg_deterministic_unit, never provider tokens.

Run the benchmark only against an authorized local workspace:

python scripts/benchmark_usage_telemetry.py --workspace . --window-days 7 --sync

Read the benchmark guide for measured, estimated, derived, and unsupported semantics. Use the demo recording checklist for a sanitized walkthrough. The repository's synthetic graph artwork is not a live product capture; it is not evidence of usage or savings.

Major V2 refactor in v0.6.0

v0.6.0 was a production data-plane refactor, not a storage-only upgrade:

• Authoritative V2 domains: Memory, Rules, Evidence, Content, Runtime, Projection, Assets, CodeGraph, Skills, and System state are separated into explicit SQLite domains with governed boundaries.
• Explicit cutover: V1_ACTIVE → V2_BUILDING → V2_READY → V2_ACTIVE is fail-closed; V2 never silently falls back to legacy stores or dual-writes after READY/ACTIVE.
• Lossless migration: frozen-source preparation uses coherent SQLite online backups, validates source/target evidence, rechecks live-source drift, and preserves V1 data plus migration backups for rollback.
• Native routing: MCP, CLI, GUI, and Hook surfaces are classified explicitly; the release closed the 233-surface cutover with 138 implemented routes, 95 retired routes, and zero neutral/blocker routes.
• Governed intelligence: Rule lifecycle and RuleMerge, extraction/enrichment, External MCP import, provider control-plane, conversation history, Knowledge Library, and GUI governance all use the V2 evidence and decision paths.
• Operational evidence: Reference Audit, per-domain SQLite health, guarded maintenance, rollback evidence, and safe unbound diagnostics are part of readiness and operations.

Why MemoryGuard

Persistent memory solves storage. It does not solve governance.

When several coding agents write into the same context, records become duplicated, stale, contradictory, over-broad, or unsafe to reuse. MemoryGuard sits between coding agents and their shared memory to keep that context usable.

Without governance	With MemoryGuard
Notes accumulate without a canonical state	Writes are classified, deduplicated, superseded, or surfaced as conflicts
A correction silently destroys the old value	Evidence and supersede chains preserve what changed and why
Tokens and credentials can remain active	Sensitive-looking content is quarantined from active memory
Every write needs manual approval	Agents write normally; people review exceptions and outcomes
Raw chat logs leak into future context	Conversation history remains a separate, explicitly read evidence archive

System architecture

%%{init: {"theme":"base","themeVariables":{"background":"#071521","fontFamily":"Arial, sans-serif","fontSize":"14px","primaryTextColor":"#EEF4F8","lineColor":"#557287","edgeLabelBackground":"#071521","clusterBkg":"#0A1A29","clusterBorder":"#27445A"},"flowchart":{"htmlLabels":true,"curve":"basis","nodeSpacing":32,"rankSpacing":48,"padding":14}}}%%
flowchart TB
    Hosts["CODING-AGENT HOSTS<br/>Claude Code · Codex · Cursor · TRAE&nbsp;&nbsp;&nbsp;&nbsp;"]:::host
    Gateway["LOCAL INTEGRATION<br/>MCP stdio · redirect rules · lifecycle hooks&nbsp;&nbsp;&nbsp;&nbsp;"]:::gateway

    subgraph Core["GOVERNANCE CORE&nbsp;&nbsp;&nbsp;&nbsp;"]
        direction LR
        Identity["TRUST<br/>identity · scope&nbsp;&nbsp;&nbsp;&nbsp;"]:::core
        MemoryAPI["MEMORY<br/>governed I/O&nbsp;&nbsp;&nbsp;&nbsp;"]:::active
        Rules["RULES<br/>scope · assignment&nbsp;&nbsp;&nbsp;&nbsp;"]:::rule
        HistoryAPI["HISTORY<br/>search · timeline&nbsp;&nbsp;&nbsp;&nbsp;"]:::history
        Security["SAFETY<br/>validate · quarantine&nbsp;&nbsp;&nbsp;&nbsp;"]:::danger

        Identity --> MemoryAPI
        Identity --> Rules
        Identity --> HistoryAPI
        MemoryAPI --> Security
    end

    subgraph Stores["LOCAL GOVERNED STORES&nbsp;&nbsp;&nbsp;&nbsp;"]
        direction LR
        SharedDB[("V2 DOMAIN STORES<br/>Memory · Rules · Evidence · Content&nbsp;&nbsp;&nbsp;&nbsp;")]:::store
        HistoryDB[("HISTORY STORE<br/>isolated conversations&nbsp;&nbsp;&nbsp;&nbsp;")]:::historyStore
        AuditDB[("RECOVERY STORE<br/>versions · receipts · backups&nbsp;&nbsp;&nbsp;&nbsp;")]:::store
    end

    Bootstrap["BOUNDED CONTEXT BOOTSTRAP<br/>mandatory rule pack · relevant recall&nbsp;&nbsp;&nbsp;&nbsp;"]:::bootstrap
    Control["HUMAN CONTROL<br/>CLI · desktop governance console&nbsp;&nbsp;&nbsp;&nbsp;"]:::surface

    Hosts --> Gateway --> Identity
    MemoryAPI --> SharedDB
    Rules --> SharedDB
    HistoryAPI --> HistoryDB
    Security --> AuditDB
    SharedDB --> Bootstrap
    Control --> Identity

    classDef host fill:#12243A,stroke:#38D5C8,color:#EEF4F8,stroke-width:1.4px;
    classDef gateway fill:#0D3338,stroke:#38D5C8,color:#EEF4F8,stroke-width:2.4px;
    classDef core fill:#12243A,stroke:#557287,color:#EEF4F8,stroke-width:1.4px;
    classDef active fill:#0D383A,stroke:#38D5C8,color:#EEF4F8,stroke-width:2px;
    classDef rule fill:#3B2C18,stroke:#F3B562,color:#EEF4F8,stroke-width:1.8px;
    classDef history fill:#102F45,stroke:#73C7F5,color:#EEF4F8,stroke-width:1.8px;
    classDef danger fill:#3A2028,stroke:#EA6A6A,color:#EEF4F8,stroke-width:1.8px;
    classDef bootstrap fill:#EEF4F8,stroke:#38D5C8,color:#071521,stroke-width:2.4px;
    classDef store fill:#0B1624,stroke:#7F96A8,color:#EEF4F8,stroke-width:1.4px;
    classDef historyStore fill:#102436,stroke:#73C7F5,color:#EEF4F8,stroke-width:1.4px;
    classDef surface fill:#EEF4F8,stroke:#38D5C8,color:#071521,stroke-width:2px;

    style Core fill:#081827,stroke:#27445A,stroke-width:1px,color:#EEF4F8
    style Stores fill:#081827,stroke:#27445A,stroke-width:1px,color:#EEF4F8
    linkStyle default stroke:#557287,stroke-width:1.4px;

Quick start

MCP Registry metadata

This package exposes a local stdio MCP server as io.github.MerakOsiris/memoryguard. Registry metadata is kept in server.json, and the marker above ships with the PyPI package README. Releases are published through GitHub OIDC to PyPI and the official MCP Registry. Verify the current package version and the Registry entry's active/latest state through their live public records.

1. Install

python -m pip install agent-memguard

For the desktop governance console:

python -m pip install "agent-memguard[gui]"

2. Authorize the current project

memoryguard source add .

3. Connect or repair your coding agent

Global provider configuration is rebuilt from the real binding in the canonical user data home. The command is idempotent and removes superseded MemoryGuard project-level overrides after a successful global takeover.

# Repair one provider
memoryguard provider repair claude
memoryguard provider repair codex
memoryguard provider repair cursor
memoryguard provider repair trae

# Repair every detected provider
memoryguard provider repair all

Restart the host after installation, then verify the integration:

memoryguard doctor
memoryguard mcp-status
memoryguard hooks status --provider all

Launch the desktop console:

memoryguard gui

memoryguard-gui . remains available for desktop shortcuts. A bare memoryguard gui always opens the canonical user-level control directory (default %LOCALAPPDATA%\MemoryGuard on Windows), so running it from a project or from C:\Windows\System32 cannot silently switch databases. MEMORYGUARD_WORKSPACE is an explicit operator override; an explicit memoryguard gui <project-path> or memoryguard gui --workspace <project-path> selects a specific workspace. It does not remember a previously selected project or open a folder picker. On Windows, memoryguard gui detaches the native window from the terminal, so closing PowerShell does not close the GUI.

Provider-specific setup and behavior:

• Claude Code installation
• Codex installation
• Cursor installation

Stable Codex / Router binding

Codex/Router binds MemoryGuard to the stable local Codex program and control installation. An account profile is an endpoint/alias, not a new memory owner: switching profiles automatically discovers or repairs the profile and reuses the verified Agent binding and active group. Request identity remains fail-closed; this does not share records across machines or with arbitrary accounts.

Upgrade

MemoryGuard currently upgrades through Python's package manager:

python -m pip install --upgrade agent-memguard
memoryguard --version
memoryguard doctor

If you installed the GUI extra, keep it during the upgrade:

python -m pip install --upgrade "agent-memguard[gui]"

There is no package self-update command. The package manager is the authoritative package-upgrade path; memoryguard upgrade below is the explicit workspace migration flow, not a package updater.

Upgrade an existing V1 data home

Upgrade the package, then run the verified migration. No workspace, data-home, apply, or confirmation arguments are required for the normal user-level data home:

python -m pip install --upgrade agent-memguard
memoryguard --version                    # confirms installed version
memoryguard upgrade
memoryguard doctor

The command prepares V2, validates the frozen and live source evidence, migrates Agent/Group control, activates only after all gates pass, and removes only the backup batch belonging to that successful migration. Re-running it on V2_ACTIVE is idempotent. For a zero-write report, use:

memoryguard upgrade --preview

Advanced explicit workspace/data-home options remain available for operators managing an isolated installation. A failed gate stays non-active and preserves its evidence; successful activation does not keep a redundant migration backup.

Existing pre-V2 workspaces: explicit V2 cutover

v0.6.0 never auto-activates an existing workspace. Upgrade the package first, then use the packaged operator CLI:

# Read-only manifest status
memoryguard-v2 status -w .

# Build a frozen-source V2 shadow and stop at V2_READY
memoryguard-v2 prepare -w . --apply

# Activate only after the prepare result is V2_READY / ready=true
memoryguard-v2 activate -w . --confirm V2_ACTIVE

The prepare step uses coherent SQLite online backups, preserves V1 and migration-backups, and rechecks live-source drift before READY. Activation performs another fresh drift check before changing the manifest. Do not delete legacy V1 data or migration backups as part of the upgrade.

Knowledge Library

The desktop console can turn a selected folder or file set into one governed local knowledge library. Source files remain where they are; MemoryGuard stores the searchable index in its user data home instead of copying a runtime database into every source project. Knowledge metadata never becomes a second source-body store.

Capability	Current behavior
File/folder ingestion	Add a folder as a book or selected files as documents
Structure	Parse documents, preserve chapter/section context, and create traceable chunks
Retrieval	Full-text search, optional embeddings, and a layered knowledge graph
Natural synchronization	Re-ingest changed files; a partial or failed scan does not silently remove previously indexed content
Lifecycle	Move a book to the library trash, restore it, or explicitly purge its recovery snapshot
Memory candidates	Preview evidence-backed candidates before accepting them into governed long-term memory

Open the desktop console and choose Knowledge Library. Remote embedding or model-backed indexing is opt-in and requires explicit authorization; local full-text retrieval remains available without sending source text to a remote provider. Background imports, re-ingests, and smart rebuilds have durable task receipts: retrying the same request reuses its task, while reusing that key for a different request is rejected. A live task for a different request reports busy rather than claiming that work was accepted.

CodeGraph refresh

The first CodeGraph build is an explicit, confirmed full build. After a scope has been built, each successful trusted file write can trigger an incremental refresh for that scope, subject to strict source-path and active-binding validation. Unchanged content hashes are a no-op; deleted files are retired; the next context receives one bounded affected receipt. MemoryGuard does not run a daemon or watcher for this path and does not infer paths from shell or free-form text. A projectless MCP caller first builds an already-bound directory source, then passes its codegraph_source_id to select that exact scope for query, status, update, and graph reads.

Desktop console surfaces

The GUI has eight visible navigation entries: seven governance pages plus a separate Token usage-and-savings view:

1. Governance Overview
2. Data Sources & Agents
3. Memory Core
4. CodeGraph
5. Rules & Habits
6. Conversation History
7. Risk Signals & Governance Console
8. Token Usage & Savings (separate from the seven governance pages)

Agent lists use readable program/provider names; the underlying ID remains available in the detail view. Empty data is shown as an explicit empty state.

Write and governance lifecycle

%%{init: {"theme":"base","themeVariables":{"background":"#071521","fontFamily":"Arial, sans-serif","fontSize":"14px","primaryTextColor":"#EEF4F8","lineColor":"#557287","edgeLabelBackground":"#071521","clusterBkg":"#0A1A29","clusterBorder":"#27445A"},"flowchart":{"htmlLabels":true,"curve":"basis","nodeSpacing":30,"rankSpacing":42,"padding":14}}}%%
flowchart TD
    subgraph Intake["01 · INTAKE    "]
        direction LR
        Write(["Memory write    "]):::entry
        Scope["Resolve identity<br/>scope · audience&nbsp;&nbsp;&nbsp;&nbsp;"]:::core
        Validate{"Authorized?&nbsp;&nbsp;&nbsp;&nbsp;"}:::decision
        Reject["Reject<br/>no persistence&nbsp;&nbsp;&nbsp;&nbsp;"]:::danger
        Write --> Scope --> Validate
        Validate -- NO --> Reject
    end

    subgraph Organize["02 · ORGANIZE&nbsp;&nbsp;&nbsp;&nbsp;"]
        direction TB
        Secret{"Sensitive?&nbsp;&nbsp;&nbsp;&nbsp;"}:::decision
        Quarantine["Quarantine<br/>outside active set&nbsp;&nbsp;&nbsp;&nbsp;"]:::danger
        Compare["Classify · compare<br/>governed records&nbsp;&nbsp;&nbsp;&nbsp;"]:::active
        Relation{"Relationship&nbsp;&nbsp;&nbsp;&nbsp;"}:::decision
        New["NEW<br/>create active record&nbsp;&nbsp;&nbsp;&nbsp;"]:::result
        Duplicate["DUPLICATE<br/>merge provenance&nbsp;&nbsp;&nbsp;&nbsp;"]:::result
        Correction["CORRECTION<br/>supersede old record&nbsp;&nbsp;&nbsp;&nbsp;"]:::rule
        Conflict["CONFLICT<br/>preserve both sides&nbsp;&nbsp;&nbsp;&nbsp;"]:::danger

        Secret -- YES --> Quarantine
        Secret -- NO --> Compare --> Relation
        Relation --> New
        Relation --> Duplicate
        Relation --> Correction
        Relation --> Conflict
    end

    subgraph Govern["03 · GOVERN&nbsp;&nbsp;&nbsp;&nbsp;"]
        direction LR
        Receipt[("Evidence event<br/>version receipt&nbsp;&nbsp;&nbsp;&nbsp;")]:::store
        Review["CLI or desktop review&nbsp;&nbsp;&nbsp;&nbsp;"]:::surface
        Action["Correct · merge<br/>restore · delete&nbsp;&nbsp;&nbsp;&nbsp;"]:::rule
        Snapshot["Reversible<br/>snapshot&nbsp;&nbsp;&nbsp;&nbsp;"]:::active
        Receipt --> Review --> Action --> Snapshot
    end

    Validate -- YES --> Secret
    Quarantine --> Receipt
    New --> Receipt
    Duplicate --> Receipt
    Correction --> Receipt
    Conflict --> Receipt

    classDef entry fill:#EEF4F8,stroke:#38D5C8,color:#071521,stroke-width:2.4px;
    classDef core fill:#12243A,stroke:#557287,color:#EEF4F8,stroke-width:1.5px;
    classDef decision fill:#0D3338,stroke:#38D5C8,color:#EEF4F8,stroke-width:2px;
    classDef active fill:#0D383A,stroke:#38D5C8,color:#EEF4F8,stroke-width:2px;
    classDef result fill:#12243A,stroke:#38D5C8,color:#EEF4F8,stroke-width:1.6px;
    classDef rule fill:#3B2C18,stroke:#F3B562,color:#EEF4F8,stroke-width:1.8px;
    classDef danger fill:#3A2028,stroke:#EA6A6A,color:#EEF4F8,stroke-width:1.8px;
    classDef store fill:#0B1624,stroke:#7F96A8,color:#EEF4F8,stroke-width:1.4px;
    classDef surface fill:#EEF4F8,stroke:#38D5C8,color:#071521,stroke-width:2px;

    style Intake fill:#081827,stroke:#27445A,stroke-width:1px,color:#EEF4F8
    style Organize fill:#081827,stroke:#27445A,stroke-width:1px,color:#EEF4F8
    style Govern fill:#081827,stroke:#27445A,stroke-width:1px,color:#EEF4F8
    linkStyle default stroke:#557287,stroke-width:1.4px;

The console is not an approval queue. Agents keep moving. MemoryGuard records the outcome and exposes the evidence needed to correct it later.

What you can govern

Signal	Governance action
Duplicate or stale memory	Inspect the canonical record and supersede chain; restore an earlier version when needed
Conflicting memories	Keep both visible until the conflict is resolved deliberately
Secrets, tokens, or credentials	Quarantine the record so it cannot enter active shared memory
Incorrect automatic organization	Correct, merge, lock, restore, or roll back with evidence
Multiple coding agents	Bind agents to one shared group while preserving source identity and scope
Mandatory rules	Assign rules to an Agent, project, provider, runtime role, or shared group