pi-total-recall

extensionmaintained

Complete context stack for pi — persistent memory, session history search, and local knowledge search in one install.

by — · v1.9.0 · published 2d ago

$ pi install npm:pi-total-recall
downloads/mo
859
stars
82
last push
2d ago
open issues
0

Signals

license: MITtestspi manifest: missinginstall size: —deps: 0peer deps: 0

Download trend

No downloads in the last 12 weeks.

README

pi-total-recall

Complete context stack for pi. One install gives your agent persistent memory, session history, and local knowledge search.

What's included

LayerPackageBundled versionWhat it does
Memory@samfp/pi-memory1.6.0Learns preferences, project patterns, and corrections. Injects relevant facts into every session.
Session historypi-session-search1.6.0Indexes past coding sessions. Search by topic to find previous work, decisions, and debugging context.
Knowledge basepi-knowledge-search1.3.7Indexes local files (markdown, text, docs). Semantic search over your notes, documentation, and vault.

The components are bundled into the tarball, so one install pins a tested set. A scheduled workflow publishes a new patch release whenever a component ships a newer compatible version.

Together, these give pi three layers of context about you:

  • What you prefer — coding style, tool choices, project conventions (memory)
  • What you've done — past sessions, debugging history, previous decisions (session search)
  • What you know — notes, docs, research, reference material (knowledge search)

Install

pi install npm:pi-total-recall

That's it. All three extensions, and the session-search skill, are active immediately. Installing from git works too: pi install git:github.com/samfoy/pi-total-recall.

Requires Node 22.19+ (pi's own floor). pi-session-search and pi-knowledge-search use SQLite FTS5 via node:sqlite, which Node 22.19+ and every Node 24 release ship. On an older Node the components stop at startup with an error that names the problem — upgrade Node and restart pi.

Tools

After installing, your agent gets these tools:

Memory

ToolDescription
memory_searchSearch stored facts and preferences
memory_rememberStore a fact or lesson
memory_forgetRemove a stored fact or lesson
memory_lessonsList learned corrections
memory_statsShow memory statistics

Session History

ToolDescription
session_searchSemantic search over past sessions
session_listBrowse sessions by date, project, or status
session_readRead the full conversation from a past session

Knowledge Search

ToolDescription
knowledge_searchSemantic search over local files
kb_readRead an indexed note by name, relative path, or [[wikilink]]

Configuration

Each component has its own configuration. See the individual package READMEs for details:

Memory

{
  "memory": {
    "lessonInjection": "selective"
  }
}

Knowledge Search

Run /knowledge-search-setup inside pi, or point it at your notes in ~/.pi/knowledge-search.json:

{
  "dirs": ["~/Documents/Notes"]
}

Session History

Works out of the box — indexes your existing pi sessions automatically.

Project-local storage

By default, all three components write to user-global locations under ~/.pi/ — which is usually what you want, because memory, sessions, and a notes index are normally global across projects.

If you want a project's memory/index to be isolated — e.g. a throwaway prototype, a client repo, or an experimental agent setup — drop a pi-total-recall.localPath key into {project}/.pi/settings.json:

{
  "pi-total-recall": {
    "localPath": ".pi/total-recall"
  }
}

Path resolution: relative paths are resolved against the project root (where you run pi), not the .pi/ directory. So ".pi/total-recall" above resolves to {project}/.pi/total-recall/, and "./data" would resolve to {project}/data/. Use an absolute path (e.g. "/Users/you/shared-index") if you want to pin outside the project.

The key is case-sensitive (localPath, lowercase l). A misspelled key like LocalPath is ignored, and the bundled components (@samfp/pi-memory 1.6.0, pi-session-search 1.6.0 and pi-knowledge-search 1.3.7, or later) each log a console.error warning naming it, e.g. pi-memory: ignoring unknown key(s) in settings.json "pi-total-recall" block: LocalPath (expected: localPath).

That single key cascades to all three packages:

PackageCascaded path
@samfp/pi-memory{project}/.pi/total-recall/memory/memory.db
pi-session-search{project}/.pi/total-recall/session-search/
pi-knowledge-search{project}/.pi/total-recall/knowledge-search/

You can also override any single package independently — package-specific keys win over the cascade:

{
  "pi-total-recall": { "localPath": ".pi/total-recall" },
  "pi-knowledge-search": {
    "localPath": "/some/other/path"   // overrides just this one
  }
}

Resolution order (highest priority first) for every package:

  1. Package-specific env vars (KNOWLEDGE_SEARCH_CONFIG, etc.)
  2. pi-<package>.localPath in {cwd}/.pi/settings.json
  3. pi-total-recall.localPath cascade
  4. Global default under ~/.pi/

Caveat: session-search source stays global

pi-session-search relocates only its own config and index — the session source directories (~/.pi/agent/sessions, ~/.pi/agent/sessions-archive) are pi's own files and remain global. That's where pi writes sessions, so making them project-local would point the tool at an empty directory. Use the project filter on session_search and session_list if you want to scope results to one project.

Cleanup

When using pi-total-recall.localPath:

rm -rf {project}/.pi/total-recall   # nukes memory, session-search config+index, knowledge-search config+index

Individual packages

If you only want one or two components, install them directly:

pi install npm:@samfp/pi-memory
pi install npm:pi-session-search
pi install npm:pi-knowledge-search

Releasing

.github/workflows/publish.yml publishes through npm trusted publishing. Its publish job runs only in a run started on the vX.Y.Z tag it publishes, so npm's provenance names the tagged commit, and it refuses a tag that doesn't match the version in package.json.

  • Automatic: the daily run bumps the bundled components when one has a newer compatible release, pushes the patch release's commit and tag to main, and dispatches the workflow on that tag.
  • By hand: push a commit that sets version and adds its CHANGELOG entry, tag it vX.Y.Z, and publish a GitHub release for the tag. Pre-releases don't publish.
  • Retry: if a publish fails, gh workflow run publish.yml --ref vX.Y.Z runs it again on that tag. It works for tags that contain this workflow (v1.9.0 onward); npm refuses a version it already has.

License

MIT