Skip to main content
Glama
README.md
# ctx-memory

Persistent memory for LLM coding agents — Claude Code, Codex, Gemini CLI, OpenCode.

When you start a new session, the agent already knows what you worked on last time: decisions made, files touched, errors hit, conventions learned. No cloud. No telemetry. Everything lives in a local SQLite database at `~/.ctx-memory/store.db`.

## How it works

```
Session starts
      │
 Shell wrapper intercepts 'claude' (or codex/gemini/opencode)
      │
 MCP server starts alongside — injects prior context, exposes memory tools
      │
 During session: hooks fire on every tool call, messages buffered
      │
 Session ends (clean exit / Ctrl-C / crash)
      │
 Layer 1 → Layer 2 → Layer 3 pipeline runs
      │
      ├── Layer 1: extract weighted messages, events, decisions, errors, keywords
      ├── Layer 2: compress to ≤500-token digest, store in DB
      └── Layer 3: merge digest into project memory doc (markdown)

Next session: agent reads prior context automatically
```

## Install

```bash
npm install -g ctx-memory
ctx-memory setup
```

The setup wizard:
1. Detects which tools are installed (`claude`, `codex`, `gemini`, `opencode`)
2. Asks which ones to integrate
3. Writes hook configs for each tool
4. Creates wrapper symlinks in `~/.ctx-memory/bin/`
5. Adds `~/.ctx-memory/bin` to your PATH via `~/.bashrc` / `~/.zshrc`

Restart your shell (or `source ~/.bashrc`), then use your tools as normal — memory is automatic.

## Commands

```bash
ctx-memory setup                        # interactive setup wizard
ctx-memory status                       # show configuration and stats
ctx-memory projects list                # list all projects
ctx-memory projects show <name>         # print full memory doc for a project
ctx-memory projects forget <name>       # reset memory (keeps sessions)
ctx-memory projects forget <name> --hard  # delete all sessions + data
```

## MCP server

The MCP server runs as a sidecar alongside each tool session and exposes six tools:

| Tool | Description |
|---|---|
| `store_message` | Buffer a conversation message for processing at session end |
| `store_event` | Record a tool call event (file edit, bash command, etc.) |
| `search_context` | Search past sessions by semantic similarity or keywords |
| `get_project_memory` | Return the full project memory doc |
| `list_sessions` | List recent sessions with goals and outcomes |
| `end_session` | Finalize a session and run the Layer 1 → Layer 2 → Layer 3 pipeline |

To use the MCP server standalone with Claude Code, add to `~/.claude/settings.json`:

```json
{
  "mcpServers": {
    "ctx-memory": {
      "command": "node",
      "args": ["/path/to/ctx-memory/dist/src/mcp/index.js"]
    }
  }
}
```

## Architecture

```
src/
  cli/        — setup wizard, status, projects commands
  db/         — SQLite schema + CRUD (projects, sessions, events, digests, memory)
  layer1/     — pure message/event processing → weighted Layer1Output
  layer2/     — digest compression to ≤500 tokens → Layer2Digest
  layer3/     — merge digest into ProjectMemory markdown
  mcp/        — MCP server (handlers + stdio entry point)
  wrapper/    — shell wrapper (intercepts tool invocation, manages session lifecycle)
  hooks/      — hook config writers for Claude / Gemini / OpenCode
```

**Key constraints:**
- All Layer 1/2/3 functions are pure — no I/O, never throw
- Digests stay under 500 tokens
- Vector search uses all-MiniLM-L6-v2 embeddings via `sqlite-vec` (384-dim)
- Single SQLite DB, WAL mode, foreign keys on

## Development

```bash
npm run build       # tsc → dist/
npm run dev         # tsc --watch
npm run test:run    # vitest (single-shot, 476+ tests)
npm test            # vitest (watch mode)
```

DB path defaults to `~/.ctx-memory/store.db`. Override with `CTX_MEMORY_DB_PATH`.

## License

MIT

TDQS

B3.3/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: session lifecycle (end_session), memory retrieval (get_project_memory, list_sessions, search_context), and data recording (store_event, store_message). No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, e.g., end_session, get_project_memory, store_event. The naming is predictable and uniform.

Tool Count5/5

With 6 tools, the server covers core memory management operations without bloat. The count is well-scoped for the domain of session context and project memory.

Completeness5/5

The tool surface covers the full typical lifecycle: recording events/messages, searching and retrieving context, listing sessions, and finalizing sessions with memory updates. No obvious gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues