#Add Telegram Paring Code via Docker

1 messages · Page 1 of 1 (latest)

pure trenchBOT Feb 28, 2026, 9:11 PM

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

untold tartanBOT Feb 28, 2026, 9:12 PM

Telegram DM pairing is approved from the gateway host (in your case: inside the Docker setup), not by typing the code back into Telegram.

1) Generate the pairing request

Make sure Telegram is enabled (channels.telegram.enabled: true) and your bot token is set.
DM your Telegram bot (send any message, not just /start).

The bot should reply with an 8‑char pairing code (expires after ~1h).

2) Approve it via Docker

If you used the repo’s Docker Compose setup (docker-setup.sh), run the pairing commands via the CLI service:

docker compose run --rm openclaw-cli pairing list telegram
docker compose run --rm openclaw-cli pairing approve telegram <CODE>

After approving, DM the bot again — now it should actually process and reply.

(If you don’t have an openclaw-cli service, tell me your compose service names, and I’ll map the exact docker compose exec ... command.)

Docs:

https://docs.openclaw.ai/channels/telegram (Quick setup → approve first DM)
https://docs.openclaw.ai/channels/pairing (DM pairing)
https://docs.openclaw.ai/install/docker (Docker CLI helper patterns)

Dein OpenRouter “Token resetten” heißt praktisch: neuen Key bei OpenRouter erstellen und dann den alten Key in deiner Docker-OpenClaw-Config ersetzen (bitte nicht hier in Discord posten).

Variante A (empfohlen): Key in OpenClaw Auth-Profil speichern

Im Ordner mit deinem docker-compose.yml:

docker compose run --rm -it openclaw-cli models auth paste-token --provider openrouter

Dann den neuen sk-or-... Key einfügen.

Gateway neu starten:

docker compose restart openclaw-gateway

Check:

docker compose run --rm openclaw-cli models status

Variante B: Key kommt über Docker Compose `.env` / Environment

Wenn du OPENROUTER_API_KEY als Env Var an den Container übergibst (oft über eine .env neben der compose-Datei):

OPENROUTER_API_KEY=... in der .env aktualisieren
Container neu starten:

docker compose up -d --force-recreate openclaw-gateway

Wenn du sagst, ob du den Key aktuell als Env Var oder schon über models auth gesetzt hast (und wie deine Services heißen), kann ich dir die exakt passenden Commands für dein Setup geben.

Docs:

https://docs.openclaw.ai/gateway/authentication (openrouter paste-token)
https://docs.openclaw.ai/install/docker

Das “Auto configured models” in der Anzeige kostet erstmal nichts – Kosten entstehen nur, wenn OpenClaw diese Modelle wirklich benutzt (als Primary, Fallback, oder wenn du per /model dahin wechselst).

Wenn du sicherstellen willst, dass openrouter/auto nie benutzt wird:

1) Prüfen, ob es gerade als Primary/Fallback drin ist

docker compose run --rm openclaw-cli models status
docker compose run --rm openclaw-cli models fallbacks list

Wenn du da openrouter/auto siehst:

Fallbacks entfernen (empfohlen)

docker compose run --rm openclaw-cli models fallbacks remove openrouter/auto
# oder alles leer machen:

docker compose run --rm openclaw-cli models fallbacks clear

Primary explizit auf dein Modell setzen

docker compose run --rm openclaw-cli models set openrouter/<dein-modell>

2) Wenn es in der Config als “configured/allowlist” rumliegt: rauswerfen

docker compose run --rm openclaw-cli config unset 'agents.defaults.models["openrouter/auto"]'
docker compose run --rm openclaw-cli config unset 'agents.defaults.models["openrouter/arcee-ai/trinity-large-preview:free"]'

3) Gateway neu starten

docker compose restart openclaw-gateway

Wenn du mir kurz den Output von models status (ohne Tokens) postest, sag ich dir exakt, wo diese beiden Einträge bei dir herkommen (Primary vs Fallback vs allowlist).

openrouter/auto ist gefährlich nur insofern, dass es nicht auf “free” festgenagelt ist (kann dir also theoretisch auf ein bezahltes Modell routen, wenn es irgendwo ausgewählt wird – z.B. per Alias).

In deinem Output ist der Grund klar:

Aliases (1): OpenRouter -> openrouter/auto
und deshalb taucht openrouter/auto auch in Configured models auf.

So machst du’s “weg” (Docker Compose)

Alias entfernen (damit du nicht aus Versehen /model OpenRouter machst und auf openrouter/auto landest):

docker compose run --rm openclaw-cli models aliases remove OpenRouter

openrouter/auto aus der Modell-Allowlist entfernen:

docker compose run --rm openclaw-cli config unset 'agents.defaults.models["openrouter/auto"]'

Gateway neu starten:

docker compose restart openclaw-gateway

Check:

docker compose run --rm openclaw-cli models status

Danach solltest du sehen:

Default bleibt: openrouter/arcee-ai/trinity-large-preview:free
Aliases: 0

Configured models: nur noch dein Free-Modell (oder was du noch explizit allowlisten willst)

Wenn du willst, kannst du dir statt “OpenRouter” auch einen Alias auf dein Free-Modell legen (sicherer):

docker compose run --rm openclaw-cli models aliases add OpenRouter openrouter/arcee-ai/trinity-large-preview:free

Der Fehler kommt von der openclaw config Path-Syntax:

In agents.defaults.models["openrouter/auto"] werden die Anführungszeichen als Teil vom Key interpretiert. OpenClaw sucht dann wirklich nach dem Key "openrouter/auto" (mit Quotes) – den gibt’s nicht.

Nimm die Quotes im [...] weg:

docker compose run --rm openclaw-cli config unset 'agents.defaults.models[openrouter/auto]'

Optional (und sinnvoll), damit du nicht aus Versehen auf openrouter/auto routest:

Alias entfernen:

docker compose run --rm openclaw-cli models aliases remove OpenRouter

Gateway neu starten:

docker compose restart openclaw-gateway

Check:

docker compose run --rm openclaw-cli models status

Wenn du den Alias „OpenRouter“ behalten willst, setz ihn stattdessen explizit auf dein Free‑Model:

docker compose run --rm openclaw-cli models aliases add OpenRouter openrouter/arcee-ai/trinity-large-preview:free

Am einfachsten (Docker-Setup):

Token aus der Config auslesen

docker compose run --rm openclaw-cli config get gateway.auth.token

Oder: Dashboard-Link (inkl. Token-Hinweis) ausgeben

docker compose run --rm openclaw-cli dashboard --no-open

Falls leer / nicht gesetzt

Token nur generieren, wenn noch keiner existiert:

docker compose run --rm openclaw-cli doctor --generate-gateway-token

Wichtig: den Token hier nicht posten (wie ein Passwort behandeln).

disconnected (1006): no reason ist fast immer: der WebSocket kommt durch nginx nicht sauber durch (Upgrade/Timeout) oder OpenClaw blockt den Browser-Origin, weil du das UI nicht mehr von localhost öffnest.

1) nginx muss WebSockets upgraden + lange Timeouts haben

Minimaler nginx location / Block (so wie in den OpenClaw Docs):

location / {
    proxy_pass http://127.0.0.1:18789;
    proxy_http_version 1.1;

    # WebSocket support
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Standard proxy headers
    proxy_set_header Host $host;

    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # Long-lived WS connections
    proxy_read_timeout 86400s;
    proxy_send_timeout 86400s;
}

(Source: https://docs.openclaw.ai/install/exe-dev – die nginx snippet ist generisch und gilt auch für dein Setup)

2) OpenClaw: Origin-Allowlist setzen (sonst non-loopback UI wird geblockt)

Wenn du das Dashboard über https://dein-host.tld aufrufst, muss das als Origin erlaubt sein:

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins \
  '["https://dein-host.tld"]' --strict-json

docker compose restart openclaw-gateway

Wichtig: In allowedOrigins steht nur scheme://host[:port] (ohne Pfad).

3) Token im Dashboard neu setzen

Wenn du von localhost auf die nginx-Domain wechselst, ist es ein anderer Origin → der Token in LocalStorage ist weg. Also im Control UI nochmal den gateway.auth.token eintragen.

Wenn es danach noch 1006 ist: poste mal (ohne Secrets) deinen nginx location-Block und sag, ob du unter / proxyst oder unter einem Prefix wie /openclaw (dann braucht man ggf. zusätzlich gateway.controlUi.basePath).

Ja – aber es gibt dabei zwei verschiedene “URLs”/Sicherheits-Themen:

1) “Main URL” im Sinne von: von welcher Domain darf das Dashboard per WebSocket verbinden?

Dafür ist nicht eine “main url” gedacht, sondern:

gateway.controlUi.allowedOrigins → welche Browser-Origin(s) dürfen den Gateway-WebSocket nutzen

Wenn du das Dashboard über Nginx Proxy Manager unter https://claw.example.com auslieferst:

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins \
  '["https://claw.example.com"]' --strict-json

docker compose restart openclaw-gateway

Das ist meistens der Fix gegen “disconnected”, wenn du nicht mehr von localhost kommst.

Docs: https://docs.openclaw.ai/web/control-ui (allowedOrigins)

2) “Auth hängt davor (NPM), damit nicht jeder drauf kommt”

Das ist ok als zusätzliche Schicht (Basic Auth / Access List / OAuth im Proxy). Aber:

OpenClaw selbst hat eigene Gateway-Auth (Token/Password) – die würde ich nicht abschalten, sondern als zweiten Riegel drin lassen.
Wenn du “Proxy macht Auth und OpenClaw vertraut dem Proxy” willst: das ist gateway.auth.mode: "trusted-proxy", aber dafür brauchst du einen identity-aware Proxy, der User-Header setzt (z.B. oauth2-proxy/Pomerium). Nginx Proxy Manager “Basic Auth” allein liefert diese Identität nicht in der Form.

Docs: https://docs.openclaw.ai/gateway/trusted-proxy-auth

3) Wichtig: der Gateway-Port darf nicht “vorbei am Proxy” erreichbar sein

Sonst kann jemand den Proxy umgehen. Also am Host/Firewall nur NPM nach außen, und OpenClaw-Port intern lassen (Docker network / localhost).

Wenn du willst, paste (ohne Secrets) kurz:

welche Domain (https://…) du nutzt
ob du unter / proxyst oder unter einem Prefix wie /openclaw
Dann sag ich dir, ob du zusätzlich gateway.controlUi.basePath brauchst und wie das im NPM am saubersten aussieht.

Der Fehler kommt von Shell-Quoting: dein JSON-Array wird bei dir offenbar in mehrere Argumente zerlegt, daher sieht openclaw config set dann 3 statt 2 Argumente.

Nimm die JSON-Liste als ein Argument in Quotes, z.B. so (einzeilig):

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["https://claw.example.com"]' --strict-json

Alternative (falls du lieber mit " arbeitest):

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins "[\"https://claw.example.com\"]" --strict-json

Danach Gateway neu starten:

docker compose restart openclaw-gateway

Hinweis: In allowedOrigins muss wirklich das exakte Origin stehen (https://… inkl. Port falls nicht 443). Wenn du sowohl http als auch https testest, musst du beide eintragen.

brisk dawn Feb 28, 2026, 9:41 PM

untold tartan Der Fehler kommt von **Shell-Quoting**: dein JSON-Array wird bei dir offenbar in...

was muss ich aber dann bei websocket url eintragen? 127.0.0.1 die domain oder die ip the er von der docker bridge bekommen hat

untold tartanBOT Feb 28, 2026, 9:42 PM

Für die WebSocket URL im Dashboard gilt: du trägst immer die Adresse ein, wie dein Browser den Gateway erreichen soll.

Wenn du übers Nginx Proxy Manager von außen drauf gehst

Dann nimm die Domain (und bei HTTPS automatisch wss):

Dashboard läuft auf: https://claw.example.com
WebSocket URL im Control UI: wss://claw.example.com

Wenn du (warum auch immer) nur HTTP hast:

http://claw.example.com → ws://claw.example.com

Was du nicht nehmen solltest

127.0.0.1 → geht nur, wenn der Browser auf derselben Maschine läuft (oder du per SSH tunnelst).
Docker-Bridge-IP (z.B. 172.18.x.x) → ist intern, ändert sich gern und ist für den Browser normalerweise nicht erreichbar.

Wichtig bei NPM

Im Proxy Host “Websockets Support” aktivieren und als Upstream den OpenClaw Container/Host + Port 18789 verwenden (intern).
Wenn das stimmt und gateway.controlUi.allowedOrigins auf https://claw.example.com gesetzt ist, sollte das Dashboard verbinden.

Wenn du magst: sag mir kurz, ob dein Dashboard unter / läuft oder unter einem Pfad wie /openclaw – das ändert, ob du zusätzlich gateway.controlUi.basePath brauchst.

Wenn du das Dashboard über Nginx Proxy Manager + Auth auslieferst und es verbindet trotzdem nicht, sind’s fast immer diese 4 Dinge:

1) In der UI als WebSocket URL wirklich nur die Domain (ohne Pfad) eintragen

Im Control UI Feld Gateway URL / WebSocket URL:

wss://claw.example.com ✅
nicht https://claw.example.com (falsches Protokoll)
nicht wss://claw.example.com/irgendwas (normalerweise kein Pfad)

2) OpenClaw muss für Remote/Proxy-Origin freigeschaltet sein

gateway.controlUi.allowedOrigins muss exakt dein Origin enthalten:

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["https://claw.example.com"]' --strict-json
docker compose restart openclaw-gateway

Wichtig: kein Slash am Ende, ggf. Port dazu (z.B. https://claw.example.com:8443).

3) NPM muss WebSockets wirklich durchlassen (und zum richtigen Upstream sprechen)

In Nginx Proxy Manager beim Proxy Host:

Websockets Support: ON
Scheme zum Upstream: http (OpenClaw spricht intern normalerweise kein https)
Upstream Host/Port muss aus dem NPM-Container erreichbar sein:
- wenn NPM + OpenClaw in derselben docker network sind: Host = openclaw-gateway (Compose Service-Name), Port = 18789
- wenn NPM auf dem Host läuft: Host = 127.0.0.1, Port = 18789 (nur wenn Port gemappt ist)

Wenn der Upstream falsch ist, lädt die HTML-Seite ggf. noch, aber der WS bricht (1006).

4) Auth in NPM (Access List / Basic Auth) kann den WS-Handshake blocken

Das kann funktionieren, aber wenn’s nicht tut, siehst du im Browser oft 1006.

Bestes Debugging:

Dann bist du schon fast da — das ist jetzt Device Pairing fürs Dashboard (nicht Telegram DM pairing).

1) Pending Device Requests anzeigen (im Docker Setup)

docker compose run --rm openclaw-cli devices list

Da siehst du ein requestId.

2) Approven

docker compose run --rm openclaw-cli devices approve <requestId>

Danach im Browser einfach neu laden / reconnecten.

Docs: https://docs.openclaw.ai/channels/pairing (Abschnitt “Node device pairing” + Devices approve)

Du bekommst den Fehler, weil openclaw-cli in einem eigenen Container läuft – 127.0.0.1:18789 zeigt dort auf den CLI-Container selbst, nicht auf den Gateway-Container. Deshalb klappt devices list nur, wenn du explizit zum Gateway-Service connectest.

Device-Pairing aus Docker heraus (funktioniert sicher)

docker compose run --rm openclaw-cli devices list \
  --url ws://openclaw-gateway:18789 \
  --token "$OPENCLAW_GATEWAY_TOKEN"

Dann approve (am einfachsten “latest”):

docker compose run --rm openclaw-cli devices approve --latest \
  --url ws://openclaw-gateway:18789 \
  --token "$OPENCLAW_GATEWAY_TOKEN"

Danach im Browser einfach reload/reconnect.

Hinweis: Die CLAUDE_* WARNs kannst du ignorieren – die haben damit nichts zu tun.

Der 1006 kommt hier daher, dass du mit --url wss://openclaw.hanz.de durch deinen Nginx Proxy Manager (inkl. Auth) gehst. Im Browser klappt das (weil der Browser die Proxy-Auth mitschickt), aber der openclaw CLI schickt diese NPM-Auth normalerweise nicht → der Proxy liefert dann z.B. 401/302/HTML statt „WebSocket Upgrade“, und der Client sieht nur „abnormal closure (1006)“.

Für devices pairing mach’s am besten intern im Docker-Netz, am Proxy vorbei:

docker compose run --rm openclaw-cli devices list \
  --url ws://openclaw-gateway:18789 \
  --token "$OPENCLAW_GATEWAY_TOKEN"

Dann approve (latest reicht):

docker compose run --rm openclaw-cli devices approve --latest \
  --url ws://openclaw-gateway:18789 \
  --token "$OPENCLAW_GATEWAY_TOKEN"

Wenn OPENCLAW_GATEWAY_TOKEN bei dir nicht im Shell-Env ist: liegt meistens in deiner .env (die docker-setup.sh schreibt). Alternativ aus der Config holen:

docker compose run --rm openclaw-cli config get gateway.auth.token

Wenn du unbedingt über die Domain pairen willst, müsstest du die NPM-Auth für WebSockets/CLI irgendwie umgehen (separater Host ohne NPM-Auth, IP-allowlist, oder trusted-proxy setup). Für “einmal device approve” ist der interne ws://openclaw-gateway:18789 Weg der stressfreie.

Das ist kein Bug, sondern Absicht: OpenClaw blockt ws:// zu nicht-loopback (also z.B. ws://172.17.x.x) aus Security-Gründen. In Docker ist die Service-IP eben so eine nicht-loopback Adresse → daher der Fehler.

Die Lösung ist: führe den Devices-CLI im Gateway-Container aus, dann ist 127.0.0.1:18789 wirklich loopback und erlaubt.

1) Pending Device Requests im Gateway-Container anzeigen

docker compose exec openclaw-gateway node dist/index.js devices list

2) Neueste Anfrage approve’n

docker compose exec openclaw-gateway node dist/index.js devices approve --latest

Dann im Browser Dashboard neu laden → es sollte verbunden bleiben.

Wenn docker compose exec ... sagt der Container läuft nicht: erst starten

docker compose up -d openclaw-gateway

Das heißt: CLI und Gateway benutzen gerade zwei unterschiedliche Tokens.

In Docker ist das typisch, weil:

der Gateway config-first nimmt (gateway.auth.token in openclaw.json)
dein Container aber zusätzlich OPENCLAW_GATEWAY_TOKEN als Env hat
→ wenn die zwei Werte nicht identisch sind, kommt genau: unauthorized: gateway token mismatch.

Fix (ohne Token hier zu posten)

Token aus der Config anschauen (lokal bei dir, nicht hier rein kopieren):

docker compose run --rm openclaw-cli config get gateway.auth.token

Check, was Docker als Env-Token nutzt:

docker compose exec openclaw-gateway sh -lc 'echo "$OPENCLAW_GATEWAY_TOKEN"'

Wenn die nicht gleich sind, musst du sie angleichen. Empfehlung: nimm einen als “Source of Truth” (meist die Config) und setz den anderen darauf.

Option A (meist am saubersten): Env-Token an die Config anpassen

In deiner .env (die Docker Compose lädt) OPENCLAW_GATEWAY_TOKEN=... auf den Wert aus Schritt 1 setzen
Dann Gateway neu starten:

docker compose up -d --force-recreate openclaw-gateway

Option B: Config-Token an die Env anpassen (ändert den Token!)

docker compose run --rm openclaw-cli config set gateway.auth.token "$OPENCLAW_GATEWAY_TOKEN"

docker compose restart openclaw-gateway

Danach musst du im Dashboard evtl. den Token neu eintragen (weil er sich geändert hat).

Danach klappt Device Pairing wieder:

docker compose exec openclaw-gateway node dist/index.js devices list
docker compose exec openclaw-gateway node dist/index.js devices approve --latest

Wenn du mir sagst, ob du .env benutzt (und ob da OPENCLAW_GATEWAY_TOKEN drinsteht), kann ich dir sagen, welche der beiden Optionen in deinem Setup weniger “Folgeschäden” hat.

Das Redacted-Output ist gut (Token nicht leaken). Dein Problem ist jetzt:

Gateway (Server) nimmt gateway.auth.token aus der Config (config-first)
CLI (Client) nimmt OPENCLAW_GATEWAY_TOKEN aus der Env (env-first)

Wenn die zwei nicht identisch sind → 1008 unauthorized: gateway token mismatch.

Schnellster Fix: Config-Token entfernen, dann nutzt alles den `.env` Token

(du musst keinen Token irgendwo kopieren)

docker compose run --rm openclaw-cli config unset gateway.auth.token
docker compose restart openclaw-gateway

Danach im Gateway-Container pairen:

docker compose exec openclaw-gateway node dist/index.js devices list
docker compose exec openclaw-gateway node dist/index.js devices approve --latest

Im Dashboard musst du dann den Token verwenden, der in deiner .env steht (OPENCLAW_GATEWAY_TOKEN) – weil gateway.auth.token jetzt weg ist.

Wenn du lieber umgekehrt willst (Config als Source of Truth), sag kurz Bescheid – dann machen wir’s “Env an Config angleichen”, ohne den Token hier zu posten.

Wenn du gateway.auth.token gerade unsets hast, kommt der Token jetzt aus der .env / Env-Variable (OPENCLAW_GATEWAY_TOKEN).

Token anzeigen (Host)

Im Ordner mit deinem docker-compose.yml:

grep '^OPENCLAW_GATEWAY_TOKEN=' .env

Token anzeigen (aus dem laufenden Gateway-Container)

docker compose exec openclaw-gateway sh -lc 'echo "$OPENCLAW_GATEWAY_TOKEN"'

Falls du wirklich einen neuen Token generieren willst (Rotation):

docker compose run --rm openclaw-cli config set gateway.auth.token "$(openssl rand -hex 32)"
docker compose restart openclaw-gateway

(Und dann wieder mit config get gateway.auth.token anzeigen.)

Das ist (leider) ein Control‑UI Anzeigeproblem, kein “Telegram ist kaputt”.

Diese rote Box „Unsupported schema node. Use Raw mode.” kommt vom Form‑Renderer in der Web‑UI (der kann manche Config‑Schema‑Teile – z.B. Telegram “Accounts” – nicht als hübsche Formularfelder darstellen). Die Telegram‑Integration kann trotzdem ganz normal laufen.

Was du machen kannst:

Ignorieren, wenn Telegram schon funktioniert (Polling/Probe OK).
Wenn du dort was ändern willst: in der Control UI bei der Config/Channels Ansicht auf Raw mode / Raw umschalten und die JSON5 direkt editieren. (Also nicht im “Form” Modus.)

Wenn du mir sagst, auf welcher Seite/Section du die Meldung siehst (Channels → Telegram → Accounts?), kann ich dir genau sagen, wo der Raw‑Toggle sitzt und welche Keys du dort eintragen solltest.

Skills sind einfach Ordner mit einem SKILL.md (plus evtl. Dateien) und liegen bei OpenClaw in einem von diesen Pfaden:

Per-Agent (Workspace): <workspace>/skills (empfohlen, weil versionierbar / pro Agent)
Shared (managed): ~/.openclaw/skills (sichtbar für alle Agents auf dem Host)

Bei deinem Docker-Compose Setup sind das auf dem Host typischerweise:

OPENCLAW_WORKSPACE_DIR/skills
OPENCLAW_CONFIG_DIR/skills

(steht in deiner .env neben dem docker-compose.yml)

Variante A (empfohlen): via ClawHub installieren

ClawHub CLI auf dem Host installieren:

npm i -g clawhub

# oder: pnpm add -g clawhub

In dein Workspace-Verzeichnis wechseln (Host-Pfad aus .env):

cd "$(grep '^OPENCLAW_WORKSPACE_DIR=' .env | cut -d= -f2-)"

