Mein OpenClaw Bot hat Probleme mit Browser | Friends of the Crustacean 🦞🤝 | Page 1

timid lodge Apr 17, 2026, 8:44 PM

#

Mein OpenClaw Bot hat Probleme mit Browser

Er selber gibt mir den Fehlerprotokoll für dich:

❌ FEHLERDIAGNOSE BROWSER

Status: Browser kann nicht gestartet werden – Timeout bei Initialisierung

Symptome:

• Browser Status: running: false
• CDP (Chrome DevTools Protocol): cdpReady: false
• Chromium erkannt, aber startet nicht

Mögliche Ursachen:

Gateway-Problem (vorgeschlagen vom System)
Chrome/Chromium-Prozess hängt/stürzt ab
Port-Konflikt (18800)
Ressourcenprobleme (RAM/CPU)

───

FEHLERMELDUNG FÜR DISCORD:

🚨 Browser-Problem – OpenClaw

System: Linux Docker Container (Hostinger VPS)
OpenClaw Version: 2026.4.15

Fehler: Browser startet nicht – Timeout bei Initialisierung
CDP Port 18800 nicht erreichbar
Chromium erkannt unter /usr/bin/chromium

Bisher versucht:

Browser start via Tool → Timeout
System empfiehlt Gateway-Restart

Brauche Hilfe bei:

Gateway-Restart durchführen?
Oder manuelle Chrome-Diagnose?

Docker Container mit Homebrew-Installation.

Soll ich das so posten oder willst du erst selbst was testen? 😄

misty ferryBOT Apr 17, 2026, 8:44 PM

#

lament juncoBOT Apr 17, 2026, 8:44 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

deep streamBOT Apr 17, 2026, 8:46 PM

#

Das hier ist schon der richtige Thread, musst du nicht nochmal umformulieren 🙂

Ich würde nicht blind zuerst den Gateway neu starten.
Bei Linux Docker + /usr/bin/chromium ist das häufiger ein Chromium/CDP/Sandbox-Problem als ein Gateway-Problem.

Bitte im Container mal das hier laufen lassen und die Outputs posten:

openclaw status --all
openclaw gateway status
openclaw browser status --json
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs
ss -lntp | grep 18800 || true

Dann der wichtigste Test, direkt ohne OpenClaw:

#

/usr/bin/chromium --headless --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \
  --user-data-dir="$HOME/.openclaw/browser/openclaw/user-data" \
  about:blank

In einem zweiten Shell:

curl http://127.0.0.1:18800/json/version

So lesen wir das:

wenn der manuelle Chromium-Start schon scheitert, ist es ein Browser-/Container-Problem
wenn curl .../json/version klappt, dann lebt CDP und OpenClaw/Gateway ist eher der nächste Verdächtige

#

Für Docker würde ich außerdem sehr wahrscheinlich setzen:

openclaw config set browser.executablePath "/usr/bin/chromium"
openclaw config set browser.headless true
openclaw config set browser.noSandbox true
openclaw gateway restart

Kleine Bauchlandung dazu: Homebrew in Docker ist ein bisschen cursed. Wenn Chromium in den laufenden Container reingebastelt wurde, besser in das Image backen statt live nachzuinstallieren.

Docs dazu:

Wenn du magst, poste die 6 Outputs hier, dann gehe ich sie mit dir Zeile für Zeile durch.

timid lodge Apr 17, 2026, 8:59 PM

#

curl http://127.0.0.1:18800/json/version
curl: (7) Failed to connect to 127.0.0.1 port 18800 after 0 ms: Couldn't connect to server

/usr/bin/chromium --headless --no-sandbox --disable-gpu
--remote-debugging-port=18800
--user-data-dir="$HOME/.openclaw/browser/openclaw/user-data"
about:blank <<<< bei den 4 Befehlzseilen kam nach 2 Min nix. Abgebrochen von mir.

iagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /data/.openclaw/openclaw.json
Bind: lan

✓ Config: /data/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
✓ Skills: 24 eligible · 0 missing · /data/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

🦞 OpenClaw 2026.4.15 (041266a)
Type the command with confidence—nature will provide the stack trace if needed.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw-0/openclaw-2026-04-17.log

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://172.19.0.2:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Habe nur einen Teil gepostet, da sonst zu lang für den Chat. War etwas wichtiges dabei, was fehlt?

deep streamBOT Apr 17, 2026, 9:00 PM

#

Ja, da war schon was Wichtiges drin 👍

Das Entscheidende:
RPC probe: ok heißt, der Gateway lebt. Das riecht also nicht nach einem Gateway-Problem, sondern nach Chromium/CDP im Container.

Und noch wichtig:
Dass /usr/bin/chromium ... einfach “hängen bleibt”, ist erstmal normal. Der Browser läuft dann im Vordergrund. Dafür brauchst du entweder eine zweite Shell oder startest ihn im Hintergrund.

Bitte genau das hier posten:

openclaw config get browser --json
ss -lntp | grep 18800 || true

/usr/bin/chromium --headless --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \

#

  --user-data-dir="$HOME/.openclaw/browser/openclaw/user-data" \
  about:blank >/tmp/chromium-cdp.log 2>&1 &

sleep 5
ss -lntp | grep 18800 || true
curl -s http://127.0.0.1:18800/json/version || true
tail -n 100 /tmp/chromium-cdp.log

So lesen wir das:

wenn curl dann JSON liefert, kann Chromium CDP grundsätzlich, dann ist OpenClaw-Konfig/Startpfad dran
wenn weiter nichts auf 18800 lauscht, startet Chromium im Container nicht sauber
wenn im Log Lib-/Sandbox-/Permission-Fehler stehen, haben wir die Ursache direkt

Noch ein Detail:

#

systemd disabled im Container ist erwartbar und hier wahrscheinlich nicht der Kernfehler. Wenn du später Config änderst, dann eher den Container/Supervisor neu starten, nicht auf systemd fixieren.

Wenn browser.noSandbox aktuell noch false ist, ist das in Docker sehr verdächtig.

Relevant:

Poste genau die 4 Outputs, dann sag ich dir direkt den nächsten Schritt.

timid lodge Apr 17, 2026, 9:04 PM

#

sleep 5
ss -lntp | grep 18800 || true
curl -s http://127.0.0.1:18800/json/version || true
tail -n 100 /tmp/chromium-cdp.log
[1] 551
[1]+ Exit 21 /usr/bin/chromium --headless --no-sandbox --disable-gpu --remote-debugging-port=18800 --user-data-dir="$HOME/.openclaw/browser/openclaw/user-data" about:blank > /tmp/chromium-cdp.log 2>&1
bash: ss: command not found
[551:551:0417/230248.792554:ERROR:chrome/browser/process_singleton_posix.cc:363] The profile appears to be in use by another Chromium process (8560) on another computer (dbd144e61f4c). Chromium has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Chromium.
[551:551:0417/230248.792694:ERROR:chrome/browser/ui/views/message_box_dialog.cc:199] Unable to show message box: Chromium - The profile appears to be in use by another Chromium process (8560) on another computer (dbd144e61f4c). Chromium has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Chromium.
root@6bbced03b86b:~#

deep streamBOT Apr 17, 2026, 9:05 PM

#

Ja, das war der fehlende Teil, und ich glaube wir haben die Ursache jetzt ziemlich klar:

Chromium crasht nicht wegen Gateway oder Port, sondern wegen einem gelockten Profil.
Der wichtige Teil ist:

Exit 21
The profile appears to be in use by another Chromium process
PID 8560

Also: CDP kommt gar nicht hoch, weil Chromium das User-Data-Dir nicht öffnen will.

Was ich jetzt machen würde

Zuerst prüfen, ob der alte Chromium-Prozess wirklich noch lebt:

#

ps -fp 8560 || true
ps aux | grep -i chromium

Dann der saubere Fix für den OpenClaw-managed profile openclaw:

openclaw browser --browser-profile openclaw stop
openclaw browser --browser-profile openclaw reset-profile
openclaw config set browser.executablePath "/usr/bin/chromium"
openclaw config set browser.headless true
openclaw config set browser.noSandbox true

Danach den Container/Supervisor neu starten
(nicht auf systemd verlassen, weil du ja im Container bist)

#

und dann testen:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs

Wichtiger Hinweis

reset-profile setzt den isolierten OpenClaw-Browser-Profileordner zurück.
Falls du dort Logins/Cookies bewusst drin hattest, sind die dann weg.

Kurzfazit

Gateway ist okay (RPC probe: ok)
Port 18800 ist nicht der Hauptfehler
Root cause ist sehr wahrscheinlich der gelockte/stale Chromium-Profileordner

Falls du magst, poste noch kurz das Ergebnis von:

#

ps -fp 8560 || true
openclaw config get browser --json

Dann sag ich dir sofort, ob noch ein zweiter Stolperstein drin ist.

Docs:

timid lodge Apr 17, 2026, 9:10 PM

#

UID PID PPID C STIME TTY TIME CMD
root 596 0.0 0.0 3500 1756 pts/0 S+ 23:06 0:00 grep -i chromium
root@6bbced03b86b:~#

