ctxはローカルのコーディングエージェント履歴を検索するCLI

エージェント履歴がJSONLに閉じ込められる問題

READMEは、コーディングエージェントにはgit履歴がある一方、セッション transcript と tool call 記録は冗長なログファイルに隔離され、エージェントから読みやすい形ではないと述べます。ctxはオープンソースCLIとして、過去のコーディングエージェントセッションをローカルで高速検索し、メッセージと tool call を横断して結果から該当イベントや全文 transcript へ飛べることを目的にしています。

親セッション、サブエージェント、フォークの関係も理解するとREADMEに書かれ、積極的なオーケストレーション下でも作業連鎖を復元できると説明しています。これは要約に頼る「エージェントメモリ」とは異なり、圧縮を挟まず生の記録へ即座にアクセスする設計だとREADMEは対比しています。 追加段落：README一次情報に基づき、本リポジトリの公開範囲はドキュメントとソースに限定されます。star数やfork数はGitHubメタデータ由来の注目指標であり、機能保証やSLAを意味しません。導入判断では、READMEが示す具体コマンド・設定キー・バージョン番号を手元環境で再現し、期待する入出力が得られるかを記録してください。READMEに無い性能数値、互換マトリックス、セキュリティ監査結果は推測で補わず、issue/リリースノート/公式サイトで確認できる事実だけを採用記録に残します。

ctx setupが~/.claudeを読む流れ

How it works節によると、過去セッションは通常~/.claudeや~/.codex下のJSONLやSQLiteに既に存在します。ctx setupはそれらソースを発見し、変更せず読み取り、各プロバイダ形式を一貫したローカルレコード（セッション、メッセージ、tool call、関係、リポジトリ活動）へ変換して索引します。

フックやエージェントプロセス内コードは不要で、自動索引が既定でオンです。更新は部分索引が完了してから可視化されるため、コマンドが未完成索引を読むことはないとREADMEは述べます。各セッションとイベントは安定したctx IDを受け取り、transcript全文とソース情報を保持します。

ctx searchとctx showの基本操作

READMEの例では、ctx setupで既存セッションを索引した後、ctx search "failed migration"のように自然言語に近い語句で検索します。ファイルに触れた履歴を探すならctx search --file crates/foo/src/lib.rs、複数語はctx search --term "failed migration" --term rollbackのように指定します。結果には一致セッション、スニペット、ctx IDが含まれます。

詳細はctx show event <ctx-event-id> --window 3で周辺 transcript を表示します。検索は既定でBM25字句一致で、エラー文字列、ファイル名、コマンド、判断語を渡すとそれを含むセッションを順位付けするとREADMEは説明しています。semantic searchはctx semantic enableとctx semantic statusでローカル埋め込みを有効化する別モードです。

ctx proとctx blameの帰属

ctx proは有料アドオンで、「git blameだがエージェントセッション版」とREADMEは位置づけます。git blameが最後に行を変えたコミットを示すのに対し、ctx blameはそのコミットを生んだエージェントセッションと、元 transcript および tool call への引用を返す、と説明されています。

例としてctx blame file src/checkout.ts --lines 118:146が示され、commit sha、session UUID、evidenceリンクが出力されます。commitやPR URLからもctx blame commit <sha>、ctx blame pr <url>で開始できます。セッションがローカルに無い場合（同僚のエージェントが書いたコードなど）、帰属を証明できないとREADMEは明記します。blameも索引と同様ローカル実行で、コードと履歴が外に出ないと述べています。

インストールとctx pro試用

macOS/Linuxはcurl -fsSL https://ctx.rs/install | sh、Windows PowerShellはirm https://ctx.rs/install.ps1 | iexです。READMEはエージェントに「Please install and set up ctx CLI (see github.com/ctxrs/ctx)」と頼む例も示しています。

ctx proは月20 USDですが、READMEはアカウントやクレジットカード無しで2週間無料試用できると書いています。新規インタラクティブインストールは条件を満たすと自動で試用が始まるとあり、既存利用者はctx proで設定します。Apache-2.0ライセンスで、最新リリースはv1.2.2（2026-08-28）がGitHub Releasesにあります。

ctx setup後にfailed migrationを検索する

評価手順は、インストール直後にctx setupを実行し、~/.claudeや~/.codexに実データがあるマシンで索引完了を待つことです。次にctx search "failed migration"を実行し、evt_やses_で始まるIDが返るか、スニペットが自分の過去作業と一致するかを記録します。ファイル横断確認では、実際に触ったリポジトリパスをctx search --fileに渡し、ヒット件数とランキングを保存します。

ctx show event <ctx-event-id> --window 3で前後文脈を取得し、token効率の主張（READMEの50x表現）は自分のクエリで raw transcript grep と比較する必要があります。semantic searchを試すならctx semantic enable --wait後に同じクエリを再実行し、語彙が異なる関連セッションが拾えるかを別表にします。ctx pro試用では、自分が書いたファイル範囲にctx blame fileを当て、session IDからctx show sessionで transcript を開けるか確認します。

ローカルプライバシーと向き不向き

READMEは索引とblameがローカルで動き、コードと履歴がマシン外に出ないと繰り返し述べます。transcript本文はローカルパスや秘密らしい文字列を隠さず保持するため、共有前に出力をレビューする必要があるとも書かれています。中央集約や監査ログをSaaSで欲しいチームには、この設計は合いません。

複数エージェント（Codex、Claude等）を使い分ける個人や小チームで、過去の失敗アプローチを検索したい場合にctxの価値がREADME上最も明確です。SDK（TypeScript、Python、Rust、Go等）がREADME冒頭に触れられており、CLI以外の組み込みも想定されています。採用記録にはインストール方法、ctx setup実行日、索引対象ディレクトリ、試したsearch/blameコマンド、pro試用の有無を残してください。

編集部の結論

複数エージェントのセッションを横断検索し、失敗した調査を繰り返したくない開発者にはctxが合います。チーム共有の中央サーバーやクラウド履歴同期を求める組織にはREADMEのローカル前提と合いません。採用前にcurl -fsSL https://ctx.rs/install | shで導入し、ctx setup後にctx search "failed migration"とctx show event <ctx-event-id> --window 3で自分の~/.claude履歴が索引されるか確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes