AI コーディングエージェント向けの開発者コンテキスト＆セマンティックメモリマネージャー。
Claude Code、Codex、Cursor には、毎セッション同じことを説明していますよね。つまり、このプロジェクトが何か、なぜキューが Redis ではなく NATS なのか、コミット前に rustfmt で整形すること、そして昨夜どこで中断したのか。ContextD はそれを一度だけ保存します — プロジェクトをまたいで、エージェントをまたいで。そして、CLI と MCP サーバーを通じて、今取り組んでいるタスクに関係する部分だけを返します。
Claude Code ─┐
Codex ───────┤
Cursor ──────┼── MCP ── ContextD ── SQLite + FTS5 + embeddings
other agents ┘すべてを保存し、必要なものだけを注入する。 1 年分のメモリはコンテキストウィンドウには収まりません。検索はハイブリッド（全文 + ベクトル）で、ランク付けされ、明示的なトークン予算に詰め込まれます。収まらなかった分はカウントされ、黙って破棄されることはありません。
現在の真実は、過去の真実と区別できなければならない。 タスクキューが Redis → PostgreSQL → NATS と移り変わったとき、エージェントには NATS と伝えなければなりません。たまたま最も言及されることが多い選択肢ではなく。置き換え済みのメモリは内容を保持したまま検索可能ですが、マークされ、ランキングでペナルティを受け、明示的に求められない限り取得から除外されます。
Related MCP server: ContextAtlas
uv tool install contextd # puts `contextd` on your PATH
contextd --versionuv は、コンパイル済みバイナリを含む公開済み wheel をインストールします — ランタイムに Rust ツールチェーンも Python も不要です。その後 contextd が見つからない場合は、uv tool update-shell を実行し（uv は ~/.local/bin にインストールします）、新しいシェルを開いてください。インストールせずに試すには: uvx contextd status。
チェックアウトからのビルド、または未リリースの変更を実行する場合:
uv tool install . # builds with your Rust toolchain
cargo install --path . # the same thing, straight from cargoSQLite はコンパイル済みです — システムライブラリも Docker も、実行すべきサービスもありません。Linux、macOS、Windows 対応。ソースからのビルドには Rust 1.85+ が必要です。
任意の環境変数:
Variable | Effect |
| メモリの置き場所（デフォルトは |
| 色を無効にします。 |
| CLI と MCP サーバーのログレベル。ログは stderr に出力され、stdout には決して出力されません |
contextd init # create ~/.contextd
cd ~/projects/orbit
contextd attach # detects git, name, agent files
contextd add --category architecture \
"GPU scheduler uses NATS for task transport"
contextd checkpoint "worker heartbeat completed" \
--goal "Implement distributed GPU scheduling" \
--done Coordinator --next "Lease-based GPU allocation" \
--problem "Worker reconnect"
contextd search "scheduler" # keyword search, ranked
contextd recall "which message transport does the scheduler use?"
contextd export claude # writes CLAUDE.md
contextd export codex # writes AGENTS.md
contextd status
contextd mcp serve # speak MCP on stdiocontextd status:
ContextD
─────────────────────────────────
Project Orbit
Branch main @ a1b2c3d (2 dirty)
Memories 124
Decisions 18
Checkpoints 7
Last checkpoint
worker heartbeat completed (2 hours ago)
Current goal
Implement distributed GPU scheduling
Next
- Lease-based GPU allocation
Semantic index ✓ 149/149 local · hashing-v1
Agents claude, codex
MCP ✓ contextd mcp serveCommand | Description |
| ホームディレクトリ、データベース、設定を作成する |
| リポジトリをプロジェクトとして追跡する |
| 件数、git 状態、最新チェックポイント、インデックスの健全性 |
| メモリの CRUD |
| あるメモリが別のメモリを置き換えたことを記録する |
| メモリ、ADR、チェックポイントにわたるキーワード優先の検索 |
| 質問を投げる; ハイブリッドな意味検索 + キーワード検索 |
| 「どこまで進んだか」を保存・復元する |
| アーキテクチャ決定記録 |
| 作業セッションとそれがもたらしたもの |
| 重複を統合し、履歴をマークし、インデックスを再構築する |
| Markdown ミラーと束縛されたエージェントファイルを書き出す |
| コンテキストをエージェントファイルに取り込む／から書き出す |
| メモリを交換するマシンを管理する |
| マシンを調査する: 何を保持しているか、コピーはしない |
| このマシンに対する同じ調査 |
| SSH 経由でレコード単位にメモリを同期する |
| 同じ交換を JSON ファイルとして行う |
| MCP サーバーを実行する; ツールを一覧する |
| パスと設定を表示する; |
すべてのコマンドは、スクリプト用の --json、別のプロジェクトに作用させるための --project <name>、そして別のストアを指すための --home <dir>（または $CONTEXTD_HOME）を受け付けます。
contextd mcp serve # newline-delimited JSON-RPC on stdio
contextd mcp serve --read-only任意の MCP クライアントに登録できます — Claude Code の場合:
claude mcp add contextd -- contextd mcp serve公開されるツール:
Tool | 用途 |
| セッション開始時のコンテキスト、トークン予算に収まる |
| 記憶から質問に答える（ハイブリッド取得） |
| キーワード優先の検索 |
| 1 件のメモリを完全な形で取得する |
| 件数、ブランチ、インデックス状態 |
| 現在の目標、完了、次、未解決の問題 |
| 現在も有効な決定 |
| どのエージェントがいつ作業し、どんな結果を残したか |
| 書き込み（ |
結果はライフサイクル状態を持ち、置き換えられたものには NOT current と明記されるため、モデルが履歴を現在の設計と取り違えることはありません。
ラップトップとワークステーションでの作業は、かつては 2 つの不連続なメモリを持つことを意味していました。ContextD はファイルではなくレコードを交換します:
contextd remote scan dev@lab-box # what does that account hold?
contextd remote add lab dev@lab-box # a Host alias from ~/.ssh/config works too
contextd remote pull lab # bring their memory here
contextd remote push lab # send yours there
contextd remote pull lab --dry-run # see what would change firstremote scan は、何かにコミットする前にアカウントを調査します。コンテンツではなく件数を報告し、そのため、マシンが何を持っているかを調べるのに、メモリ全体ではなく数キロバイトの通信で済みます。さらに、依然 as まだ設定されていないリモートの宛先でも動作します:
$ contextd remote scan lab
lab-box contextd 0.1.0
─────────────────────────────────
Home /home/dev/.contextd
Memories 124 (118 current, 6 superseded)
Decisions 18
Checkpoints 7
Last activity 2 hours ago
Embeddings openai · bge-m3 · vectors in qdrant
project mem adr ckpt last activity last checkpoint
Orbit 80 12 5 2 hours ago worker heartbeat completed
Sable 38 6 2 3 weeks ago parser rewrite landed
plus 6 global memories, applying to every project: 4 convention, 2 user
Nothing was copied. `contextd remote pull lab` merges it here.--detail は、プロジェクトごとのカテゴリ内訳を追加します。contextd inventory は同じ調査をローカルで実行します。アカウントは SSH でログインするもので、ホームディレクトリはそのマシン上で解決されます($Ptitle...)、なければ ~/.contextd) — 別の場所にある場合は --remote-home` を渡してください。
ターミナルから実行すれば、ssh が通常どおり尋ねてきます:
$ contextd remote scan dev@lab-box
dev@lab-box's password:パスワードのプロンプト、ホストキーの確認、2FA はすべて機能します。ssh がそれらをターミナルから直接読み取るためです。各コマンドは自分で判断します: ターミナルがあれば ssh がプロンプトを表示し、ターミナルがない場合 — cron、パイプライン、MCP サーバー — は BatchMode=yes を渡し、鍵が見つからない場合に誰も応答しないプロンプトでハングする代わりに即座に失敗します。--interactive または --batch のどちらかに強制できます。
ssh host command は、非対話的で非ログインの shell を実行し、標準的な ~/.bashrc はその場で先に戻ってしまいます — ~/.local/bin や ~/.cargo/bin を PATH に追加する行よりも前に。そのため、contextd 遠隔側にインストールされ動作していても「not 見つからない」ことがあります。どのケースに当てはまるかは:
ssh you@host 'command -v contextd' # nothing? not installed
ssh you@host 'bash -lc "command -v contextd"' # found? a PATH problemどちらの修正も機能します:
contextd remote add lab you@host --login-shell # read ~/.profile first
contextd remote add lab you@host --command '~/.local/bin/contextd'クォートに注意してください。クォートがないと、自分のシェルが ~ を ContextD ディレクトで展開して、リモートには この マシンから取り出したパスが設定されます。二つのアカウントのホームディレクトリが異なる場合に知っておく価値があります。忘れてしまえば ContextD がどに知らせます。
クォート付きの ~/ または $HOME/ パスは、ここではなくリモート側で展開されます。さらに、バナーを出力するログインシェルでも、何も壊れません — JSON ペイロードは出力から拾い出されます。
各コマンドは独自の接続を開くため、scan の後に pull と 2 回尋ねられます。それを止める方法が 2 つあります:
ssh-copy-id dev@lab-box # key-based auth, asked once, ever
# or reuse one authenticated connection for a few minutes
contextd remote add lab dev@lab-box \
--ssh-option=-o --ssh-option=ControlMaster=auto \
--ssh-option=-o --ssh-option=ControlPath=~/.ssh/cm-%r@%h:%p \
--ssh-option=-o --ssh-option=ControlPersist=5mpull は、SSH 越しにリモートで contextd bundle export を実行し、帰ってきたものをマージします。マージは UUID に基づくので:
2 回目の実行では2回目にしても何も変更されない;
両方にレコードが存在するときは、新しい updated_at が勝つ;
両方の側で変更されていたら、ローカルコピーがに保持され、分岐は競合として静かに解決するのではなくリストされる;
supersede リンクも伝搬するので、片方のマシンで閉じた履歴はもう片方でも閉じたまま;
削除も伝搬します — — ラップトップで削除されたメモリはデスクトップからも削除され、そのどちらからでも3台目のマシンへも届きます。
contextd delete は、tombstone — レコードが削除された日時 — を記録し、その記録は他のレコードと同じように同期されます。これがなければ、まだメモリを持っていたマシンからの次の同期で、親切にも取り出されて引き渡されてしまいます。
削除にもタイムスタンプを持つ decision として扱うため、どのような場合でも常に最新の意思が優先されます:
状況 | 結果 |
一方で削除され、もう一方では未変更 | 他方で削除され、その後の全マシンでも削除されます |
一方で削除され、もう一方でその後編集された | 編集が優先され、レコードが復活し、tombstone は消去されます |
両方で削除された | すべての場所から一度だけ削除されます |
プロジェクト全体を削除する（contextd detach --purge）は、ローカルの掃除です。意図的に同期はされません。一台のマシンが整理したからといて、他台にそのプロジェクトを忘れさせるべきではないからです。
tombstones は sync.tombstone_retention_days（デフォルト 1 年）のあいだ保持し、その後、contextd refresh が忘れます。それより長い間同期していなかったマシンでは、削除されたことを知らされていないレコードが復活し取り込まれることがあります。保持期間を短くするのは、すべてのマシンが頻繁に同期するときだけにしてください。
context の復活を必要とするなら、contextd delete --archiveを推奨します: これで古いに戻せれ、同期され、アーカイブされたメモリはcontextd memories --all` に残りつつ、検索の対象は避けられます。
contextd.db をコピーし合う方式は、意図的に採用されていません: 前回の交換後に両方のマシンが記録を持っている場合、その両方を保存しなければならず、ファイルコピーはどちらか一方しか選べません。
プロジェクトの照合は、マーンズをまたいで、git リモート（SSH と HTTPS URL 形式は同一のリポジトリとして扱われる）そして slug で行われます。他から来たプロジェクトはローカルパスを持っておらず、自分のチェックアウト上で contextd attach を実行すると、同じコードの重複プロジェクトを作るのではなく、それを採用します。
SSH がない？ 同じ交換はファイルを介して行けます:
contextd bundle export --out memory.json # on one machine
contextd bundle import --file memory.json # on the other境界ボードは含まれません — それらは派生されるからです。相手側が違うプロバイダーを使っている場合があり、また pull では通信でかかる時間より早くローカルで再埋め込みされます。
セッションとは、1 つのエージェントがあるプロジェクトで行う 1 連の作業のことです。contextd mcp serve は、クライアントがモデルに接続すると自動的にセッションを開きます — エージェント名は MCP ハンドシェイクから来ます — そして、接続が切れると閉じます。ターミナルから:
contextd session start --agent claude
contextd session end "heartbeat wired up"
contextd session list
contextd session show # what the current or last session produced後 サ ーション open の間に作成されたチェックポイントはそれにリンクされ、記憶と判断は時間ウィンドウによって結び付けられます。それにより「前回は実際に何をしていたのか？」を本当の答えに変えます:
$ contextd session show
Session b506bd93
─────────────────────────────────
agent claude
window 2026-08-24T14:42:21Z → 2026-08-24T15:10:03Z
ran 27m 42s
summary heartbeat wired up
Checkpoints
6e702570 worker heartbeat completed
Memories
069a5f19 [architecture] GPU scheduler uses NATS for task transportプロジェクトごとに開けるセッションは1つだけです。新しいセッションを開始すると直前のセッションは閉じるため、クラッシュしたエージェントは次のエージェントの作業を引き継げません。セッションはこのマシン上のアクティビティを記録するので、常にローカルに留まります。contextd bundleが運ぶのは知識であって、参加記録ではありません。
query → project detection → FTS5 → semantic → ranking → token budget → context候補のスコアは重み付き総和にライフサイクル係数を掛けたものです。
(fts + semantic + priority + recency + project_match) × status_multiplierすべての重みはconfig.tomlに格納され、スコアラーはtrait（search::scoring::Scorer）として実装されているため、検索本体に触れることなく計算式を差し替えられます。contextd search --explainは、ヒットごとの内訳を出力します。
デフォルトのプロバイダーはlocalです。オフラインで動作する特徴ハッシング型エンベッダーで、モデルのダウンロードもネットワークもAPIキーも不要です。語彙の重なりや言い回しを捉えるため、ハイブリッド検索がキーワードだけを上回るには十分ですが、決して共起しない単語同士を関連付けることはできません。
真のパラフレーズ（言い換え）マッチングが必要な場合は、ContextDを任意のOpenAI互換エンドポイント（Ollama、TEI、vLLM、LM Studio、OpenAI自身）に向けてください。bge-m3は良いデフォルトです。多言語対応なので、中国語の質問から英語で書かれたメモを見つけられます。
ollama pull bge-m3
contextd config set embeddings.provider openai
contextd config set embeddings.model bge-m3
contextd config set embeddings.api_base http://localhost:11434/v1
contextd config set embeddings.dimensions 1024
contextd config --check # asks the endpoint for a real vector
contextd refresh --force-embeddings # re-embed with the new modelAPIキーが必要な場合、embeddings.api_key_envに指定された名前の環境変数から読み取られ、設定ファイルやデータベースに書き込まれることはありません。もしprovider = "none"にすると、ベクトルは完全に無効になり、ContextDは全文検索にフォールバックします。
ベクトルの検索は、2つのバックエンドを持つVectorIndexトレイトを通じて行われます。
バックエンド | 使用場面 |
| データベースにすでにあるベクトルに対するコサイン真沖探索。インストール不要で、個人規模なら1ミリ秒未満。 |
| すでにQdrantを運用している場合や、メモリがスキャンしきれない規模にまで大きくなった場合。 |
contextd config set vector.backend qdrant
contextd config set vector.url http://localhost:6333
contextd config set vector.collection contextd
contextd refresh --reindex-vectors # publish existing vectors, no re-embedding
contextd config --checkコレクションは初回使用時に作成され、次元数は埋め込みモデルから決められ、コサイン距離を使用します。幅が合わない既存のコレクション（たとえば384次元モデルをbge-m3の1024次元に切り替えた場合）は、無意味な近傍を生成する代わりに、修正するコマンドとともに報告されます。
どのバックエンドを選んでも、SQLiteがすべてのベクトルの正本を保持しているため、外部インデックスはいつでも再構築できますし、contextd bundleは動作し続け、Qdrantを導入していないマシンでも同じメモリを読み取れます。
ベクトルストアや埋め込みエンドポイントに到達できない場合、検索は全文検索にフォールバックし、その旨を通知します。contextd statusはbackendと応答の有無を表示します。
SQLiteが正本です。Markdownミラーは、メモリを読む、差分を確認する、コミットするという用途で存在します。
~/.contextd/
├── config.toml
├── contextd.db
├── projects/Orbit/
│ ├── overview.md architecture.md decisions.md tasks.md
│ └── checkpoints/
└── global/
├── coding.md git.md preferences.md生成されたコンテンツは、マークされたブロック内に格納されます。
# House rules ← yours, never touched
Never force-push to main.
<!-- contextd:begin -->
...generated context... ← ContextD's
<!-- contextd:end -->ContextDは書き込んだ内容のハッシュを記録します。このときのハッシュからブロックが変更されていると、--forceを渡すまでcontextd exportは拒否し、終了コード非ゼロで終了します。これはMarkdownミラーにも適用され、contextd sync --adoptは手動編集を破棄するのではなく、メモリとして取り込みます。
cli / mcp entry points (thin)
↓
agents per-agent import/export adapters
↓
core projects, memories, checkpoints, context building
↓
search / embeddings retrieval, pluggable providers
↓
storage repository traits + SQLite implementation各レイヤーは、自分の下のレイヤーにのみ依存します。storageより上でSQLiteに言及せず、embeddingsより上でプロバイダー名を挙げず、MCPサーバーはcoreのクライアントとして、CLIとまったく同じです。これにより、計画されている進化（SQLite → FTS → embeddings → semantic memory → MCP）が、ひとつの絡み合ったモジュールにはなりません。
src/
├── cli/ argument parsing, rendering, one module per command group
├── core/ model, project, memory, checkpoint, decision, session, context, refresh
├── storage/ repository traits + sqlite/ (migrations, FTS, vectors)
├── search/ fulltext, semantic, hybrid fusion, scoring, indexer
│ └── vector/ VectorIndex trait, sqlite scan, qdrant client
├── embeddings/ EmbeddingProvider trait, local, openai-compatible
├── agents/ AgentAdapter trait, claude, codex, cursor, generic
├── sync/ agent files, Markdown mirror, bundles, SSH remotes
├── mcp/ JSON-RPC protocol, tools, stdio server
├── config/ config.toml, path resolution
└── ui/ terminal formattingcargo fmt
cargo clippy --all-targets
cargo test # unit + CLI + MCP + migration tests
uv build --wheel # the artefact `uv tool install contextd` shipsCIはLinux、macOS、Windows上で同じ3つのコマンドを実行し、wheelがインストールして動くことを確認します。v*のタグを打つと、各プラットフォームのwheelをビルドし、trusted publishingでPyPIに公開します。
テストは一時的なCONTEXTD_HOMEディレクトリを対象に実行され、実際のメモリストアには一切触れません。
contextd configはパスと現在の設定を出力し、contextd config --tomlはファイルを出力します。主な設定項目は次の通りです。
[context]
max_context_tokens = 6000 # the injection budget
max_memories = 40
[vector]
backend = "sqlite" # or "qdrant"
url = "http://localhost:6333"
collection = "contextd"
[search]
fts_weight = 1.0
semantic_weight = 1.0
priority_weight = 0.35
recency_weight = 0.25
project_weight = 0.5
recency_half_life_days = 90.0
superseded_penalty = 0.35 # how far history is pushed below current truth
[sync]
tombstone_retention_days = 365 # how long deletions keep propagating
[refresh]
duplicate_threshold = 0.9 # at or above this, memories are merged
similar_threshold = 0.65 # at or above this, they are reported
summarizer = "none" # or "openai" to consolidate clusters現在提供中の機能：プロジェクト、メモ、チェックポイント、決定、セッション、FTS5検索、ハイブリッドな意味的呼び出し、コンテキストのバジェット管理、Claude/Codex/Cursor/汎用アダプター、競合検出付きMarkdownミラー、refresh、SSH経由のクロスオーバー、プラガブルな埋め込みプロバイダー（localまたは任意のOpenAI互換エンドポイント）、プラガブルなベクトルストア（SQLiteまたはQdrant）、そしてMCPサーバー。
今後実装予定：refreshでのより高度な競合解決、アダプター追加、そして常時その他のマシンへの同期スケジュール。
MITです。LICENSE を参照。
This server cannot be deployed
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Search, store, and recall across sessions.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