GatewayClientRequestError: browser.request cannot mutate persistent browser profiles

🦞 OpenClaw 2026.4.15 (041266a)

Ich kann Teilen nicht posten, weils vom Server abgelehnt wird.
Jedenfalls : Config overwrite: /data/.openclaw/openclaw.json schlägt fehl

deep streamBOT Apr 17, 2026, 9:12 PM

#

Ah, jetzt wird’s klarer. Da sind zwei Probleme gleichzeitig:

stale/gelocktes Browser-Profil
OpenClaw kann seine Config unter /data/.openclaw/openclaw.json nicht schreiben

Und eine Korrektur zu meinem vorigen Testpfad:
Bei dir liegt OpenClaw offenbar unter /data/.openclaw, nicht unter /root/.openclaw. Der relevante Browser-Ordner ist also sehr wahrscheinlich dort.

Was das heißt

ps zeigt kein laufendes Chromium
der frühere Lock ist also sehr wahrscheinlich stale
browser.request cannot mutate persistent browser profiles heißt, dass dieser Reset-Pfad über die aktuelle Surface blockiert ist
Config overwrite ... schlägt fehl heißt zusätzlich: Permissions/Mount-Problem

Nächste Checks bitte

#

echo "$OPENCLAW_HOME"
ls -ld /data /data/.openclaw /data/.openclaw/openclaw.json
ls -la /data/.openclaw/browser/openclaw/user-data 2>/dev/null | head -50
find /data/.openclaw/browser/openclaw/user-data -maxdepth 1 -name 'Singleton*' -ls 2>/dev/null
id

Meine Vermutung

Wenn da SingletonLock / SingletonCookie / SingletonSocket liegen und kein Chromium läuft, dann ist genau das der Blocker.

Danach der Fix

Wenn du mit dem Verlust des isolierten OpenClaw-Browserprofils okay bist, ist der pragmatische Fix:

stale Lockfiles im /data/.openclaw/browser/openclaw/user-data entfernen
oder
gleich den ganzen isolierten openclaw-Browserprofilordner zurücksetzen

#

Und separat: die Rechte auf /data/.openclaw fixen, damit openclaw config set ... wieder schreiben darf.

Bei Docker ist das oft Ownership. Die Docs nennen dafür typischerweise UID 1000 beim Image:
https://docs.openclaw.ai/install/docker

Wenn du magst, poste genau die 5 Outputs oben, dann sage ich dir die konkrete nächste Zeile, statt weiter zu raten.

timid lodge Apr 17, 2026, 9:15 PM

#

drwxr-xr-x 12 node node 4096 Mar 13 17:47 .
drwxr-xr-x 3 node node 4096 Mar 5 23:50 ..
-rw-r--r-- 1 node node 14 Mar 5 23:50 .openclaw-profile-decorated
-rw------- 1 node node 4194304 Mar 5 23:52 BrowserMetrics-spare.pma
drwx------ 34 node node 4096 Mar 13 21:16 Default
drwx------ 2 node node 4096 Mar 10 16:03 Dictionaries
drwx------ 2 node node 4096 Mar 5 23:50 GrShaderCache
drwx------ 2 node node 4096 Mar 5 23:50 GraphiteDawnCache
-rw-r--r-- 1 node node 14 Mar 7 22:31 Last Version
-rw------- 1 node node 3079 Mar 13 17:47 Local State
drwx------ 2 node node 4096 Mar 5 23:50 NativeMessagingHosts
drwx------ 2 node node 4096 Mar 5 23:50 Safe Browsing
drwx------ 2 node node 4096 Mar 5 23:50 ShaderCache
lrwxrwxrwx 1 node node 19 Mar 7 22:31 SingletonCookie -> 4371859529056072007
lrwxrwxrwx 1 node node 17 Mar 7 22:31 SingletonLock -> dbd144e61f4c-8560
lrwxrwxrwx 1 node node 49 Mar 7 22:31 SingletonSocket -> /tmp/org.chromium.Chromium.NAXmxV/SingletonSocket
-rw-r--r-- 1 node node 86 Mar 7 22:31 Variations
drwx------ 2 node node 4096 Mar 5 23:50 component_crx_cache
drwx------ 2 node node 4096 Mar 5 23:51 extensions_crx_cache
-rw------- 1 node node 49152 Mar 5 23:50 first_party_sets.db
-rw------- 1 node node 0 Mar 5 23:50 first_party_sets.db-journal
drwx------ 2 node node 4096 Mar 5 23:50 segmentation_platform
10516430 0 lrwxrwxrwx 1 node node 19 Mar 7 22:31 /data/.openclaw/browser/openclaw/user-data/SingletonCookie -> 4371859529056072007
10516428 0 lrwxrwxrwx 1 node node 17 Mar 7 22:31 /data/.openclaw/browser/openclaw/user-data/SingletonLock -> dbd144e61f4c-8560
10516429 0 lrwxrwxrwx 1 node node 49 Mar 7 22:31 /data/.openclaw/browser/openclaw/user-data/SingletonSocket -> /tmp/org.chromium.Chromium.NAXmxV/SingletonSocket
uid=0(root) gid=0(root) groups=0(root)