Skill installieren (kommt dann nach ./skills/<slug>/...):

clawhub install <skill-slug>

Neue Session starten, damit OpenClaw die Skills neu snapshottet:

in Telegram/Discord: /new (oder Gateway neu starten)

Variante B: manuell (ohne ClawHub)

Skill-Ordner nach OPENCLAW_WORKSPACE_DIR/skills/<skillname>/ kopieren (muss SKILL.md enthalten), dann /new.

Docs:

Wenn du mir sagst, welchen Skill du installieren willst (ClawHub slug/Link), sag ich dir den exakten Pfad + Command für dein Setup.

“Network connection lost” ist fast immer WebChat/Dashboard verliert die WebSocket‑Verbindung zum Gateway (nicht “Skill kaputt”). Zwei häufige Ursachen in deinem Docker+Nginx‑Setup:

A) Token geändert → Dashboard hat noch den alten Token gespeichert

Du hast ja gateway.auth.token entfernt und nutzt jetzt den Token aus .env (OPENCLAW_GATEWAY_TOKEN). Das Dashboard speichert den Token pro Domain im Browser → nach Token-Wechsel musst du ihn dort neu setzen.

Token am Host anzeigen:

grep '^OPENCLAW_GATEWAY_TOKEN=' .env

Dann im Dashboard: Control → Overview → Gateway Access (Token Feld) → den Token einfügen → Connect.

B) Nginx Proxy Manager killt/blocked WebSockets (Auth/Timeout)

In NPM sicherstellen:

“Websockets Support” = ON
proxy_read_timeout hoch (sonst fliegt die WS Verbindung raus)
Auth darf den WS‑Upgrade nicht auf eine HTML Login-Seite umleiten

Debug (zeigt sofort, was es ist)

Lass das Gateway-Log laufen und schick dann eine Nachricht im Dashboard:

docker compose logs -f --tail=200 openclaw-gateway

Wenn du magst, paste die letzten ~30 Zeilen nach dem Disconnect (ohne Tokens). Dann kann man sehen ob es unauthorized, origin not allowed, Proxy-Reset, etc. ist.

Zusatz-Check ob der Gateway Container überhaupt stabil läuft:

docker compose ps

2M Tokens nach “ein paar Nachrichten” ist nicht der Normalfall, aber es kann passieren – OpenClaw schickt bei jedem Run nicht nur deine Nachricht, sondern auch:

System-Prompt + Tool-Liste
Skill-Liste (Metadaten)
Workspace/Bootstrap-Dateien (AGENTS/SOUL/USER/MEMORY usw.)
kompletten Chat-Verlauf + Tool-Outputs

Wenn du z.B. irgendwo viel Text drin hast (lange Logs gepastet, große MEMORY/AGENTS, große Tool-Ergebnisse), explodieren die Input-Tokens schnell.

Erstmal klären: Wo siehst du “2M tokens”?

OpenRouter Dashboard (gesamt über Zeit/alle Requests)?
oder in OpenClaw per /status bzw. /usage?

Schnellster Debug-Check (in dem Chat mit dem Bot)

Schalte per-response Anzeige an:

/usage tokens

Schreib danach nur „ping“.
Dann siehst du direkt, ob:

Input-Tokens riesig sind → Kontext/Systemprompt ist zu groß
Output-Tokens riesig sind → verbose/reasoning/zu lange Antworten

Wenn Input riesig ist:

/context detail

Damit siehst du, was den Kontext so aufbläht.

Häufige Ursachen + Fixes

Verbose/Reasoning an → /verbose off und /reasoning off

Sehr langer Verlauf → /compact oder /new
Große Tool-Outputs / Logs → weniger in den Chat pasten, lieber als Datei/Link oder vorher kürzen

Wenn du mir den Screenshot/Output von /usage tokens nach einem “ping” (ohne Secrets) gibst, kann ich dir sagen, ob es “nur” riesiger Input-Kontext ist oder ob bei dir irgendwas looped.

untold tartanBOT Feb 28, 2026, 11:30 PM

