OPENCLAW MACOS
STALE_
LAUNCHAGENT_
TOKEN.

Im Release-Zug 2026.4.x taucht immer wieder dasselbe Szenario auf: Operations rotieren das Gateway-Token über Doctor oder Control-Plane, exportieren den neuen Wert in der Shell, vielleicht sogar in Docker Compose — und dennoch antworten Telegram, Enterprise-IM, Browser-UI und Integrationsclients geschlossen mit 401 unauthorized. Lokal kann openclaw gateway status kurz grün wirken, weil der Pfad kürzer ist als der einer echten Kanalnachricht. In Wahrheit startet macOS LaunchAgent den Prozess mit einem in der plist unter EnvironmentVariables eingefrorenen OPENCLAW_GATEWAY_TOKEN. Ohne --force kann openclaw gateway install melden, der Agent sei „bereits installiert“, und die plist unverändert lassen. Dieser Artikel strukturiert Symptommatrix, Drei-Quellen-Abgleich (plist / Shell / Vault), sicheres bootout–edit–bootstrap, erzwungenes Reinstall, Remote-SSH-Checks und harte Gates. Ergänzend: Upgrade breaking & Auth v2, Docker/WS-Token, Migration & launchd, silent Gateway, systemd/launchd-Baseline.

1. Warum globale 401er mit „lebendigem“ Prozess koexistieren

Transport kann gesund sein, Credentials aber nicht: ein Gateway kann lauschen und dennoch jeden Authorization-Header mit dem alten Secret ablehnen. Kanalplugins melden sofort; minimale Healthchecks oft nicht. launchd erbt plist-Umgebung, nicht Ihre letzte zsh-Session. Wenn das Control-Plane das alte Token widerruft, kollabieren alle brokerabhängigen Pfade synchron. Das Installationswerkzeug ist idempotent — das ist korrekt — aber doppeldeutig, wenn Ihre Absicht Secret-Refresh ist; dann brauchen Sie Überschreib-Semantik (--force laut CLI-Hilfe).

2. Symptom-Evidenz-Matrix