deep streamBOT Apr 17, 2026, 9:15 PM

#

Perfekt, das ist der Smoking Gun. 👀

Die drei hier sind stale Chromium-Locks:

SingletonLock -> dbd144e61f4c-8560
SingletonCookie
SingletonSocket

Und weil kein Chromium-Prozess läuft, sind die nicht mehr gültig.
Der Browser hängt also am alten Lock, nicht an Gateway/RAM/Port.

Jetzt der direkte Fix

rm -f /data/.openclaw/browser/openclaw/user-data/SingletonLock \
      /data/.openclaw/browser/openclaw/user-data/SingletonCookie \

#

      /data/.openclaw/browser/openclaw/user-data/SingletonSocket

Dann Container / Gateway-Prozess neu starten und direkt testen:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs

Wenn es danach immer noch klemmt

Dann den isolierten OpenClaw-Browserprofilordner nur umbenennen, nicht löschen:

mv /data/.openclaw/browser/openclaw/user-data \

#

   /data/.openclaw/browser/openclaw/user-data.bak.$(date +%s)
mkdir -p /data/.openclaw/browser/openclaw/user-data
chown -R node:node /data/.openclaw/browser/openclaw

Dann nochmal:

openclaw browser --browser-profile openclaw start

Zum `config overwrite` Fehler

Das ist vermutlich ein zweites Problem.
Für den Browserfehler selbst haben wir jetzt aber ziemlich klar die Ursache gefunden: stale Singleton* Locks.

Wenn du die 3 Lockfiles entfernt und neu gestartet hast, poste einfach das Ergebnis von openclaw browser ... start. Dann gehen wir den letzten Meter auch noch.

timid lodge Apr 17, 2026, 9:21 PM

#

Ich bat meinen OpenClaw Bot um einen intensiven Browser Test. Scheinbar läuft alles.

Seine Meldung:

Alle 3 Suno-Links wurden geöffnet! ✅

Intensiv-Test Ergebnis:

Test	Ergebnis
Status Check	✅ running: true, cdpReady: true
Google.com	✅ targetId erhalten
Suno Link 1 (Rise Again)	✅ targetId erhalten
Suno Link 2 (The Closed Book)	✅ targetId erhalten
Suno Link 3 (Chrysalis)	✅ targetId erhalten

Browser ist voll funktionsfähig. Keine Timeouts, keine Fehler, CDP kommuniziert korrekt.

Du kannst jetzt alle Suno-Tracks direkt im Browser öffnen lassen – kein Discord-Ticket nötig. 😎

deep streamBOT Apr 17, 2026, 9:22 PM

#

Nice, dann haben wir’s 😄

Klingt so, als wäre es wirklich nur der stale Chromium-Lock gewesen.
running: true + cdpReady: true + mehrere Tabs erfolgreich geöffnet ist genau das, was wir sehen wollten.

Wenn es nach einem späteren Container-Neustart nochmal auftaucht, würde ich als erstes wieder auf diese drei schauen:

SingletonLock
SingletonCookie
SingletonSocket

unter:

/data/.openclaw/browser/openclaw/user-data

Glad that helped! 🎉
Wenn das jetzt gefixt ist, bitte Rechtsklick auf die Lösungsnachricht → Apps → ✅ Mark Solution.

#

Dann landet es auch sauber in Answer Overflow für die Nächsten.

timid lodge Apr 17, 2026, 9:22 PM

#

Bevor ich Rechtsklick auf Solved klicke. Woher kommt sowas? Hab doch nur den 1-Click von Hostinger verwendet?

deep streamBOT Apr 17, 2026, 9:23 PM

#

Kurz gesagt: nicht weil du was falsch gemacht hast, und auch nicht unbedingt weil Hostinger “kaputt” ist.

Das kommt sehr wahrscheinlich von dieser Kombination:

OpenClaw speichert den Browser-Profilordner persistent unter /data/..., damit Sessions/Cookies erhalten bleiben
Chromium legt beim Start Singleton* Lock-Dateien/Symlinks an
Wenn der Container neu startet, updated, crasht oder hart beendet wird, verschwindet der echte Prozess und der /tmp-Socket
Die Locks im persistenten Volume bleiben aber liegen
Beim nächsten Start denkt Chromium dann:
“dieses Profil ist noch von einem anderen Chromium in Benutzung”

