@amaster.ai/pi-memory
Pi extension providing persistent curated memory (MEMORY.md + USER.md) injected into the system prompt as a frozen snapshot.
Package details
Install @amaster.ai/pi-memory from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:@amaster.ai/pi-memory- Package
@amaster.ai/pi-memory- Version
0.1.29- Published
- Oct 20, 2026
- Downloads
- 3,514/mo · 481/wk
- Author
- qianchuan
- License
- Apache-2.0
- Types
- extension
- Size
- 1.8 MB
- Dependencies
- 2 dependencies · 4 peers
Pi manifest JSON
{
"image": "https://raw.githubusercontent.com/TGYD-helige/pi/master/packages/pi-memory/preview.png",
"extensions": [
"./dist/index.js"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
@amaster.ai/pi-memory

Persistent curated memory for pi agents — MEMORY.md (the agent's own notes) and USER.md (what the agent knows about the user). The extension loads both files at session start and injects a sanitized snapshot into the system prompt. Writes are durable on disk immediately and visible through memory_read right away; the system-prompt snapshot refreshes after successful context compaction or in a new session.
Modeled after hermes' default MemoryStore mechanism (no provider/manager abstraction).
Storage
- Location:
<agentDir>/memories/MEMORY.mdand<agentDir>/memories/USER.md - Entries separated by
\n§\n - Atomic writes via temp-file + rename
- Read-modify-write protected by
proper-lockfile - Drift detection: if the on-disk file contains content that wouldn't round-trip through the parser/serializer (or any single entry exceeds the per-store char limit), the mutation is refused and a
.bak.<unix-ts>snapshot is taken for the user to recover from.
Safety
Every write — and every system-prompt snapshot build — runs the content through the bundled threat-patterns scanner at the strict scope. Patterns cover prompt injection, role hijack, C2 framework names, exfiltration, persistence (SSH backdoor, agent-config edits), and invisible unicode.
| Action | On match |
|---|---|
memory_add / memory_replace |
Reject with the matched pattern id; live state and disk unchanged. |
| Snapshot build (load) | Replace the entry with [BLOCKED: <filename> entry contained threat pattern(s): <ids>...]. The poisoned content never enters the system prompt. Live state keeps the original so memory_read / memory_remove can recover. |
Tools
Four LLM-callable tools (separate, not action-multiplexed):
| Tool | Purpose |
|---|---|
memory_add |
Append a new entry. Exact duplicates are successful no-ops; empty, over-limit, and threat content is rejected. |
memory_replace |
Update an existing entry by short unique substring (oldText). |
memory_remove |
Delete an entry by short unique substring (oldText). |
memory_read |
Return live entries, count, and <percent>% — <chars>/<limit> usage string. |
target is 'memory' (the agent's own notes) or 'user' (user profile facts).
Defaults
| Store | Char limit |
|---|---|
| MEMORY | 2200 |
| USER | 1375 |
These are total chars after §-joining all entries. The limit is enforced at write time, and at load time as a drift signal (single-entry overflow).
Integration Modes
Mode 1: Extension auto-discovery (standalone / CLI)
When installed as a dependency with the pi.extensions field declared in package.json, the runtime auto-discovers and loads the extension. The extension creates its own MemoryStore with file-based storage at <agentDir>/memories/ — fully self-contained.
pi.extensions → session_start → initialize store → register tools
→ before_agent_start → append frozen snapshot to systemPrompt
→ session_compact → reload MEMORY.md/USER.md for the next agent run
→ session_shutdown → release
- Storage:
<agentDir>/memories/MEMORY.mdand<agentDir>/memories/USER.md - Lifecycle: capture a fresh system-prompt snapshot for new and forked sessions, restore it on resume or reload, and refresh it after successful compaction
- Status command:
/memory statusshows entry counts per file - LLM tools:
memory_add,memory_replace,memory_remove,memory_read
Configure via the pi-memory settings key:
Project .pi/settings.json values are loaded only after project trust is accepted and are not environment-interpolated. User and agent settings retain environment interpolation.
{
"pi-memory": {
"dataDir": "/custom/memory/path",
"memoryCharLimit": 4000,
"userCharLimit": 2000
}
}
Mode 2: Dependency import (host-controlled)
When the host process owns the MemoryStore (e.g. shared across agents, test fixtures, custom storage path), construct the store yourself and register tools directly:
import { MemoryStore, createMemoryTools } from "@amaster.ai/pi-memory";
const store = new MemoryStore({
dir: "/var/lib/pi/agent-42/memories",
memoryCharLimit: 4000,
});
await store.loadFromDisk();
// ToolDefinition[] — wire into your tool registry directly
const tools = createMemoryTools(store);
// System prompt fragment (rebuilt by loadFromDisk; freeze it for the session)
const promptBlock = store.formatAllForSystemPrompt();
You can also pass a pre-built store into the extension via injectedConfig to keep the extension lifecycle but use your own storage:
import memoryExtension from "@amaster.ai/pi-memory";
memoryExtension(pi, { store });
Drift recovery
If memory_add / memory_replace / memory_remove returns success: false with driftBackup: ".../MEMORY.md.bak.<ts>", the on-disk file no longer round-trips through the parser. This usually means a patch tool / shell append / manual edit / concurrent session wrote raw content that broke the §-delimited structure.
To recover:
- Open the
.bak.<ts>snapshot and identify content not yet captured as clean entries. - Add each missing entry via
memory_add. - Either delete the original
MEMORY.md(the next add will recreate it) or rewrite it as a clean§-delimited list.
The drift guard exists to prevent silent data loss — never bypass it by deleting .bak.<ts> snapshots blindly.
Prompt snapshot
loadFromDisk() refreshes live entries from disk and rebuilds the sanitized system-prompt block. A new or forked session captures that block and persists it in the Pi session; resume and reload restore a saved block after validating it again. Invalid saved blocks fall back to a newly sanitized disk snapshot. The same bytes are reused across agent runs until successful context compaction, while session-tree navigation selects the snapshot saved on that branch. Subsequent add / replace / remove calls update live state and disk, but not the frozen prompt snapshot. Why:
- Reusing the same system prompt preserves the provider's prefix-cache opportunity across agent runs in the session.
- Tool responses always reflect live state, so the model still sees its own writes — just via tool-result tail, not system-prompt head.
- The prompt snapshot picks up changes after successful
session_compactor in a new session. A changed snapshot can still cause a cache miss at that boundary.
The extension bounds very large prompt snapshots when capturing them and reserves space for both files when both are present; the memory files and tool reads retain their full content.
Lifecycle reference
| Hook | Behavior |
|---|---|
session_start |
Resolve dataDir, build MemoryStore, loadFromDisk(), capture a fresh snapshot for new/forked sessions or restore the saved one, register 4 tools, set status memory: loaded/memory: empty, and start a gated background dream. |
before_agent_start |
Append the frozen snapshot to assembled systemPrompt (guidance only when empty). |
session_compact |
Reload memory from disk and persist a changed snapshot for the next agent run. |
session_tree |
Select the snapshot saved on the newly active branch. |
session_shutdown |
Drop store references. |
Dreaming (Background Memory Consolidation)
On session start, pi-memory checks whether enough Pi session history has accumulated and, when due, starts an isolated background agent that consolidates durable facts into memory. The default global memory store reads Pi sessions across all projects; an injected store or custom dataDir reads only the active session directory. It does not add a turn to the active conversation or install an operating-system scheduled task.
How it works
Session-start trigger — The extension launches the check asynchronously after memory initialization, so the active session is not blocked.
Gate and lock — Each run checks whether enough time and turns have elapsed, then takes a cross-process lock so multiple Pi hosts cannot dream concurrently.
Consolidation — An agentic loop (using pi-agent-core) reviews recent Pi sessions and updates
MEMORY.md/USER.mdvia the memory tools. Follows a 4-phase prompt: Orient → Gather recent signal → Consolidate → Verify and report.
Configuration
Add to settings.json under the pi-memory key:
{
"pi-memory": {
"dreaming": {
"enabled": true,
"minHoursSinceLastRun": 24,
"minTurnsSinceLastRun": 5,
"model": {
"provider": "openai",
"model": "gpt-4.1-mini"
}
}
}
}
All fields are optional with sensible defaults. The model field accepts any provider/model pair configured in your ~/.pi/agent/models.json (built-in or custom). minSessionsSinceLastRun is accepted as a deprecated alias for minTurnsSinceLastRun.
Set "enabled": false to disable background dreaming.
Dreaming is opportunistic: it runs while a Pi host is active and catches up on the next session start. It does not run while every Pi host is closed.
Structured results (Pi 0.99+)
memory_read, memory_add, memory_replace, and memory_remove declare outputSchema and return their live store results as structuredContent. Codemode receives entries and usage directly; writes also expose success, target, and entryCount. Failed writes set isError: true and preserve available error, matches, currentEntries, usage, and drift-remediation fields. Entry text remains the existing substring reference used by replace/remove; no new entry-ID format is introduced.
const result = await tools.memory_read({ target: "memory" });
if (result.error || result.truncated) throw new Error("Read a complete memory result before updating");
const entry = result.entries.find(e => e.includes("TypeScript"));
if (entry) text(await tools.memory_replace({ target: "memory", oldText: entry, newContent: "Project uses strict TypeScript" }));
Structured output is limited to 12 KiB and top-level lists to 100 complete records. truncated: true indicates omitted records; total retains the original count where available. Oversized records with an id retain that complete ID and small scalar metadata, omit large fields, and carry truncated: true both on the record and envelope; callers must check that flag before reusing content for an update. Oversized results without a record ID return a typed output-limit error instead of clipped paths or content. A write may already have completed when that happens: inspect saved state before retrying. Readable text and renderer details are independently bounded.