Updating openclaw on vps in docker from 4.15 to latest. | Friends of the Crustacean 🦞🤝 | Page 1

weary cradle May 24, 2026, 4:59 PM

#

Hi @next rover I haven't updated for a while but would like to now. My claw is running in a small vps in a docker container. My idea was to update and run the doctor afterwards.

Would you additionally suggest anything that I should do or be aware of?

half berryBOT May 24, 2026, 4:59 PM

#

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

exotic cairnBOT May 24, 2026, 4:59 PM

#

next roverBOT May 24, 2026, 4:59 PM

#

weary cradle Hi <@1457407575476801641> I haven't updated for a while but would like to now. M...

Yep, your plan is basically right. I’d add a couple of boring-but-important steps because Docker updates are mostly about preserving the mounted state.

Suggested order:

Check exactly what you’re on:

docker compose run --rm openclaw-cli --version

Back up the persisted OpenClaw state before touching the image/container. Usually that’s your bind mount or Docker volume for ~/.openclaw / /home/node/.openclaw, plus your .env and compose files. Don’t rely on the container filesystem itself unless you know your state is mounted.
Pull/build the new image, depending on how you installed:

docker compose pull
docker compose up -d

or, if you’re using the repo setup script / local build flow, rerun the Docker setup/update flow from the repo root. Docker docs are here: https://docs.openclaw.ai/install/docker

next roverBOT May 24, 2026, 4:59 PM

#

weary cradle Hi <@1457407575476801641> I haven't updated for a while but would like to now. M...

After the gateway is back up, run health checks:

curl -fsS http://127.0.0.1:18789/readyz
docker compose run --rm openclaw-cli doctor

If doctor reports migrations/repairs, I’d first read the output, then run the fix mode intentionally:

docker compose run --rm openclaw-cli doctor --fix

Two things I’d watch for from an older 2026.4.15-ish install: config/state migrations, and plugin dependency cleanup. Doctor is the right tool for that, and if anything looks like a real bug after the update, file it here rather than trying to patch around it in-place: https://github.com/openclaw/openclaw/issues

Relevant docs:
https://docs.openclaw.ai/install/updating
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/install/docker

weary cradle May 25, 2026, 12:11 PM

#

Update went through, but Minimax does no longer work. I receive the following log:
openclaw-gateway | 2026-05-25T12:03:28.538+00:00 [agent/embedded] embedded run agent end: runId=5ff77fb6-28c4-436a-8adf-fcbbe2d067a3 isError=true model=MiniMax-M2.7 provider=minimax-portal error=The provider returned an HTML error page instead of an API response. This usually means a CDN or gateway (e.g. Cloudflare) blocked the request. Retry in a moment or check provider status. rawError=404 <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>
openclaw-gateway | 2026-05-25T12:03:28.649+00:00 [agent/embedded] auth profile failure state updated: runId=5ff77fb6-28c4-436a-8adf-fcbbe2d067a3 profile=sha256:9e08bd6be9c1 provider=minimax-portal reason=model_not_found window=cooldown reused=false
openclaw-gateway | 2026-05-25T12:03:28.655+00:00 [agent/embedded] embedded run failover decision: runId=5ff77fb6-28c4-436a-8adf-fcbbe2d067a3 stage=assistant decision=fallback_model reason=model_not_found from=minimax-portal/MiniMax-M2.7 profile=sha256:9e08bd6be9c1 rawError=404 <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>
openclaw-gateway | 2026-05-25T12:03:28.658+00:00 [diagnostic] lane task error: lane=main durationMs=4676 error="FailoverError: The provider returned an HTML error page instead of an API response. This usually means a CDN or gateway (e.g. Cloudflare) blocked the request. Retry in a moment or check provider status."

next roverBOT May 25, 2026, 12:12 PM

#

weary cradle Update went through, but Minimax does no longer work. I receive the following lo...

That log is coming from the MiniMax OAuth provider path: provider=minimax-portal and from=minimax-portal/MiniMax-M2.7.

A raw 404 <html> ... nginx usually means OpenClaw reached MiniMax’s HTTP edge but did not get an API JSON response. That is different from “bad key” or “expired token”; it smells like the MiniMax portal/OAuth route or region endpoint is not accepting that request.

First checks:

openclaw --version
openclaw models status --probe --probe-provider minimax-portal
openclaw models list --provider minimax-portal

If you used MiniMax OAuth/Coding Plan, try re-authing the same region:

openclaw onboard --auth-choice minimax-global-oauth
# or, if you use the China endpoint:
openclaw onboard --auth-choice minimax-cn-oauth

next roverBOT May 25, 2026, 12:12 PM

#

weary cradle Update went through, but Minimax does no longer work. I receive the following lo...

Fast workaround: switch MiniMax from OAuth (minimax-portal/...) to API-key auth (minimax/...) and restart the container/gateway:

openclaw onboard --auth-choice minimax-global-api
# or:
openclaw onboard --auth-choice minimax-cn-api

Docs I checked:
https://docs.openclaw.ai/providers/minimax
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/help/faq

If models status --probe still shows model_not_found / HTML 404 on latest, please file it with the version + this log here: https://github.com/openclaw/openclaw/issues. That gives maintainers the exact provider/region failure without exposing tokens.

weary cradle May 25, 2026, 12:14 PM

#

I don't want to pay via api. I have the token plan active and want to use it. Isn't there another opportunity?
This is the minimax entry in my openclaw.json:
"minimax-portal": {
"baseUrl": "https://api.minimax.io/v1",
"models": []
}

is something wrong in here?

next roverBOT May 25, 2026, 12:15 PM

#

weary cradle I don't want to pay via api. I have the token plan active and want to use it. Is...

Yes, that entry is likely the problem.

For minimax-portal / OAuth Coding Plan chat, the current docs/source expect the Anthropic-compatible route, not /v1, and models: [] can leave OpenClaw with no usable chat model for that provider.

I would either remove that manual minimax-portal block and let OAuth onboarding inject it, or change it to something shaped like:

"minimax-portal": {
  "baseUrl": "https://api.minimax.io/anthropic",
  "api": "anthropic-messages",
  "authHeader": true,
  "apiKey": "MINIMAX_OAUTH_TOKEN",
  "models": [
    {
      "id": "MiniMax-M2.7",
      "name": "MiniMax M2.7",

next roverBOT May 25, 2026, 12:15 PM

#

weary cradle I don't want to pay via api. I have the token plan active and want to use it. Is...

      "reasoning": true,
      "input": ["text", "image"],
      "contextWindow": 204800,
      "maxTokens": 131072
    },
    {
      "id": "MiniMax-M2.7-highspeed",
      "name": "MiniMax M2.7 Highspeed",
      "reasoning": true,
      "input": ["text", "image"],
      "contextWindow": 204800,
      "maxTokens": 131072
    }
  ]
}

next roverBOT May 25, 2026, 12:15 PM

#

weary cradle I don't want to pay via api. I have the token plan active and want to use it. Is...

Then keep your default model as:

agents: {
  defaults: {
    model: { primary: "minimax-portal/MiniMax-M2.7" }
  }
}

After changing it, restart the Docker container/gateway and check:

openclaw models list --provider minimax-portal
openclaw models status --probe --probe-provider minimax-portal

next roverBOT May 25, 2026, 12:15 PM

#

weary cradle I don't want to pay via api. I have the token plan active and want to use it. Is...

If you don’t want to hand-edit: run OAuth onboarding again instead, not API-key onboarding:

openclaw onboard --auth-choice minimax-global-oauth

Docs: https://docs.openclaw.ai/providers/minimax

weary cradle May 25, 2026, 12:33 PM

#

Nach ausführen von:
openclaw models status --probe --probe-provider minimax-portal
erhalte ich als Ergebnis:
Auth probes
┌──────────────────┬────────────────────────┬──────────────────────────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────┼────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
│ minimax-portal/ │ minimax- │ unknown · 1.3s │
│ MiniMax-M2.7 │ portal:default (oauth) │ ↳ Auth profile "minimax-portal:default" is not configured for minimax- │
│ │ │ portal. │
└──────────────────┴────────────────────────┴──────────────────────────────────────────────────────────────────────────┘

next roverBOT May 25, 2026, 12:34 PM

#

weary cradle Nach ausführen von: openclaw models status --probe --probe-provider minimax-port...

Ja, das ist jetzt ein anderer Hinweis: Dein Modell wird gefunden, aber das OAuth-Profil ist nicht sauber für minimax-portal verdrahtet.

Die relevante Zeile ist:

Auth profile "minimax-portal:default" is not configured for minimax-portal.

Das bedeutet meist: In der Auth-Profile-Konfiguration gibt es zwar einen gespeicherten Token/Profileintrag, aber openclaw.json hat kein passendes auth.profiles["minimax-portal:default"] mit Provider minimax-portal, oder ein altes/migriertes Profil zeigt auf den falschen Provider.

Ich würde jetzt nicht auf API-Key wechseln. Für Coding Plan/OAuth:

Entferne/ersetze den manuellen models.providers.minimax-portal Block mit baseUrl: ".../v1". Für Chat sollte das /anthropic sein.
Lass OAuth die Profilverdrahtung neu schreiben:

openclaw onboard --auth-choice minimax-global-oauth

next roverBOT May 25, 2026, 12:34 PM

#

weary cradle Nach ausführen von: openclaw models status --probe --probe-provider minimax-port...

Für China-Endpoint entsprechend:

openclaw onboard --auth-choice minimax-cn-oauth

Danach Gateway/Docker neu starten und nochmal:

openclaw models list --provider minimax-portal
openclaw models status --probe --probe-provider minimax-portal

Wenn du manuell in openclaw.json schaust: Es sollte sinngemäß ein Auth-Profil für minimax-portal:default existieren, das als Provider minimax-portal hat. Poste aber bitte keine Tokens/Secrets.

Docs dazu:
https://docs.openclaw.ai/providers/minimax

next roverBOT May 25, 2026, 12:34 PM

#

weary cradle Nach ausführen von: openclaw models status --probe --probe-provider minimax-port...

https://docs.openclaw.ai/cli/models

weary cradle May 25, 2026, 12:47 PM

#

der oauth hat funktioniert. jetzt reagiert allerdings telegram zwar noch auf befehle wie /status, aber nicht mehr auf meine nachrichten. den doctor habe ich bereits laufen lassen. das hats nicht gelöst. Hilft der output am Ende weiter?
Health check failed: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: loopback
│
◇ Gateway port ───────────────────────────────────────────────────────────────╮
│ │
│ Port 18789 is already in use. │
│ - pid 8 node: node dist/index.js gateway --bind lan --port 18789 (*:18789) │
│ - Another process is listening on this port. │
│ │
├──────────────────────────────────────────────────────────────────────────────╯
│
◇ Gateway ────────────────────────────────────────────────────────────────────────────────╮
│ │
│ 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. │
│ │
├──────────────────────────────────────────────────────────────────────────────────────────╯

next roverBOT May 25, 2026, 12:48 PM

#

weary cradle der oauth hat funktioniert. jetzt reagiert allerdings telegram zwar noch auf bef...

Ja, der Output hilft. Wichtig: /status ist ein Command und braucht keinen normalen Agent-Run. Normale Telegram-Nachrichten gehen durch Routing + Agent/Model. Wenn Commands gehen, aber freie Nachrichten nicht, ist Telegram nicht komplett tot.

Der Doctor-Block sagt wahrscheinlich zwei Dinge:

Port 18789 is already in use ... node dist/index.js gateway --bind lan ist im Docker-Setup erwartbar: der Gateway läuft schon im Foreground. Also im Container nicht zusätzlich openclaw gateway starten.
Health check failed: gateway timeout after 10000ms ist der echte rote Hinweis. Der Gateway antwortet nicht schnell genug auf Health/RPC. Das kann ein hängender Agent-Run, ein blockierter Main-Lane-Task oder ein Provider-Failover sein.

Ich würde jetzt so vorgehen:

openclaw --version
openclaw health --verbose --timeout 60000
openclaw channels status --probe

Dann eine normale Telegram-Nachricht senden und parallel Logs schauen:

next roverBOT May 25, 2026, 12:48 PM

#

weary cradle der oauth hat funktioniert. jetzt reagiert allerdings telegram zwar noch auf bef...

openclaw logs --follow

Falls openclaw logs wegen Health/RPC auch hängt, nimm Docker direkt:

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

In den Logs besonders nach diesen Wörtern suchen:

telegram
drop
blocked
allowlist

next roverBOT May 25, 2026, 12:48 PM

#

weary cradle der oauth hat funktioniert. jetzt reagiert allerdings telegram zwar noch auf bef...

pairing
mention required
embedded run
lane task error
minimax
model_not_found

Wenn das eine Telegram-Gruppe ist: prüfe zusätzlich, ob nach dem Update wieder requireMention/Gruppen-Allowlist greift. In Gruppen reicht DM-Pairing nicht; Gruppen brauchen channels.telegram.groups und ggf. groupAllowFrom/per-group allowFrom. Docs: https://docs.openclaw.ai/channels/telegram

Wenn es eine DM ist und /status geht, würde ich als erstes den Gateway-Container sauber neu starten, weil der 10s Health-Timeout nach einem hängenden Gateway/Run riecht:

docker compose restart openclaw-gateway

next roverBOT May 25, 2026, 12:48 PM

#

weary cradle der oauth hat funktioniert. jetzt reagiert allerdings telegram zwar noch auf bef...

Danach direkt testen:

openclaw health --verbose --timeout 60000
openclaw models status --probe --probe-provider minimax-portal

Wenn es danach wieder hängt, poste bitte die 50-100 Logzeilen direkt nach einer normalen Telegram-Nachricht, aber ohne Tokens/Secrets.

