Tesserae v0.7.2 — ディスカバリーとコンパイルがハングしなくなりました

<!-- translations:start -->

English · 한국어 · 中文 · Русский · Español · Français · Deutsch

<!-- translations:end -->

リリース日 2026-06-12 · PyPI · GitHub release · pip install --upgrade tesserae==0.7.2

大規模なエージェントセッション履歴を持つマシンで Tesserae が停止し得た3つの経路を取り除くバグフィックスリリースです: 返ってこないセッションディスカバリー、タイムアウト時に永久にハングする CLI エージェントのサブプロセス、同じプロジェクト状態に積み重なる同時コンパイル。

1. tesserae sessions discover が返ってきます — 数十 GB の履歴があっても

従来のディスカバリーは、フィルタリングの前にすべてのアカウントルート配下のすべてのプロジェクトのトランスクリプトを完全に JSON パースしていました。約 57 GB の Claude Code / Codex 履歴を持つマシンでは、コマンドは事実上永遠に返りませんでした。

3つの修正が掛け合わさります:

• マーカー事前フィルタ — トランスクリプトが対象プロジェクトに属するには、プロジェクトパスがファイル内に文字どおり現れる必要があるため、他プロジェクトのトランスクリプトは JSON 処理の前に生バイトスキャン(パースの約50倍高速)でふるい落とされます。
• シンボリックリンクされたアカウントルートの重複排除 — ~/.claude が ~/.claude-personal1 を指していても、すべてのトランスクリプトが二重にスキャンされることはなくなりました。
• mtime キーのスキャンキャッシュ — スクリーニング結果は ~/.cache/tesserae/discovery_scan.sqlite に保存され(TESSERAE_DISCOVERY_CACHE で上書き可能)、再実行時には新規または変更されたトランスクリプトだけを読み直します。

問題のマシンでの計測: 永遠に返らない → コールド 3分16秒 → ウォーム 1分26秒、4,048 セッションを発見。tesserae refresh とセッションインポートも同じ経路を共有するため、同様に高速化されます。

2. CLI エージェントのタイムアウトがコンパイルをハングさせなくなりました

codex exec / claude -p の呼び出しは subprocess.run(capture_output=True, timeout=...) を使っていましたが、これはタイムアウト時に直接の子プロセスだけを kill し、その後タイムアウトなしで出力パイプをドレインします。エージェント CLI はそのパイプを継承する自前の子プロセスを生成するため、タイムアウトが孤児となった孫プロセスの背後でコンパイルを CPU 0% のまま無期限に(観測: 約2日間)ブロックさせることがありました。

LLM CLI 呼び出しは現在、独自のプロセスグループで実行され、タイムアウト時にはグループ全体を kill して制限時間内にドレインします — タイムアウトは常に「終了」を意味し、決して「ハング」ではありません。

3. プロジェクトごとに同時1コンパイル

ProjectWiki.compile は .tesserae/compile.lock の排他ロックを保持するようになりました。コンパイル実行中にフックでトリガーされた refresh は、同じ .tesserae 状態に静かに積み重なる代わりに、ロック保持者の pid を示す明確なメッセージとともに即座に失敗します。代わりに待機したい場合は TESSERAE_COMPILE_LOCK_WAIT=<秒> を設定してください。ロックは flock(2) ベースなので、コンパイルがクラッシュしても古いロックが残ることはありません。

4. tesserae --version

ルートヘルプはインストール済みバージョンで始まるようになり、tesserae --version(-V / version も可)がそれを直接表示します。

v0.7.1 からのアップグレード

そのまま差し替え可能で、設定変更は不要です。アップグレード後最初の sessions discover / refresh はスキャンキャッシュを構築するための一回限りのスクリーニングコストを支払いますが、それ以降の実行は高速です。