Ja – bei OpenRouter kannst du (für ein OpenRouter‑Modell) die Provider‑Routing Preferences setzen (z.B. “nur Provider X benutzen” oder “Reihenfolge bevorzugen”). Das läuft über den OpenRouter API‑Request provider: {...} und OpenClaw kann das über Model-Params weiterreichen.

In OpenClaw (Config) pro Modell festlegen

In openclaw.json unter dem Model‑Eintrag:

{
  agents: {
    defaults: {
      models: {
        "openrouter/<model-id>": {
          params: {
            provider: {
              only: ["<provider-name>"],
              allow_fallbacks: false
            }

only: erzwingt einen bestimmten OpenRouter‑Provider
order: (Alternative) bevorzugte Reihenfolge
allow_fallbacks: false: verhindert, dass OpenRouter heimlich auf andere Provider ausweicht

Welche Provider-Namen gültig sind, steht in den OpenRouter “provider routing” Docs (die Namen sind OpenRouter-spezifisch, nicht OpenClaw).

Mit deinem Docker-Setup setzen (Beispiel)

(ersetze <model-id> und <provider-name>)

#Add Telegram Paring Code via Docker

1) Generate the pairing request

2) Approve it via Docker

Variante A (empfohlen): Key in OpenClaw Auth-Profil speichern

Variante B: Key kommt über Docker Compose .env / Environment

1) Prüfen, ob es gerade als Primary/Fallback drin ist

Fallbacks entfernen (empfohlen)

Primary explizit auf dein Modell setzen

2) Wenn es in der Config als “configured/allowlist” rumliegt: rauswerfen

3) Gateway neu starten

So machst du’s “weg” (Docker Compose)

Token aus der Config auslesen

Oder: Dashboard-Link (inkl. Token-Hinweis) ausgeben

Falls leer / nicht gesetzt

1) nginx muss WebSockets upgraden + lange Timeouts haben

2) OpenClaw: Origin-Allowlist setzen (sonst non-loopback UI wird geblockt)

3) Token im Dashboard neu setzen

1) “Main URL” im Sinne von: von welcher Domain darf das Dashboard per WebSocket verbinden?

2) “Auth hängt davor (NPM), damit nicht jeder drauf kommt”

3) Wichtig: der Gateway-Port darf nicht “vorbei am Proxy” erreichbar sein

Wenn du übers Nginx Proxy Manager von außen drauf gehst

Was du nicht nehmen solltest

Wichtig bei NPM

1) In der UI als WebSocket URL wirklich nur die Domain (ohne Pfad) eintragen

2) OpenClaw muss für Remote/Proxy-Origin freigeschaltet sein

3) NPM muss WebSockets wirklich durchlassen (und zum richtigen Upstream sprechen)

4) Auth in NPM (Access List / Basic Auth) kann den WS-Handshake blocken

1) Pending Device Requests anzeigen (im Docker Setup)

2) Approven

Device-Pairing aus Docker heraus (funktioniert sicher)

1) Pending Device Requests im Gateway-Container anzeigen

2) Neueste Anfrage approve’n

Fix (ohne Token hier zu posten)

Option A (meist am saubersten): Env-Token an die Config anpassen

Option B: Config-Token an die Env anpassen (ändert den Token!)

Schnellster Fix: Config-Token entfernen, dann nutzt alles den .env Token

Token anzeigen (Host)

Token anzeigen (aus dem laufenden Gateway-Container)

Variante A (empfohlen): via ClawHub installieren

Variante B: manuell (ohne ClawHub)

A) Token geändert → Dashboard hat noch den alten Token gespeichert

B) Nginx Proxy Manager killt/blocked WebSockets (Auth/Timeout)

Debug (zeigt sofort, was es ist)

Erstmal klären: Wo siehst du “2M tokens”?

Schnellster Debug-Check (in dem Chat mit dem Bot)

Häufige Ursachen + Fixes

In OpenClaw (Config) pro Modell festlegen

Mit deinem Docker-Setup setzen (Beispiel)

Variante B: Key kommt über Docker Compose `.env` / Environment

Schnellster Fix: Config-Token entfernen, dann nutzt alles den `.env` Token