weary cradle May 25, 2026, 12:52 PM

#

das sind die logs. meine nachricht die ich in telegram schreibe taucht nicht auf...

openclaw-gateway | 2026-05-25T12:49:14.756+00:00 [telegram] [default] starting provider (@Clemens_openclaw_bot)
openclaw-gateway | 2026-05-25T12:49:14.988+00:00 [gateway] ready
openclaw-gateway | 2026-05-25T12:49:14.998+00:00 [heartbeat] started
openclaw-gateway | 2026-05-25T12:49:15.275+00:00 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 72 commands visible.
openclaw-gateway | 2026-05-25T12:49:15.476+00:00 [telegram] [diag] isolated polling ingress started spool=/home/node/.openclaw/telegram/ingress-spool-default
openclaw-gateway | 2026-05-25T12:49:21.030+00:00 [gateway] provider auth state pre-warmed in 4942ms eventLoopMax=3338.7ms

next roverBOT May 25, 2026, 12:52 PM

#

weary cradle das sind die logs. meine nachricht die ich in telegram schreibe taucht nicht auf...

Ja, das hilft sehr. Diese Logs zeigen: Telegram-Provider startet sauber, aber es kommt kein Inbound-Update an. Wenn deine Nachricht nicht einmal im Log auftaucht, ist das nicht MiniMax und noch kein Agent-Problem.

Wenn du in einer Telegram-Gruppe testest, ist die wahrscheinlichste Ursache Telegram Privacy Mode: Commands wie /status werden an Bots geliefert, normale Gruppennachrichten aber nicht. Dann sieht OpenClaw sie nie.

Fix in BotFather:

/setprivacy
@Clemens_openclaw_bot
Disable

Danach den Bot aus der Gruppe entfernen und wieder hinzufügen, oder ihn als Admin in der Gruppe setzen. Dann nochmal eine normale Nachricht testen.

Wenn es eine DM direkt an den Bot ist, dann ist Privacy Mode nicht relevant. Dann prüfe diese zwei Sachen:

next roverBOT May 25, 2026, 12:52 PM

#

weary cradle das sind die logs. meine nachricht die ich in telegram schreibe taucht nicht auf...

openclaw channels status --probe
docker compose ps

Achte darauf, dass nicht noch ein zweiter Gateway/Container mit demselben Telegram-Bot-Token läuft. Bei Telegram Long Polling kann effektiv nur ein Consumer sauber Updates abholen; eine zweite Instanz kann Updates “wegfressen”.

Optionaler Check, nur wenn der Gateway kurz gestoppt ist, damit du nicht mit Polling konkurrierst:

curl "https://api.telegram.org/bot<bot_token>/getUpdates"

Wenn dort deine normale Nachricht auch nicht erscheint, liefert Telegram sie nicht an den Bot -> Privacy/Gruppe/falscher Bot. Wenn sie dort erscheint, aber OpenClaw sie nicht loggt -> Polling/Container/Token-Konflikt.

Docs: https://docs.openclaw.ai/channels/telegram

weary cradle May 25, 2026, 1:03 PM

#

Docker PS zeigt nur ein image, das aktuelle an.
der Curl befehl bei gestoptem gateway liefert: {"ok":true,"result":[]}

next roverBOT May 25, 2026, 1:04 PM

#

weary cradle Docker PS zeigt nur ein image, das aktuelle an. der Curl befehl bei gestoptem g...

{"ok":true,"result":[]} heißt: Telegram hatte zu diesem Zeitpunkt keine Updates für genau diesen Bot-Token in der Queue. Das ist ein starker Hinweis, dass OpenClaw die Nachricht gar nicht bekommen kann.

Wichtig zum Test: Gateway stoppen, danach eine neue Telegram-Nachricht an den Bot schicken, danach getUpdates ausführen. Wenn du getUpdates nur nach dem Stoppen ausführst, ohne danach neu zu schreiben, ist [] normal.

Bitte so testen:

docker compose stop openclaw-gateway

# jetzt in Telegram eine frische Nachricht an @Clemens_openclaw_bot senden

curl "https://api.telegram.org/bot<bot_token>/getUpdates"
curl "https://api.telegram.org/bot<bot_token>/getWebhookInfo"

Auswertung:

next roverBOT May 25, 2026, 1:04 PM

#

weary cradle Docker PS zeigt nur ein image, das aktuelle an. der Curl befehl bei gestoptem g...

