P2: Schlanker claude-Kontext ohne zweiten Auth-Zustand — settingSources statt CLAUDE_CONFIG_DIR

[munirad7s]

Mission

Der claude-Agent bekommt seinen schlanken Kontext — ohne einen zweiten Auth-Zustand. Der Hebel ist nicht das Config-Verzeichnis, sondern die settingSources-Zeile im ACP-Adapter.

Money-Link

Führungs-Hebel: buzz#84 hat gemessen, dass der claude-Strang bei jedem session/new 17,8 s verbrennt und 56 MCP-Server hochzieht, 12 davon dauerhaft kaputt. Der Gegenbeweis steht auch: mit schlankem Kontext sind es 2,2 s und 19 Server — 8,1×. Solange das nicht greift, ist der zweite bezahlte Builder im Empire bei jedem Auftrag eine Viertelminute langsamer, und jeder tote Server ist ein Fehlerpfad, der irgendwann als "Agent hängt" auftaucht.

Kontext (alles gemessen in buzz#84, 2026-08-01)

• Ursache: @agentclientprotocol/claude-agent-acp@0.64.0, dist/acp-agent.js setzt hart
  const options = { systemPrompt, settingSources: ["user", "project", "local"], ... }.
  Ohne diese Zeile lädt das Claude Agent SDK keine Filesystem-Settings; mit ihr erbt der Agent Munirs kompletten User-Scope (28 MCP-Server aus ~/.claude.json, 39 Plugins aus ~/.claude/settings.json).
• Der naheliegende Weg CLAUDE_CONFIG_DIR (das Analogon zu CODEX_HOME aus buzz#40) ist erprobt und verworfen: Claude Code ersetzt ~/.claude/.credentials.json beim Schreiben (neu schreiben + umbenennen). Ein Hardlink zeigt auf den Inode und zerfällt deshalb nach einem Aufruf lautlos in zwei Dateien — zwei Refresh-Ketten auf einem Konto. Zweimal reproduziert, Inode- und Linkzahl-Beleg in .empire/AGENTS.md (Abschnitt buzz#84).
• Zur Kontrolle: ~/.codex/auth.json ↔ ~/.codex-buzz/auth.json halten (links=2, gleicher Inode) — die Codex-Engine schreibt in place. Der Mechanismus aus buzz#40 ist nicht übertragbar, der Unterschied liegt in der Engine.
• Symlink wäre die richtige Form (löst nach Pfad auf, überlebt das Ersetzen), scheitert an Windows: New-Item -ItemType SymbolicLink → NewItemSymbolicLinkElevationRequired. Junctions gibt es nur für Verzeichnisse.
• Der Nest-Scope trägt sich selbst: mit enableAllProjectMcpServers: true in ~/.buzz/.claude/settings.local.json verbinden sich alle fünf Nest-Server auch dann, wenn der User-Scope wegfällt. Die Dispatcher-Ausstattung aus buzz#4 ist nicht in Gefahr.
• Messwerkzeug: stdio-Sonde initialize → session/new gegen %APPDATA%\Buzz\node-tools\claude-agent-acp.cmd, kontingentunabhängig (kein session/prompt); Server-Zahl über claude mcp list im selben cwd.

Vorflug-Check (nach Claim, vor Arbeit)

1. Adapter-Version prüfen — settingSources kann inzwischen konfigurierbar sein. Ist sie es, entfällt Punkt 1 des Auftrags und es bleibt reine Verdrahtung.
2. Ausgangsmessung wiederholen (Zahlen aus buzz#84 sind der Vergleichsmaßstab, nicht die Wahrheit von heute).
3. Prüfen, ob Windows-Entwicklermodus inzwischen an ist (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock) — dann ist der Symlink-Weg auf einmal offen und viel billiger als ein Adapter-Patch.

Auftrag

1. Bevorzugt: settingSources im Adapter konfigurierbar machen (z. B. Env CLAUDE_ACP_SETTING_SOURCES, Default unverändert) und als Upstream-PR an @agentclientprotocol/claude-agent-acp einreichen. Bis das gemerged ist, entscheiden: warten oder lokal patchen — das Verzeichnis der installierten App ist tabu, ein Patch gehört daneben, nicht hinein.
2. Alternativweg bewerten: Entwicklermodus/Elevation für einen echten Symlink auf die Credentials-Datei. Wenn das ein Munir-Handgriff von 30 Sekunden ist, ist es der kürzere Weg — dann Blocker-Protokoll statt Adapter-Patch.
3. Gewählten Weg umsetzen, Agent-Record verdrahten (Muster: der codex-Record trägt seine Variable seit buzz#40), Sicherung mit Zeitstempel daneben.
4. Rot-Probe: alten Zustand zurückspielen, Messwerte müssen wieder schlecht werden.
5. Gegenprobe: eine Auth-Kette — nach einem Agentenlauf und einer interaktiven Session müssen beide Seiten denselben Token-Stand sehen (Inode/Hash vergleichen, nicht behaupten).

Nicht-Ziele / Guardrails

• Munirs interaktives Claude-Code-Setup wird nicht beschnitten — trennen statt aufräumen.
• Kein zweiter Auth-Zustand. Das ist der Grund, warum buzz#84 nicht verdrahtet hat; wer es hier wieder aufmacht, macht denselben Fehler.
• Die installierte Buzz-App wird nicht überschrieben; kein Neustart der App mit laufenden Agenten ohne Munir.

Verifikation (Befehle + erwartete Ausgabe)

#	Aktion	Erwartung
1	stdio-Sonde initialize → session/new, warm, vorher/nachher	von ~17 s auf < 5 s
2	claude mcp list im cwd ~/.buzz	von 56 auf < 25 Server, die fünf Nest-Server weiterhin verbunden
3	Rot-Probe	ohne die Änderung wieder ~17 s
4	Auth-Gegenprobe nach einem Refresh	eine Datei, ein Stand — kein eingefrorener zweiter Token

Definition of Done

• Messwerte vorher/nachher, gleiche Bedingungen
• Auth nachweislich einkettig (Inode/Hash-Beleg)
• Gewählter und verworfener Weg begründet in .empire/AGENTS.md
• Feat-Branch → PR (--repo munirad7s/buzz --base main --head <branch>) → gemerged, Issue geschlossen

Rechte

Chrome-MCP, Windows-MCP, Playwright, n8n-MCP, ~/.secrets/** — ohne Rückfrage. Blocker → blocker-mail.sh + Label blocked-munir + weiter.

Format v2 · buzz_empire 2026-08-01 (Gardener aus buzz#84)