OpenClaw-Pull-Request soll Updates auf Bun-only-Systemen reparieren

Ein offener Pull Request im OpenClaw-Repository soll ein Problem auf Installationen beheben, die nur mit Bun laufen: openclaw update, update repair und Doctor scheitern dort, weil die Wartungsprozesse ein Node starten wollen, das es auf dem System nicht gibt. Laut Pull Request #159431 vom 27. September 2026 betrifft das genau das Setup, auf das die macOS-App und die Linux-Desktop-App mit dem OpenClaw-Bun-Fork umsteigen.

Wo Bun-only-Updates scheiterten

Gemeint sind Systeme ganz ohne Node. Dort startet die CLI als <bun> openclaw.mjs, und der Gateway-Service ist an genau dieses Bun gebunden. Die Wartungsprozesse rief OpenClaw laut Pull Request trotzdem mit einem nackten node auf. Das ging schief.

Zusätzlich blockierte laut Pull Request die Preinstall-Prüfung des Pakets jede Installation und jeden Staging-Schritt des Updaters. Bun legt für Lifecycle-Skripte einen eigenen temporären node-Shim an, und diesen Shim wies die Prüfung als Bun-basiert zurück. Laut OpenClaw-Dokumentation bleibt Bun eine ausdrücklich optionale Runtime für CLI, Gateway und den Managed Node Host. Node ist weiterhin die primäre und empfohlene Runtime.

Ein Runner für alle CLI-Kindprozesse

Der Fix setzt bei resolveNodeRunner() an. Laut Pull Request gibt die Funktion unter Bun jetzt das laufende Bun zurück und entscheidet damit als einzige Stelle, womit OpenClaw seine CLI-Kindprozesse startet. Bisher gab es dafür Sonderfälle und kopierten Code: im Finalize-Schritt von Repair, im automatischen Repair-Agenten und in den Legacy-Kompatibilitätsmodulen. Diese Stellen nutzen jetzt ebenfalls diesen einen Pfad.

Laut Pull Request überspringt die Preinstall-Prüfung künftig den Shim, hinter dem das laufende Bun selbst steckt. Findet sie kein persistentes Node, akzeptiert sie ein ausdrücklich über OPENCLAW_PACKAGE_BUN_LAUNCHER benanntes Bun ab Version 1.4. Unter Bun setzt der Updater diese Variable selbst, bei der Erstinstallation übernimmt das die App. Ist ein persistentes Node vorhanden, muss es weiterhin die engines-Vorgaben erfüllen.

Nebenbei behebt der Pull Request laut eigener Beschreibung einen zweiten Fehler, der mit Node nichts zu tun hat: Updates über ein Kandidatenpaket brachen bei Bun- und pnpm-verwalteten Installationen sofort mit „Staged update has not been admitted for activation.“ ab.

Die Service-Runtime bleibt, wie sie konfiguriert ist

Der Fix ändert nicht, auf welcher Runtime der Gateway-Service läuft. Laut Pull Request bleibt die konfigurierte beziehungsweise angeheftete Runtime maßgeblich, also bei einem an Bun gebundenen Service auch Bun. Doctor schlägt nicht mehr vor, ein unterstütztes oder angeheftetes Bun durch Node zu ersetzen. Die Dokumentation, die eine solche Migration noch beschrieb, wird im selben Zug korrigiert. Unter Bun bietet der Updater die Bun-Executable außerdem nicht mehr als Ersatz-Node für einen Node-Service an und misst das laufende Bun nicht mehr an den Node-engines des Zielpakets.

Was das für den Betrieb heißt

Wichtig für den Betrieb ist ein Punkt, den kein Update selbst lösen kann. Bereits veröffentlichte Updater bis einschließlich 2026.9.6 lehnen ein Bun-only-Update laut Pull Request weiterhin ab, allerdings bevor sie das Gateway stoppen, sodass es weiterläuft. Deshalb muss die erste Bun-only-Version der Apps einen korrigierten Updater gleich mitbringen, denn nachträglich lässt er sich über den alten Updater nicht einspielen. Da der Pull Request noch offen ist, hängt der Nutzen für Bun-only-Setups aus unserer Sicht davon ab, dass der Fix gemergt und veröffentlicht wird.