Wenn getUpdates wieder [] liefert: Telegram liefert normale Nachrichten nicht an diesen Bot. Bei Gruppen ist das fast immer Privacy Mode / Bot nicht Admin / falscher Bot / Nachricht ohne Mention. In DM wäre es eher falscher Bot-Token oder du schreibst an einen anderen Bot.
Wenn getWebhookInfo eine url zeigt: Dann ist noch ein Webhook gesetzt. Für Long Polling muss der weg:
```
curl "https://api.telegram.org/bot<bot_token>/deleteWebhook?drop_pending_updates=false"
```
Danach Gateway wieder starten.
Wenn getUpdates deine Nachricht zeigt, OpenClaw aber später nicht: dann ist es wirklich OpenClaw-Polling/Container-seitig.

Für Gruppen nochmal der direkte Fix:

BotFather -> /setprivacy -> @Clemens_openclaw_bot -> Disable

Dann Bot aus der Gruppe raus und wieder rein, oder als Admin setzen.

weary cradle May 25, 2026, 1:08 PM

#

Es ist keine Gruppe. Ich bin in einem privaten Chat. User IDs sind hinterlegt. Die Nachricht jetzt war in Curl get Updates enthalten. Es tut sich in Telegram jedoch weiterhin nichts

next roverBOT May 25, 2026, 1:09 PM

#

weary cradle Es ist keine Gruppe. Ich bin in einem privaten Chat. User IDs sind hinterlegt. D...

Okay, dann ist es keine Privacy-/Gruppen-Sache. Wenn die DM in getUpdates auftaucht, liefert Telegram korrekt. Dann hängt es zwischen OpenClaw-Polling und Verarbeitung.

Wichtig: Starte nach dem Curl-Test den Gateway wieder und sende eine neue DM. Dann direkt Logs beobachten:

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

Wenn dabei weiterhin gar kein telegram-Inbound auftaucht, prüfe bitte diese drei Dinge:

openclaw channels status --probe
openclaw pairing list telegram
openclaw config get channels.telegram

next roverBOT May 25, 2026, 1:09 PM

#

weary cradle Es ist keine Gruppe. Ich bin in einem privaten Chat. User IDs sind hinterlegt. D...

Und wegen dieser Logzeile:

isolated polling ingress started spool=/home/node/.openclaw/telegram/ingress-spool-default

bitte auch nur lesend schauen, ob dort Dateien liegen bleiben:

docker compose exec openclaw-gateway sh -lc 'ls -lah /home/node/.openclaw/telegram/ingress-spool-default || true'

Auswertung:

Spool bleibt leer + keine Inbound-Logs: Polling bekommt die Updates im laufenden Gateway nicht. Dann als nächstes mit Telegram HTTP-Diagnostik starten.
Spool füllt sich: Polling holt Updates, aber der Ingress-Processor hängt.
Inbound erscheint, aber keine Antwort: dann sind wir bei Allowlist/Pairing/Agent/Model.

next roverBOT May 25, 2026, 1:09 PM

#

weary cradle Es ist keine Gruppe. Ich bin in einem privaten Chat. User IDs sind hinterlegt. D...

Für mehr Signal beim nächsten Start kannst du temporär setzen:

OPENCLAW_DIAGNOSTICS=telegram.http

Dann Gateway neu starten und eine neue DM senden. Wenn du die Logs postest, bitte Token/Chat-IDs schwärzen. Besonders interessant sind Zeilen mit getUpdates, telegram, spool, pairing, blocked, allowlist, agent, embedded run.

Eine Sache noch: Falls du getUpdates mit offset benutzt hast oder irgendein Script das tut, kann das Updates bestätigen/überspringen. Für Tests nur ohne offset verwenden.

weary cradle May 25, 2026, 1:14 PM

#

OpenClaw 2026.5.22 (unknown) — The only open-source project where the mascot could eat the competition.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, connected, transport:just now, mode:polling, bot:@Clemens_openclaw_bot, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
node@1ca943b1d994:/app$ openclaw pairing list telegram
│
◇

OpenClaw 2026.5.22 (unknown) — Running on your hardware, reading your logs, judging nothing (mostly).

No pending telegram pairing requests.
node@1ca943b1d994:/app$ openclaw config get channels.telegram

Gateway sieht gut aus für mich.

Ja, es liegen Dateien:
drwxr-xr-x 2 node node 4.0K May 25 13:11 .
drwx------ 3 node node 4.0K May 25 13:08 ..
-rw------- 1 node node 2.2K May 25 12:25 0000000483173254.json.processing
-rw------- 1 node node 368 May 25 12:29 0000000483173256.json
-rw------- 1 node node 404 May 25 12:30 0000000483173257.json
-rw------- 1 node node 346 May 25 12:41 0000000483173258.json
-rw------- 1 node node 353 May 25 12:45 0000000483173260.json
-rw------- 1 node node 345 May 25 12:50 0000000483173261.json
-rw------- 1 node node 351 May 25 12:57 0000000483173262.json
-rw------- 1 node node 406 May 25 12:59 0000000483173263.json
-rw------- 1 node node 359 May 25 13:07 0000000483173264.json
-rw------- 1 node node 354 May 25 13:11 0000000483173266.json