Sichtbar	Hypothese	Beleg
Alle Kanäle gleichzeitig 401	Gateway nutzt widerrufenes Token	Zeitstempel mit Rotations-Ticket; HTTP-Body
nur launchd-Instanz tot, Foreground ok	veralteter plist-Wert	plutil -p ~/Library/LaunchAgents/*openclaw*.plist
install „erfolgreich“, kein Fix	keine plist-Änderung	mtime/Hash vorher–nachher
nur Remote-Mac	falscher Benutzer oder launchd-Domain	launchctl print gui/$(id -u)

3. Wie LaunchAgents den Fehler verstärken

Die plist ist deklarative Infrastruktur: einmal serialisiertes OPENCLAW_GATEWAY_TOKEN überlebt Reboots unverändert, bis Sie bootout, Datei ändern und neu laden. Behandeln Sie Rotation wie ein Mini-Release: Geheimnis im Vault → alle Materialisationen (plist, compose) → Gateway neu starten → geschäftlichen Smoke-Test (echte Nachricht), nicht nur localhost-curl.

4. Sieben Schritte

Step 01 — Einfrieren

CLI-Versionen, LaunchAgent-Label, Rotationszeitpunkt dokumentieren; parallele unkoordinierte Restarts vermeiden.

Step 02 — plist finden

Typisch ~/Library/LaunchAgents/; bei dediziertem Benutzer dessen $HOME.

Step 03 — drei Quellen

plist, interaktive Shell (forensisch), Vault-Fingerprint — keine Klartext-Secrets in Chat.

Step 04 — bootout, editieren, bootstrap

Domäne/Label laut Dokumentation, dann neu laden.

Step 05 — CLI mit force

openclaw gateway install --force falls Hilfe es vorsieht; Akzeptanzkriterium: geänderte plist-Metadaten.

Step 06 — Schichtprüfung

Logs healthy → echter Kanal-Roundtrip → UI. Zweite plist oder Docker-Duplikat suchen.

Step 07 — Hygiene

alte Tokens im Vault widerrufen; Backups verschlüsseln; Keychain oder 0600-Dateien bevorzugen.

5. Remote-Mac: zehn SSH-Punkte

Gleicher Unix-Benutzer, $HOME, launchctl print, ProgramArguments-Pfad, alte Workspace-Pfade nach Migration, Firewall, Aqua-Anmeldung, Log-Verzeichnisrechte, Docker-Vorrang gegenüber launchd (Docker-Leitfaden), redigierte Logs im Ticket.

6. Missverständnisse

Nur .env ändern, während launchd der Owner ist, reicht nicht. Grüner Installer-Text ohne plist-Änderung ist kein Alignment. Ein localhost-curl beweist nicht Telegram-Webhooks.

7. Grenze zu Upgrade und Migration

Breaking-Releases verschieben oft Device Identity und Attestation. Doctor ohne plist-Refresh erzeugt „halb grün“. Konvergieren Sie mit Migration-Runbook auf eine einzige Secret-Pipeline.

8. Incident-Zeitleiste (erste 30 Minuten)

T+0–2: zweite Installation verbieten, Label und Build-Hash pinnen. T+3–8: 401-Antwortkörper und Gateway-Auth-Zeile korrelieren; nur Clients schreien → anderer Proxy/Port. T+9–15: plist, optional Compose, Vault parallel — zwei Wahrheiten = Drift, nicht Control-Plane-Ausfall. T+16–25: bootout → Patch oder Force → bootstrap; genau eine Rollenreihenfolge pro Vorfall. T+26–30: ohne Gates A–C kein „grün“. Headless-Rack-Macs haben keine Schulter zum Antippen — schriftliche Schritte bestimmen MTTR.

9. Doppel-Gateways, Ports, Reverse-Proxy

Vordergrund-Debugging und launchd besetzen verschiedene Loopbacks; TLS-Zertifikate sind neu, aber proxy_pass zeigt noch auf die alte Kiste; Docker fügt eine dritte Env-Schicht hinzu — alles sieht nach „Token stimmt, 401 bleibt“ aus. Build-/Commit-Health auf Loopback und öffentlichem Hostnamen messen; Hash muss übereinstimmen. Entweder einen Supervisor wählen (nur launchd oder nur Compose) oder Dual-Write in jedem RFC erzwingen.

10. Dreieck plist ↔ launchctl ↔ Prozess

Schicht	Gesund	Kaputt
Datei	mtime springt, plutil ok	XML-Fehler, Rechte drift
launchctl	Programmpfad passt zu which	verwaister nvm-Pfad
Prozess env	Fingerprint = Vault	fehlender Key trotz Start
Logs	401-Wellen = Auth	nur CPU — jsonl/bootstrap zuerst

systemd-Umgebungsdateien 1:1 zu übernehmen ist riskant; LaunchAgents serialisieren Literale. Ohne dieses Dreieck verirren sich Remote-Teams.

11. FAQ

F: plist geändert, weiter 401. A: Pfad aus launchctl print gegen Cloud-Duplikate prüfen. F: Zuerst revoken? A: gefährlich — Reihenfolge im Runbook fixieren. F: Doctor grün, Kanal tot. A: echte Nachricht schließen den Vorfall. F: Multi-User-Mini? A: getrennte Unix-Konten, getrennte LaunchAgents.

12. Fazit

Universelle 401er nach Token-Arbeit auf macOS sind fast immer Konfigurationsdrift, nicht mystische TLS-Bugs. Für dauerhaftes Apple-Silicon-Hosting: MACGPU-Preise, Telegram (Stichwort MACGPU). Maßgeblich ist stets die offizielle CLI-Hilfe Ihrer Version.