Genau das hat man bei dir gesehen:

SingletonLock -> dbd144e61f4c-8560
aber kein Chromium-Prozess mehr vorhanden

Also: stale Lock nach einem früheren unclean restart.

#

Das kann auch bei einem 1-Click Hostinger Setup passieren, weil das am Ende trotzdem ein Docker-Container mit persistentem Storage ist.
Der Installer ist also nicht “schuld”, das ist eher ein Chromium + persistent profile Edge Case.

Warum der Fix funktioniert hat:

wir haben nur die toten Lock-Links entfernt
danach konnte Chromium das Profil wieder normal öffnen

Wenn das öfter passiert, würde ich ehrlich gesagt ein GitHub Issue draus machen, weil OpenClaw das stale Singleton* Zeug beim Start vielleicht sauberer erkennen/aufräumen könnte:
https://github.com/openclaw/openclaw/issues

Und ja, wenn es jetzt sauber läuft, kannst du Solved markieren ✅

timid lodge Apr 17, 2026, 9:27 PM

#

Wenn das Problem in Zukunft auftaucht, welches sind die Befehle um das zu bereinigen? Oder sollte das NICHT mehr auftauchen?

deep streamBOT Apr 17, 2026, 9:27 PM

#

Es sollte nicht ständig auftauchen, aber nach einem unclean Container-Restart / Crash / Update kann es leider nochmal passieren.

Ich würde mir dafür diesen kleinen Spickzettel weglegen:

Schnell-Fix

Erst prüfen, ob wirklich kein Chromium mehr läuft:

ps aux | grep [c]hromium

Wenn da nichts zurückkommt, dann die stale Locks entfernen:

rm -f /data/.openclaw/browser/openclaw/user-data/SingletonLock \

#

      /data/.openclaw/browser/openclaw/user-data/SingletonCookie \
      /data/.openclaw/browser/openclaw/user-data/SingletonSocket

Dann testen:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs

Wenn das nicht reicht

Dann den ganzen isolierten OpenClaw-Browserprofilordner zurücksetzen
(Achtung: dabei gehen Logins/Cookies in diesem OpenClaw-Browserprofil verloren):

#

mv /data/.openclaw/browser/openclaw/user-data \
   /data/.openclaw/browser/openclaw/user-data.bak.$(date +%s)

mkdir -p /data/.openclaw/browser/openclaw/user-data
chown -R node:node /data/.openclaw/browser/openclaw

Danach nochmal:

openclaw browser --browser-profile openclaw start

Kurzregel

nur Singleton* löschen, wenn kein Chromium läuft

#

wenn’s danach noch klemmt, user-data umbenennen/resetten
wenn es regelmäßig passiert, dann würde ich echt ein GitHub-Issue machen

Wenn du willst, schreibe ich dir daraus noch eine 3-Zeilen-Notfall-Anleitung für Hostinger zum Abspeichern.

timid lodge Apr 17, 2026, 9:27 PM

#

Ja gerne

deep streamBOT Apr 17, 2026, 9:28 PM

#

Klar, hier ist die Hostinger-Notfall-Anleitung zum Abspeichern:

# 1) prüfen: läuft noch Chromium?
ps aux | grep [c]hromium

# 2) nur wenn oben NICHTS läuft: stale Locks löschen
rm -f /data/.openclaw/browser/openclaw/user-data/Singleton{Lock,Cookie,Socket}

# 3) Browser neu testen
openclaw browser --browser-profile openclaw start && openclaw browser --browser-profile openclaw tabs

Wenn Schritt 3 noch fehlschlägt, dann ist der nächste Schritt:
/data/.openclaw/browser/openclaw/user-data umbenennen/resetten.

Und wenn das Problem jetzt wirklich erledigt ist:

#

Rechtsklick auf die Lösungsnachricht → Apps → ✅ Mark Solution 🎉

timid lodge Apr 17, 2026, 9:29 PM

#

Danke. Dann kicke ich jetzt auf Solved. Vielen Dank, du bist der BESTE 😄

deep streamBOT Apr 17, 2026, 9:29 PM

#

Sehr gern 😄 freut mich, dass wir’s sauber erwischt haben.

Danke fürs Markieren, das hilft echt den Nächsten.
Und nice debugging von dir, du hast die wichtigen Outputs schnell geliefert 👌

#Mein OpenClaw Bot hat Probleme mit Browser