next roverBOT May 25, 2026, 1:15 PM

#

weary cradle OpenClaw 2026.5.22 (unknown) — The only open-source project where the mascot cou...

Das ist der Treffer. Der Gateway ist erreichbar und Telegram-Polling funktioniert, aber die Ingress-Spool staut sich. Besonders verdächtig ist:

0000000483173254.json.processing   May 25 12:25

Eine alte .processing-Datei plus viele spätere .json Dateien heißt: Der Ingress-Processor hat eine Nachricht als “in Bearbeitung” markiert und ist danach offenbar stecken geblieben/abgestürzt. Deshalb kommen neue DMs zwar in die Spool, werden aber nicht weiter an den Agenten gegeben.

Ich würde die kaputte Processing-Datei erst beiseitelegen, nicht löschen:

docker compose stop openclaw-gateway

docker compose run --rm --entrypoint sh openclaw-gateway -lc '
  cd /home/node/.openclaw/telegram/ingress-spool-default &&
  mkdir -p held &&

next roverBOT May 25, 2026, 1:15 PM

#

weary cradle OpenClaw 2026.5.22 (unknown) — The only open-source project where the mascot cou...

  mv ./*.processing ./held/
'

docker compose up -d openclaw-gateway

Dann eine neue Telegram-DM senden und Logs prüfen:

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

Wenn er danach die alten .json Dateien abarbeitet, war diese .processing Datei der Blocker. Wenn sofort wieder eine neue .processing hängen bleibt, bitte diese zwei Dinge posten:

next roverBOT May 25, 2026, 1:15 PM

#

weary cradle OpenClaw 2026.5.22 (unknown) — The only open-source project where the mascot cou...

docker compose logs --tail=300 openclaw-gateway
docker compose run --rm --entrypoint sh openclaw-gateway -lc 'ls -lah /home/node/.openclaw/telegram/ingress-spool-default'

Tokens/Chat-IDs bitte schwärzen.

Das riecht nach einem Bug in der isolierten Telegram-Ingress-Spool auf 2026.5.22, vor allem weil channels status --probe “works” sagt, aber die Spool nicht drainiert. Wenn das nach dem Beiseitelegen erneut passiert, wäre ein GitHub-Issue mit genau dieser Spool-Liste + Logs sinnvoll: https://github.com/openclaw/openclaw/issues

weary cradle May 25, 2026, 1:20 PM

#

das ist der output:
es tut sich weiterhin nichts. also ist es ein issue?
kann ich ggf. ein downgrade auf eine ältere version durchführen in der hoffnung wieder einen funktionierenden bot zu bekommen?

📎 message.txt

next roverBOT May 25, 2026, 1:21 PM

#

weary cradle das ist der output: es tut sich weiterhin nichts. also ist es ein issue? kann ic...

Ja, das sieht inzwischen sehr nach einem Issue in 2026.5.22 aus, aber dein letzter Output zeigt auch: der eigentliche Unblock wurde noch nicht wirksam. Die alte Datei liegt weiterhin da:

0000000483173254.json.processing

Solange die Spool so aussieht, wird nichts sauber abgearbeitet. Ich würde jetzt einmal die ganze Telegram-Ingress-Spool beiseitelegen. Das ist nicht löschen, nur Quarantäne der hängenden Updates:

docker compose stop openclaw-gateway

docker compose run --rm --no-deps --entrypoint sh openclaw-gateway -lc '
  set -eu
  spool=/home/node/.openclaw/telegram/ingress-spool-default
  held=/home/node/.openclaw/telegram/held-ingress-$(date +%Y%m%d-%H%M%S)
  mkdir -p "$held"

next roverBOT May 25, 2026, 1:21 PM

#

weary cradle das ist der output: es tut sich weiterhin nichts. also ist es ein issue? kann ic...

  mv "$spool"/* "$held"/ 2>/dev/null || true
  ls -lah "$spool"
  echo "moved old spool files to $held"
'

docker compose up -d openclaw-gateway

Dann eine neue Telegram-DM senden und prüfen:

docker compose logs -f --tail=200 openclaw-gateway
docker compose run --rm openclaw-cli channels status --probe

Wenn danach wieder neue .json Dateien liegen bleiben oder sofort wieder eine .processing hängt, dann ja: bitte als Bug melden. Gute Issue-Daten wären:

next roverBOT May 25, 2026, 1:21 PM

#

weary cradle das ist der output: es tut sich weiterhin nichts. also ist es ein issue? kann ic...

Version: OpenClaw 2026.5.22
Docker/VPS
Telegram DM, polling mode, channels status --probe sagt works
Spool füllt sich unter /home/node/.openclaw/telegram/ingress-spool-default
alte .processing Datei blockiert Verarbeitung
relevante Logs ohne Tokens/Chat-IDs

Issue-Link: https://github.com/openclaw/openclaw/issues

Downgrade geht grundsätzlich. Wenn du das Docker-Image aus GHCR nutzt, pinne in deiner .env oder Compose-Umgebung z.B. ein älteres Tag statt latest:

OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:<version>
docker compose pull
docker compose up -d

next roverBOT May 25, 2026, 1:21 PM

#

weary cradle das ist der output: es tut sich weiterhin nichts. also ist es ein issue? kann ic...

Die Docker-Doku sagt, gängige Tags sind main, latest und konkrete Versionen wie 2026.2.26: https://docs.openclaw.ai/install/docker

Ich würde vor dem Downgrade erst den Spool-Reset oben machen. Das ist der kleinste Eingriff und kann deinen Bot sofort wieder freibekommen.

weary cradle May 25, 2026, 1:32 PM

#

das löschen half, dass er reagierte und wieder typing stand. allerdings ist nie eine antwort angekommen und auch die logs zeigen nichts. dafür hängen jetzt wieder neue json mit processing:
Container openclaw-openclaw-gateway-run-24ef267d5b86 Creating
Container openclaw-openclaw-gateway-run-24ef267d5b86 Created
total 16K
drwxr-xr-x 2 node node 4.0K May 25 13:30 .
drwx------ 5 node node 4.0K May 25 13:27 ..
-rw------- 1 node node 452 May 25 13:27 0000000483173269.json.processing
-rw------- 1 node node 345 May 25 13:30 0000000483173270.json

next roverBOT May 25, 2026, 1:32 PM

#

weary cradle das löschen half, dass er reagierte und wieder typing stand. allerdings ist nie ...

Ja, damit ist es reproduzierbar: Spool leeren hilft kurz, dann bleibt direkt der nächste Ingress wieder als .json.processing hängen. Das ist sehr wahrscheinlich ein Bug in dieser Telegram isolated-polling/spool Verarbeitung auf 2026.5.22.

Noch zwei sinnvolle Checks vor dem Downgrade:

docker compose logs --tail=500 openclaw-gateway | grep -Ei 'telegram|spool|ingress|error|exception|embedded|agent|minimax'

Und die hängende Datei einmal anschauen, aber IDs/Text vor dem Posten schwärzen:

docker compose run --rm --no-deps --entrypoint sh openclaw-gateway -lc '
  sed -n "1,120p" /home/node/.openclaw/telegram/ingress-spool-default/*.processing
'

Wenn dort nur deine Telegram-Update-Payload drinsteht, aber keine Fehlerdatei/kein Log folgt, würde ich nicht weiter dran herumdebuggen. Dann Issue aufmachen mit:

next roverBOT May 25, 2026, 1:32 PM

#

weary cradle das löschen half, dass er reagierte und wieder typing stand. allerdings ist nie ...

2026.5.22
Docker/VPS
Telegram DM polling, channels status --probe = works
nach Spool-Reset kommt kurz typing, dann bleibt neue .json.processing hängen
Spool-Liste + redigierte Logs

Issue: https://github.com/openclaw/openclaw/issues

Downgrade ist als Workaround okay. Wenn du vorher auf 2026.4.15 warst und dein Image aus GHCR kommt, pinne das Image explizit statt latest:

# in .env oder deiner Compose-Umgebung:
OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:2026.4.15

docker compose pull
docker compose up -d

next roverBOT May 25, 2026, 1:32 PM

#

weary cradle das löschen half, dass er reagierte und wieder typing stand. allerdings ist nie ...

docker compose run --rm openclaw-cli --version

Falls 2026.4.15 als Image-Tag nicht existiert, nimm den letzten Tag, von dem du weißt, dass er bei dir lief. Wichtig: vor jedem Wechsel die Spool wieder beiseitelegen, sonst schleppt der alte Container die hängenden Updates mit:

docker compose stop openclaw-gateway
docker compose run --rm --no-deps --entrypoint sh openclaw-gateway -lc '
  spool=/home/node/.openclaw/telegram/ingress-spool-default
  held=/home/node/.openclaw/telegram/held-ingress-$(date +%Y%m%d-%H%M%S)
  mkdir -p "$held"
  mv "$spool"/* "$held"/ 2>/dev/null || true
'

weary cradle May 25, 2026, 1:38 PM

#

here you go. siehst du noch was oder issue und zurückwechseln?

📎 message.txt

next roverBOT May 25, 2026, 1:39 PM

#

weary cradle here you go. siehst du noch was oder issue und zurückwechseln?

Ja, ich sehe noch etwas Wichtiges: Das ist nicht mehr “Telegram liefert nicht”.

Diese Zeile zeigt, dass die DM sauber bei OpenClaw angekommen ist:

[telegram] Inbound message telegram:... (direct, 6 chars)

Danach startet ein Embedded-Agent-Run, aber er kommt nicht bis zur Antwort. Die .json.processing Datei ist dabei eher das Symptom: sie bleibt liegen, weil der Run nie fertig wird. Auffällig sind diese Zeilen:

[agent/embedded] workspace bootstrap file MEMORY.md ...
exec: elevated command cat ~/.openclaw/agents/main/agent/auth-profiles.json ...
[reload] config change requires gateway restart ... deferring until ... embedded run(s) complete
[telegram] channel stop exceeded 5000ms after abort

next roverBOT May 25, 2026, 1:39 PM

#

weary cradle here you go. siehst du noch was oder issue und zurückwechseln?

Für eine simple Hallo?-DM ist es nicht normal, dass der Agent anfängt Auth-Profile per exec zu lesen. Das sieht nach einem hängenden/fehlgeleiteten Agent-Run aus, wahrscheinlich aus der alten Session-History plus dem MiniMax/Tool-Kontext nach der Migration.

Ich würde jetzt nicht weiter viel Zeit verbrennen. Zwei pragmatische Wege:

Schnellster Reparaturversuch ohne Downgrade:
- Spool wieder beiseitelegen
- Gateway starten
- in Telegram zuerst /stop, dann /new senden
- danach erst eine normale neue Testnachricht
Falls /stop//new nicht sauber beantwortet werden, ist der Run/Ingress weiter kaputt.
Für funktionierenden Bot: Downgrade auf den letzten bekannten guten Docker-Tag und Spool vorher beiseitelegen.

docker compose stop openclaw-gateway

next roverBOT May 25, 2026, 1:39 PM

#

weary cradle here you go. siehst du noch was oder issue und zurückwechseln?


docker compose run --rm --no-deps --entrypoint sh openclaw-gateway -lc '
  spool=/home/node/.openclaw/telegram/ingress-spool-default
  held=/home/node/.openclaw/telegram/held-ingress-$(date +%Y%m%d-%H%M%S)
  mkdir -p "$held"
  mv "$spool"/* "$held"/ 2>/dev/null || true
'

Dann in .env oder deiner Compose-Umgebung pinnen:

OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:<last-known-good-version>
docker compose pull
docker compose up -d

next roverBOT May 25, 2026, 1:39 PM

#

weary cradle here you go. siehst du noch was oder issue und zurückwechseln?

docker compose run --rm openclaw-cli --version

Und ja: bitte als GitHub-Issue melden. Die Daten sind gut genug:

2026.5.22, Docker/VPS
Telegram DM polling, channels status --probe sagt works
DM kommt als inbound an
Embedded run hängt, keine Antwort
.json.processing bleibt liegen
Logauszug mit exec elevated command cat auth-profiles.json und channel stop exceeded

https://github.com/openclaw/openclaw/issues

Mein Bauchgefühl: Downgrade ist jetzt der richtige Workaround, Issue parallel aufmachen.

weary cradle May 25, 2026, 1:43 PM

#

next rover Für eine simple `Hallo?`-DM ist es nicht normal, dass der Agent anfängt Auth-Pro...

der letzte versuch hats gelöst. /stop und /new waren hilfreich. danke krill!

next roverBOT May 25, 2026, 1:43 PM

#

weary cradle der letzte versuch hats gelöst. /stop und /new waren hilfreich. danke krill!

Sehr gut, dann war es wirklich ein hängender alter Run/Session-Zustand nach der Migration, nicht Telegram selbst. Freut mich, dass /stop + /new es gelöst hat.

Wenn das wieder passiert: erst /stop, dann /new, und nur wenn danach wieder .json.processing hängen bleibt, Spool beiseitelegen.

Wenn das jetzt die Lösung war: bitte Rechtsklick auf die Lösungsnachricht → Apps → ✅ Mark Solution. Das hilft Answer Overflow, die Lösung für die nächsten Docker/Telegram-Leute sauber zu indexieren. 🦞

#Updating openclaw on vps in docker from 4.15 to latest.