marcus.hinz
3.5 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| multi-account-keychain | Multi-Account auf macOS — Stand 2.1.199: pro CLAUDE_CONFIG_DIR eigener suffixierter Keychain-Eintrag; .credentials.json-Ansatz überholt |
|
ÜBERHOLT (galt bis Version vor 2.1.199): claude las die .credentials.json direkt aus CLAUDE_CONFIG_DIR (verifiziert 2026-07-03 vormittags, Test bin/oauth-configdir-test).
Stand 2026-07-03 abends, Version 2.1.199 (native Installation): Neu-Login war nötig. Die .credentials.json im Pool Mx9Privat ist weg; claude speichert jetzt pro Config-Dir einen Keychain-Eintrag Claude Code-credentials-<suffix>, Suffix = erste 8 Hex-Zeichen von SHA-256 über den CLAUDE_CONFIG_DIR-Pfad (Mx9Privat → a014e206, TestWürth → erwartet 4c0ad9a9, ggf. NFC/NFD-Frage wegen „ü"). Ohne gesetztes CLAUDE_CONFIG_DIR entsteht der unsuffixierte Eintrag Claude Code-credentials plus ~/.claude/~/.claude.json. Damit ist #20553 (Überschreiben) upstream gelöst — pro Pool ein eigener Eintrag. Verifiziert 2026-07-03 abends: Nach /login in ai-control (Mx9Privat) lief wuerth-plato (gleicher Pool) ohne erneutes Login — Eintrag a014e206 wird poolweit geteilt. Keychain enthielt danach nur diesen einen Claude-Code-Eintrag (kein unsuffixierter). Zweiter Pool ebenfalls verifiziert: 08-07 (TestWürth, oauth) verlangte wie erwartet erneutes Login und erzeugte Claude Code-credentials-4c0ad9a9 — Suffix stimmt mit der Vorab-Berechnung überein, NFC/NFD-Frage wegen „ü" damit geklärt. Keychain-Stand: genau zwei Einträge, a014e206 (Mx9Privat) und 4c0ad9a9 (TestWürth). Multi-Account über suffixierte Keychain-Einträge funktioniert damit vollständig. Dritter Beleg: robotunits nach Umzug auf TestWürth ohne Login gestartet (Starter-Pfad hasht identisch auf 4c0ad9a9). Mit gesetztem CLAUDE_CONFIG_DIR entsteht dabei kein neues ~/.claude im Home — das gelöschte bleibt weg.
Umbenennung 2026-07-03 spätabends: Mx9Privat → privateDefault, TestWürth → apiDefault. Suffixe: privateDefault → 096c4ef9, apiDefault → 15e10251. Die alten Einträge a014e206/4c0ad9a9 wurden gelöscht; kurz darauf lag 096c4ef9 im Keychain — eine laufende Session hat die Credentials unter dem neuen Pfad selbst neu geschrieben, ohne Login-Prompt. Weitere Session-Starts erzeugten keinen zusätzlichen Eintrag. Keychain-Endstand 2026-07-03: genau ein Eintrag 096c4ef9; für apiDefault (15e10251) existiert noch keiner, dort ist beim ersten Start Login nötig.
Kaltstart-Test über die umgestellten Starter (2026-07-04): durchgeführt, funktioniert grundsätzlich (kein Login nötig), aber laut Marcus nicht in der gewünschten Qualität — worin genau der Mangel liegt, ist noch nicht festgehalten.
Umbenennung 2026-07-05: privateDefault → private (Runtime-Ordner, Repo-Ordner, Symlinks, alle 7 Projekt-ai-control.json). Neuer Suffix 485a513f, von der laufenden Session ohne Login selbst geschrieben; 096c4ef9 gelöscht. Im Keychain liegen daneben vier ungeklärte Einträge (54743385, 550a1032, b425db93, dfbfcf1a), keinem Pool zugeordnet — vermutlich Test-Reste.
Why: Mehrere Claude-Zugänge (Abo + Kunden-Keys) strikt getrennt auf einem Rechner.
How to apply: Pro Pool ein Ordner als CLAUDE_CONFIG_DIR (siehe ai-control-pool-setup). OAuth: .credentials.json (0600) in den Pool-Ordner. API-Key: apiKeyHelper in der Pool-settings.json auf die Key-Datei. CLAUDE_CODE_OAUTH_TOKEN-Export ist unnötig.