Tesserae v0.7.2 — Discovery und Compile hängen nicht mehr

<!-- translations:start -->

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

<!-- translations:end -->

Veröffentlicht am 2026-06-12 · PyPI · GitHub release · pip install --upgrade tesserae==0.7.2

Ein Bugfix-Release, das drei Wege beseitigt, auf denen Tesserae auf Maschinen mit großer Agenten-Sitzungshistorie stecken bleiben konnte: eine Session-Discovery, die nie zurückkehrte, CLI-Agent-Subprozesse, die nach einem Timeout für immer festhingen, und parallele Compiles, die sich auf demselben Projektzustand stapelten.

1. tesserae sessions discover kehrt zurück — selbst bei zig GB Historie

Die Discovery hat bisher vor dem Filtern jedes Transkript aller Projekte unter jeder Account-Wurzel vollständig als JSON geparst. Auf einer Maschine mit ~57 GB Claude-Code-/Codex-Historie kehrte der Befehl damit praktisch nie zurück.

Drei Fixes, die sich gegenseitig verstärken:

• Marker-Vorfilter — ein Transkript kann nur dann zum fokussierten Projekt gehören, wenn der Projektpfad wörtlich in der Datei vorkommt. Fremde Transkripte werden daher jetzt mit einem rohen Byte-Scan (~50× schneller als Parsen) aussortiert, bevor irgendeine JSON-Arbeit anfällt.
• Deduplizierung symlinkter Account-Wurzeln — ~/.claude als Symlink auf ~/.claude-personal1 führt nicht mehr dazu, dass jedes Transkript doppelt gescannt wird.
• mtime-basierter Scan-Cache — die Prüfergebnisse werden in ~/.cache/tesserae/discovery_scan.sqlite gespeichert (überschreibbar via TESSERAE_DISCOVERY_CACHE), sodass Folgeläufe nur neue oder geänderte Transkripte erneut lesen.

Gemessen auf der betroffenen Maschine: kehrt nie zurück → 3 min 16 s kalt → 1 min 26 s warm, 4.048 Sessions gefunden. tesserae refresh und der Session-Import nutzen denselben Pfad und beschleunigen entsprechend.

2. CLI-Agent-Timeouts können einen Compile nicht mehr aufhängen

Aufrufe von codex exec / claude -p nutzten subprocess.run(capture_output=True, timeout=...), das beim Timeout nur das direkte Kind beendet und anschließend die Ausgabe-Pipes ohne Zeitlimit leert. Die Agent-CLIs starten eigene Kindprozesse, die diese Pipes erben — ein Timeout konnte einen Compile daher hinter verwaisten Enkelprozessen unbegrenzt bei 0 % CPU blockieren (beobachtet: ~2 Tage).

LLM-CLI-Aufrufe laufen jetzt in einer eigenen Prozessgruppe, und ein Timeout beendet die gesamte Gruppe mit zeitlich begrenztem Leeren der Pipes — ein Timeout bedeutet immer tot, nie festgehangen.

3. Ein Compile pro Projekt zur selben Zeit

ProjectWiki.compile hält jetzt einen exklusiven Lock auf .tesserae/compile.lock. Ein hook-ausgelöster Refresh, der während eines laufenden Compiles feuert, schlägt sofort mit einer klaren Meldung fehl, die die PID des Inhabers nennt, statt sich still auf denselben .tesserae-Zustand zu stapeln. Mit TESSERAE_COMPILE_LOCK_WAIT=<Sekunden> wird stattdessen auf den Lock gewartet. Der Lock basiert auf flock(2), ein abgestürzter Compile hinterlässt also nie einen veralteten Lock.

4. tesserae --version

Die Root-Hilfe beginnt jetzt mit der installierten Version, und tesserae --version (auch -V / version) gibt sie direkt aus.

Upgrade von v0.7.1

Drop-in. Keine Konfigurationsänderungen. Der erste sessions discover / refresh nach dem Upgrade zahlt einen einmaligen Prüfdurchlauf, um den Scan-Cache zu füllen; alle weiteren Läufe sind schnell.