Ich habe meine Signal Verbindung zu meinem Agenten zerstört. | Friends of the Crustacean 🦞🤝 | Page 1

chilly egret Apr 22, 2026, 8:50 PM

#

Spreche mit meinen Agenten immer über Signal. Dann habe ich versucht mir selbst eine nachricht mit dem Befehl

openclaw message send —channel signal -t „+XXXXXXXXXXXXXX“ -m „Testnachricht“

zu schicken. Danach konnte ich keine Signalnachtichten mehr an meinen Agenten schicken. Er konnte mir sporadisch noch welche zukommen lassen, aber nicht zuverlässig.

Gateway neustart.
Reboot des systems haben nicht geholfen.
Uns ist dann auch aufgefallen, dass die dns api.signal.org nicht aufgelöst werden kann.
openclaw doctor liefert keine fehler.
ich habe dann openclaw update gemacht.
Danach ging garnichts mehr mit agent 1 auch nicht mehr über das TUI.
Mit Agent 2 konnte ich dann noch einen kurzen chat führen. Dann ist er auch eingeschlafen.
Danach ist der Ventilator des rechners hochgefahren, dass harmt er noch nie gemacht.
„/reset“ bei agent 1 hat auch nichtsgebracht.

Openclaw ist momentan nicht mehr nutzbar.

dry wraithBOT Apr 22, 2026, 8:50 PM

#

real loomBOT Apr 22, 2026, 8:50 PM

#

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

dry wraithBOT Apr 22, 2026, 8:50 PM

#

chilly egret Apr 23, 2026, 7:23 AM

#

Hallo Krill, ich hoffe du hattest gestern eine schöne Auszeit und hast es genossen, mal nicht andauernd Fragen zu beantworten. Kannst du bitte nochmal in mein Problem reinschauen, dass ich gestern gepostet habe?

grave tendonBOT Apr 23, 2026, 7:25 AM

#

Ich schaue gerade in die lokalen Docs und die bekannten Signal-Fallen rein, damit ich dir nicht irgendwas ausdenke.

#

Ja, ich hab nochmal reingeschaut.

Mein aktueller Verdacht ist: Der Self-Send hat nicht direkt alles “zerstört”. Laut Signal-Doku/Code filtert OpenClaw nur eigene Signal-Nachrichten zur Loop-Prevention. Das sollte keinen kompletten Totalausfall verursachen. Was deutlich verdächtiger ist, ist dein Hinweis mit api.signal.org DNS. Wenn der Host das nicht auflöst, wird Signal bzw. signal-cli schnell unzuverlässig, auch wenn openclaw doctor noch grün ist.

Dass später Agent 1 auch im TUI hing und der Rechner hörbar hochdrehte, riecht zusätzlich nach einem zweiten Problem, also Gateway/Session hängt oder ein Prozess loopt.

Magst du bitte genau diese Ausgaben posten, am besten gesammelt in einem Reply?

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw pairing list signal
getent hosts api.signal.org || resolvectl query api.signal.org || dig +short api.signal.org
pgrep -af 'signal-cli|openclaw|java|node'

#


latest_log="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$latest_log"
grep -iE 'signal|dns|resolve|java|exception|error|pair' "$latest_log" | tail -n 120

Wichtig:

openclaw --version zuerst, das ist oft die halbe Miete.
Wenn api.signal.org da schon fehlschlägt, ist mein Hauptverdacht erstmal Host-DNS / VPN / Adblocker / Resolver, nicht Signal-Pairing.
Bitte noch nicht neu linken / neu registrieren, bis wir die Logs gesehen haben.

Hilfreiche Doku dazu:

#

Kleine Randnotiz: Falls du den Send-Befehl nochmal testest, nimm wirklich --channel mit zwei normalen Minuszeichen, nicht —channel.

chilly egret Apr 23, 2026, 8:36 AM

#

I cannot post the text in one chat, because it's longer than 2000 characters. What can I do? Upload button at the "+" Symbol is not available.

grave tendonBOT Apr 23, 2026, 8:37 AM

#

Kein Problem, einfach auf 2 bis 4 Replies aufteilen. Das ist völlig okay. 🙂

Am besten so:

Reply 1

openclaw --version
openclaw gateway status
openclaw channels status --probe
openclaw pairing list signal

Reply 2

openclaw status --all

#

Reply 3

getent hosts api.signal.org || resolvectl query api.signal.org || dig +short api.signal.org
pgrep -af 'signal-cli|openclaw|java|node'

Reply 4
Nur die letzten 40 statt 120 relevanten Logzeilen:

latest_log="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$latest_log"
grep -iE 'signal|dns|resolve|java|exception|error|pair' "$latest_log" | tail -n 40

Bitte jeweils in code blocks schicken, dann bleibt es lesbar.

Wenn selbst openclaw status --all zu lang ist, schick erstmal nur:

#

openclaw --version
openclaw gateway status
openclaw channels status --probe
DNS-Ausgabe
die letzten 40 Logzeilen

Das reicht meistens schon, um die Richtung zu sehen.

chilly egret Apr 23, 2026, 8:49 AM

#

Kann jeder hier in discord die logs lesen oder nur du?

grave tendonBOT Apr 23, 2026, 8:49 AM

#

Nicht nur ich, jeder, der diesen Thread sehen kann, kann die geposteten Logs lesen.

Also bitte vorher redacten:

Tokens / API keys / Passwörter
komplette Telefonnummern
private URLs / Hostnames / IPs, falls sensibel
alles, was wie Secret aussieht

Unkritisch sind meistens:

openclaw --version
gateway status
channels status --probe
DNS-Fehler
die relevanten signal / error Logzeilen

Wenn du willst, poste nur die gekürzten Ausschnitte, nicht den ganzen Log. Ich sag dir dann, was noch fehlt.

#

Das hilft schon, danke. Die gute Nachricht zuerst: Das sieht nicht nach komplett kaputtem OpenClaw aus.

Was ich daraus lese:

Version ist aktuell (2026.4.21)
Gateway läuft und ist erreichbar
Signal ist konfiguriert
keine Agents hängen im Bootstrapping
Port 18789 is already in use ist hier wahrscheinlich normal, weil dein Gateway-Service ja genau auf dem Port läuft. Das ist in diesem Kontext nicht der Smoking Gun.

Heißt: Der Fokus liegt jetzt eher auf

Signal-Transport / signal-cli
DNS zu Signal
eventuell Pairing / Allowlist / hängender Prozess

Schick bitte als Nächstes nur diese drei Sachen:

#

openclaw channels status --probe
openclaw pairing list signal
getent hosts api.signal.org || resolvectl query api.signal.org || dig +short api.signal.org

Wenn das wieder zu lang wird, gern in mehreren Replies.

Mein Zwischenfazit gerade:
Gateway ok, OpenClaw insgesamt eher ok, Problem sitzt wahrscheinlich eine Schicht tiefer bei Signal/DNS oder im Signal-Prozess.

#

Super, das engt es stark ein.

Damit haben wir jetzt ziemlich sicher:

Gateway läuft
OpenClaw ist erreichbar
der lokale Signal-Daemon antwortet
openclaw update hat den Dienst nicht zerschossen

Wichtig: channels status --probe ... works heißt hier vor allem, dass OpenClaw mit dem lokalen signal-cli sprechen kann. Das ist gut, aber noch kein vollständiger End-to-End-Beweis, dass echtes Senden/Empfangen zu Signal sauber läuft.

Damit bleiben für mich vor allem noch:

Pairing / Allowlist
DNS / Netzwerk zu Signal
evtl. Fehler beim echten Send/Receive, die nur im Log auftauchen

Bitte als Nächstes nur diese zwei Sachen:

#

openclaw pairing list signal
getent hosts api.signal.org || resolvectl query api.signal.org || dig +short api.signal.org

Und wenn du noch Luft hast, direkt danach noch das hier:

latest_log="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -iE 'signal|sse|receive|pair|dns|resolve|exception|error' "$latest_log" | tail -n 60

Mein Zwischenfazit jetzt:
OpenClaw selbst lebt. Wenn es noch kaputt wirkt, sitzt der Fehler sehr wahrscheinlich im Signal-Pfad, nicht im Gateway-Kern.

#

Ja, das ist jetzt endlich ein echter harter Hinweis.

Was wir jetzt wissen:

kein Pairing-Problem (No pending signal pairing requests)
Gateway lebt
Signal-Daemon antwortet lokal
aber getent hosts api.signal.org liefert nichts. Das heißt: der Host kann den Namen gerade nicht auflösen.

Das passt leider ziemlich gut zu deinem Symptom “sporadisch / unzuverlässig”. Und der hochdrehende Lüfter könnte einfach von Retry-Loops kommen.

Ich würde jetzt nicht mehr an OpenClaw herumresetten, sondern erstmal den Resolver und die Logs anschauen.

Bitte als Nächstes:

cat /etc/resolv.conf

#

und dann:

latest_log="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -iE 'signal|dns|resolve|lookup|sse|receive|send|exception|error' "$latest_log" | tail -n 80

Wenn du einen DNS-Blocker / Pi-hole / AdGuard / VPN / speziellen Router-DNS nutzt, sag das bitte auch dazu, das wäre gerade mein Hauptverdacht.

Mein Zwischenfazit jetzt:
Das sieht zunehmend nach einem Host-DNS-/Netzwerkproblem im Signal-Pfad aus, nicht nach einem zerstörten Agenten.

#

Das ist nur noch ein weiterer Chromium-Hilfsprozess, der hilft uns hier leider nicht weiter.

Die zwei wichtigen Sachen fehlen noch:

cat /etc/resolv.conf

und

latest_log="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -iE 'signal|dns|resolve|lookup|sse|receive|send|exception|error' "$latest_log" | tail -n 80

Wenn du magst, schick erst nur cat /etc/resolv.conf, dann gehen wir Schritt für Schritt weiter.

#

Perfekt, das bestätigt jetzt immerhin: signal-cli läuft tatsächlich.

Also Stand gerade:

Gateway läuft
OpenClaw läuft
signal-cli läuft
kein pending pairing
DNS bleibt der Hauptverdacht

Lass uns ab jetzt wirklich nur noch einen Schritt auf einmal machen, sonst verzetteln wir uns.

Bitte jetzt nur das hier ausführen und posten:

cat /etc/resolv.conf

#

Mehr erstmal nicht.

#

Fast, aber das ist wieder nicht cat /etc/resolv.conf, sondern nochmal Prozess-Ausgabe 🙂

Bitte wirklich genau diesen einen Befehl:

cat /etc/resolv.conf

Die Ausgabe sollte nur ein paar Zeilen sein, typischerweise sowas wie:

nameserver 1.1.1.1
nameserver 8.8.8.8

Poste einfach genau das, was dann erscheint.

#

Danke, das Log hilft insofern: da ist gerade kein Signal-Fehler drin.
Die zwei Zeilen sind harmlos bzw. nur Gateway-Startup:

punycode Deprecation Warning, unschön aber nicht die Ursache
gateway ready, also normaler Start

Uns fehlt weiter der wichtigste DNS-Hinweis. Bitte wirklich nur das hier:

echo '--- resolv.conf ---'
cat /etc/resolv.conf

Wenn da nichts kommt, sag einfach: “leer”.
Danach haben wir sehr wahrscheinlich den nächsten echten Ansatz.

#

Okay, das bringt tatsächlich noch einen zweiten Hinweis:

starting provider ist normal
unknown agent id "main" erklärt wahrscheinlich dein TUI-Problem, ist aber ein separates Thema vom Signal-Ausfall

Für den Signal-Teil fehlt uns weiterhin genau eine Sache: welche DNS-Server dein Pi benutzt.

Bitte jetzt wirklich nur das hier:

grep '^nameserver' /etc/resolv.conf || cat /etc/resolv.conf

Ich brauche nur die nameserver-Zeilen.
Dann kann ich dir ziemlich sicher sagen, ob wir auf der DNS-Spur richtig sind.

#

Diese beiden Zeilen sind wieder nur normale Starts, kein Fehler:

device.pair.list erfolgreich
signal-cli ... Starting daemon erfolgreich

Wir drehen uns gerade nur im Kreis, weil ich nicht die Logs, sondern deine DNS-Konfiguration brauche.

Am einfachsten jetzt so:

Öffne /etc/resolv.conf in Mousepad
Kopiere nur die Zeilen mit nameserver hier rein

Es sollte ungefähr so aussehen:

nameserver 1.1.1.1

#

nameserver 8.8.8.8

Wenn du lieber Terminal nimmst, dann wirklich nur:

grep '^nameserver' /etc/resolv.conf

Bitte nur die Ausgabe davon, nichts anderes.

#

Ah, das ist endlich ein echter Smoking Gun. 👀

Die wichtige Zeile ist:

signal daemon not ready after 11368ms

Das heißt:

signal-cli startet
der HTTP-Server kommt sogar hoch
aber OpenClaw bricht die Readiness-Prüfung nach ~11s ab

Auf einem Raspberry Pi ist das absolut plausibel. Das würde auch erklären, warum es nach Neustarts besonders flaky wirkt.

Mein klarer erster Fix

In ~/.openclaw/openclaw.json im channels.signal Block hinzufügen oder erhöhen:

#

{
  channels: {
    signal: {
      startupTimeoutMs: 60000,
    },
  },
}

Danach:

openclaw gateway restart
openclaw channels status --probe

#

Dann 20 bis 30 Sekunden warten und erst dann Signal testen.

Wichtig

Das hier ist separat von dem TUI-Fehler mit:

unknown agent id "main"

Also:

Signal-Problem: sehr wahrscheinlich Startup-Timeout / langsamer signal-cli
TUI-Problem: separater Agent-ID-/Client-Fehler

Wenn du willst, schick als Nächstes den redaktierten channels.signal-Block aus deiner openclaw.json, dann sag ich dir exakt, wo startupTimeoutMs rein muss.

Doku dazu: https://docs.openclaw.ai/channels/signal

#

Ja, genau das bestätigt die Theorie.

Timeline:

07:45:06 signal-cli startet
07:45:07 OpenClaw sagt: not ready after 11s
07:45:46 Signal: ok

Also: Der Signal-Daemon ist nicht kaputt, sondern auf deinem Pi einfach langsamer bereit, als OpenClaw beim Start gerade erwartet.

Damit ist der nächste sinnvolle Schritt:

startupTimeoutMs erhöhen, dann Gateway neu starten.

In ~/.openclaw/openclaw.json:

#

  channels: {
    signal: {
      startupTimeoutMs: 60000,
    },
  },
}

Dann:

openclaw gateway restart
openclaw channels status --probe

Wenn du magst, poste danach nur noch kurz:

#

ob du startupTimeoutMs gesetzt hast
ob channels status --probe danach sauber bleibt
ob Signal-DMs wieder zuverlässig reinkommen

Ich bin jetzt ziemlich zuversichtlich, dass wir den Hauptfehler erwischt haben.

#

Perfekt, danke. Das sagt uns:

resolv.conf ist nicht leer
DNS ist also konfiguriert
aber das heißt leider noch nicht, dass die Resolver auch sauber funktionieren

Mit den einen IPv4- plus zwei IPv6-Nameservern ist mein Bauchgefühl gerade:

der bestätigte Hauptfehler ist weiterhin der zu kurze Signal-Startup-Timeout
zusätzlich könnte noch ein IPv6-/Resolver-Thema dranhängen, falls api.signal.org weiter nicht auflösbar ist

Ich würde jetzt so vorgehen

Zuerst den bestätigten Fix machen:
- channels.signal.startupTimeoutMs: 60000
- openclaw gateway restart
Danach nochmal testen:

#

   openclaw channels status --probe
   getent hosts api.signal.org

Wenn getent hosts api.signal.org danach immer noch leer bleibt, schauen wir als Nächstes gezielt auf IPv4 vs IPv6 DNS. Aber ich würde erst den Timeout-Fix machen, weil wir dafür jetzt einen echten Beleg aus dem Log haben.

Wenn du willst, poste jetzt einfach kurz:

startupTimeoutMs gesetzt: ja/nein
Ergebnis von openclaw channels status --probe
Ergebnis von getent hosts api.signal.org

Dann ziehen wir den Rest sauber auseinander.

chilly egret Apr 23, 2026, 10:02 AM

#

Ist api.signal.org eigentlich die richtige Addresse?

grave tendonBOT Apr 23, 2026, 10:03 AM

#

Kurz gesagt: für unsere OpenClaw-Diagnose eher nein.

Ich habe in den OpenClaw-Docs und im lokalen Code keinen relevanten Verweis auf api.signal.org gefunden. Für OpenClaw ist der wichtige Pfad:

lokal: signal-cli Daemon auf http://127.0.0.1:<port>
relevant fürs Problem: ob der Daemon rechtzeitig ready wird und ob Send/Receive klappt

Und genau dafür haben wir ja schon einen echten Treffer im Log:

signal daemon not ready after 11368ms

Also:

api.signal.org mag irgendwo im Signal-Ökosystem existieren oder auch nicht
aber es ist nicht der beste oder verlässlichste Check für dein aktuelles OpenClaw-Problem
der stärkste Befund bleibt gerade der zu kurze Startup-Timeout auf deinem Pi

#

Ich würde mich deshalb weiter auf den Fix mit startupTimeoutMs konzentrieren, nicht auf api.signal.org.

#

Nice, das ist ein echter Fortschritt. 🎉

Damit haben wir jetzt:

startupTimeoutMs erhöht
Signal kommt sauber hoch
channels status --probe ist grün

getent hosts api.signal.org = leer bleibt interessant, aber ich würde das jetzt nicht mehr als Hauptblocker für OpenClaw behandeln. Für deinen konkreten Fall zählt jetzt vor allem: funktioniert Signal end-to-end wieder zuverlässig?

Bitte jetzt genau diesen Realtest

openclaw gateway restart
30 Sekunden warten
Schick deinem Agenten über Signal 2 bis 3 normale Testnachrichten

Dann sag mir einfach nur eines von beiden:

„Ja, geht wieder stabil“
„Nein, immer noch flaky“

#

Wenn es immer noch flaky ist, machen wir als Nächstes einen Live-Log beim echten Signal-Test.
Wenn es jetzt stabil ist, war der Startup-Timeout sehr wahrscheinlich der Hauptfehler.

Und separat, nur damit’s nicht untergeht:
Der TUI-Fehler mit unknown agent id "main" ist sehr wahrscheinlich ein zweites, separates Problem.

chilly egret Apr 23, 2026, 10:18 AM

#

Signal funktioniert nicht. Weder Textnachricht noch inchat Befehl /status gibt eine Antwort.

grave tendonBOT Apr 23, 2026, 10:19 AM

#

Okay, dann hat der Timeout-Fix zwar den Startup verbessert, aber nicht den eigentlichen Nachrichtenfluss. Das ist wichtig.

Der nächste Schritt ist jetzt ein Live-Repro, damit wir sehen, ob deine Signal-Nachricht überhaupt beim Gateway ankommt.

Bitte genau so:

Im Terminal:
```
openclaw logs --follow
```
Dann eine einzige normale Signal-Nachricht an den Agenten schicken, zum Beispiel:
```
test
```
oder
```
/status
```

#

10 Sekunden warten
Mit Ctrl+C stoppen
Die letzten ~30 Zeilen hier posten

Ganz wichtig:

Wenn gar nichts Neues im Log auftaucht, sag einfach:
„Beim Senden kam im Log nichts Neues.“

Das trennt sauber:

Signal → Gateway kommt gar nicht an
oder
kommt an, wird aber von OpenClaw/Agent nicht verarbeitet.

#

Danke, aber das ist nicht der Signal-Traffic. Das ist nur ein unrelated WebChat/heartbeat-Log.

Wir müssen das Log auf Signal eingrenzen, sonst ersaufen wir im Rauschen.

Bitte genau so:

openclaw logs --follow | grep -iE 'signal|receive|send|pair|error|exception'

Dann:

eine Signal-Nachricht schicken
10 Sekunden warten
mit Ctrl+C stoppen
die Ausgabe hier posten

Wichtig:

Wenn gar nichts erscheint, ist das ebenfalls ein starkes Signal, dann wissen wir:

#

deine Signal-Nachricht kommt gar nicht erst als Event im Gateway an.

#

Ja, das ist wahrscheinlich nur Zeitzonen-Mix, nicht der Fehler.

Du hattest bisher beides:

+00:00 = UTC
+02:00 = lokale Zeit

Das ist unschön, aber erstmal normal genug und nicht der eigentliche Signal-Bug.

Wichtiger ist weiter nur das hier:

openclaw logs --follow | grep -iE 'signal|receive|send|pair|error|exception'

Dann eine Signal-Nachricht schicken und schauen:

kommt da etwas
oder kommt gar nichts

#

Genau das brauchen wir als Nächstes.

grave tendonBOT Apr 23, 2026, 10:45 AM

#

Okay, ich glaube wir haben das jetzt sauber auseinandergezogen.

Im Log sehe ich nicht mehr primär einen kaputten Signal-Transport, sondern das hier als echten Blocker:

Context overflow ... provider=ollama/glm-5.1:cloud ... messages=145
Auto-compaction failed ... Restarting session

Das heißt sehr wahrscheinlich:

Signal-Startup war tatsächlich zu knapp, das haben wir verbessert.
Dein eigentlicher Reply-Pfad scheitert jetzt am Agent-/Session-Zustand, nicht mehr primär an Signal.
Das erklärt auch gut, warum es sich wie “Signal antwortet nicht” anfühlt, obwohl der Kanal selbst grün ist.

Mein aktueller Befund

Du hast gerade mindestens zwei getrennte Probleme:

#

Signal-Startup-Timeout auf dem Pi, jetzt entschärft
Context overflow / Session kaputt auf ollama/glm-5.1:cloud

Und separat noch:

TUI-Problem mit unknown agent id "main"

Schnellster Test, den ich jetzt empfehlen würde

Bitte probier einen ganz frischen / wenig benutzten Agenten oder eine frische Session, nicht den alten langen Chat.

Wenn ein frischer Agent über Signal antwortet, dann wissen wir:

Signal ist okay
der alte Agent-/Session-Kontext ist das eigentliche Problem

Wenn du willst, machen wir jetzt genau diesen nächsten Schritt:

sag mir welcher Agent nicht antwortet
und ob du einen anderen, kaum benutzten Agenten zum Testen hast

#

Dann sage ich dir den sinnvollsten nächsten Move, ohne weiter im Kreis zu drehen.

#

Ja, das ist jetzt ziemlich eindeutig.

Der entscheidende Teil ist nicht mehr Signal, sondern dein aktueller Modell-/Backend-Pfad:

provider=ollama/glm-5.1:cloud
Context overflow schon bei 8 Nachrichten
danach 503 Service Temporarily Unavailable
Auto-compaction schlägt fehl, Session wird neu gestartet

Das erklärt sehr gut, warum über Signal nichts zurückkommt, obwohl der Kanal selbst auf works steht.

Wichtigste Schlussfolgerung

/reset reicht hier nicht, weil das Problem nicht nur alter Chat-Verlauf ist.
Der aktuell verwendete Modellpfad ist gerade instabil / ungeeignet.

Meine klare Empfehlung

Temporär den betroffenen Agenten von diesem Modell wegschalten.

#

Die relevanten Config-Stellen laut Docs sind:

global: agents.defaults.model.primary
pro Agent: agents.list[].model

Model-Doku:

Ich würde also jetzt so vorgehen:

Nicht weiter Signal debuggen
Den betroffenen Agenten auf einen anderen, in deinem Setup stabilen Modellpfad umstellen
Gateway neu starten
Dann Signal nochmal testen

Wenn du willst, machen wir den nächsten Schritt ganz konkret:
Poste den redaktierten Block von

#

agents.defaults.model
und falls vorhanden den passenden agents.list[] Eintrag für den betroffenen Agenten

Dann sage ich dir exakt, welche Stelle du ändern musst.

grave tendonBOT Apr 23, 2026, 12:25 PM

#

Das Log bestätigt für mich nochmal:

Signal selbst sieht gesund aus (Signal: ok)
der SIGTERM-Teil ist ein normaler Shutdown, kein Crash
ich sehe hier weiter keinen Hinweis, dass der Signal-Kanal selbst der Hauptfehler ist

Also ehrlich: Ich würde jetzt aufhören, Signal weiter zu debuggen.
Der wahrscheinlichere Blocker bleibt der Modell-/Session-Pfad mit glm-5.1:cloud + Context Overflow / 503.

Nächster sinnvoller Schritt

Öffne ~/.openclaw/openclaw.json, suche nach:

glm-5.1:cloud

und poste bitte den umgebenden model-Block redaktiert hier rein.

#

Am einfachsten:

in Mousepad nach glm-5.1:cloud suchen
den Abschnitt mit agents.defaults.model oder dem passenden agents.list[]-Eintrag kopieren
Tokens/IDs schwärzen, den Modellnamen bitte stehen lassen

Dann kann ich dir genau sagen, was du ändern musst.

Kleine Randnotiz:
signal daemon exited (code=0) beim Shutdown ist sauber, auch wenn es im Log als error auftaucht.

#

Das sind wieder nur Startup-Zeilen, noch nicht der Modell-Block, den ich brauche.

Lass uns das jetzt maximal eindeutig machen. Bitte genau nur diesen einen Befehl:

grep -n -C 6 'glm-5.1:cloud' ~/.openclaw/openclaw.json

Der zeigt mir die 6 Zeilen davor und danach, also genau den relevanten Config-Ausschnitt.

Wenn da nichts kommt, schreib einfach:
„kein Treffer“

Dann gehen wir den nächsten Schritt.

chilly egret Apr 23, 2026, 12:29 PM

#

grep -n -C 6 'glm-5.1:cloud' ~/.openclaw/openclaw.json
75- "ollama": {
76- "baseUrl": "http://█",
77- "apiKey": "█",
78- "api": "ollama",
79- "models": [
80- {
81: "id": "glm-5.1:cloud",
82- "name": "glm 5.1█",
83- "api": "ollama",
84- "reasoning": false,
85- "input": [
86- "text"
87- ],

225- }
226- }
227- },
228- "agents": {
229- "defaults": {
230- "model": {
231: "primary": "ollama/glm-5.1:cloud"
232- },
233- "models": {
234: "ollama/glm-5.1:cloud": {
235- "params": {
236- "maxTokens": 4096
237- }
238- },
239- "anthropic/claude-sonnet-4-6": {
240- "params": {

312- "typingMode": "instant",
313- "typingIntervalSeconds": 8
314- },
315- "list": [
316- {
317- "id": "Miro",
318: "model": "ollama/glm-5.1:cloud",
319- "tools": {
320- "alsoAllow": [
321- "browser"
322- ]
323- },
324- "subagents": {

grave tendonBOT Apr 23, 2026, 12:30 PM

#

Perfekt, jetzt ist es eindeutig.

Der Agent Miro ist zweifach auf das kaputte Modell gepinnt:

global:

"agents.defaults.model.primary": "ollama/glm-5.1:cloud"

und nochmal direkt für den Agenten:

"agents.list[].id == Miro"
"model": "ollama/glm-5.1:cloud"

Deshalb bringt es nichts, nur am Kanal rumzuschrauben.
Und selbst wenn du nur den Default änderst, würde Miro trotzdem weiter GLM benutzen, weil der Agent einen eigenen Override hat.

#

Was ich jetzt konkret machen würde

Da in deiner Config schon ein anderer erlaubter Modellpfad auftaucht, würde ich testweise beide Stellen umstellen auf:

"anthropic/claude-sonnet-4-6"

Also:

1) Default ändern

Von:

"primary": "ollama/glm-5.1:cloud"

Zu:

#

"primary": "anthropic/claude-sonnet-4-6"

2) Agent `Miro` ändern

Von:

"id": "Miro",
"model": "ollama/glm-5.1:cloud"

Zu:

"id": "Miro",
"model": "anthropic/claude-sonnet-4-6"

#

3) Danach

openclaw gateway restart
openclaw channels status --probe

4) Dann sofort Signal testen

normale Textnachricht
/status

Wichtiger Hinweis

Den glm-5.1:cloud-Eintrag noch nicht löschen, nur nicht mehr aktiv benutzen.

Wenn bei Anthropic danach ein Auth-Fehler kommt, wissen wir sofort, dass wir als Nächstes die Auth prüfen müssen.
Wenn Signal dann wieder antwortet, haben wir den echten Hauptfehler gefunden.

Wenn du magst, poste danach einfach nur noch:

#

„umgestellt“
Ergebnis von openclaw channels status --probe
und ob Signal wieder antwortet

Glad we caught the eigentliche Ursache.

chilly egret Apr 23, 2026, 1:52 PM

#

Ich hatte noch andere Schwierigkeiten. Folgende Änderungen habe ich gemacht um überhaupt wieder sinnvoll mir meinem Agenten chatten zu können:

separates leistungsstarkes modell nur für die compaction runs Eingestellt
startupcontext=false
heartbeat erstmal deaktiviert
cronjobs deaktiviert
Compaction safeguard mode
und "contextPruning": {
"mode": "cache-ttl",
"ttl": "5m"

Wie sollte ich jetzt weiter vorgehen um signal wieder zum Laufen zu bekommen? Ich vermute hiermit ist schonmal ein rieseiger schritt getan!

grave tendonBOT Apr 23, 2026, 1:53 PM

#

Ja, das klingt nach einem riesigen Schritt. 👍
Vor allem, weil du damit die größte Störquelle, nämlich Context Overflow + kaputte Compaction, erstmal entschärft hast.

Ich würde jetzt nicht noch mehr umbauen, sondern Signal sauber isoliert testen.

Mein Vorschlag für die nächsten Schritte

1) Den jetzigen Zustand erstmal einfrieren

Für den Moment so lassen:

stärkeres Modell für Compaction
startupContext: false
Heartbeat aus
Cronjobs aus
compaction safeguard mode
contextPruning.mode = "cache-ttl"
contextPruning.ttl = "5m"
channels.signal.startupTimeoutMs = 60000

#

Gerade nicht wieder parallel rumdrehen.

2) Sauberer Baseline-Test für Signal

openclaw gateway restart
openclaw channels status --probe

Wenn das grün ist, dann im zweiten Terminal:

openclaw logs --follow | grep -iE 'signal|pair|error|exception'

Dann über Signal nur eine normale Textnachricht schicken, kein /status zuerst.

#

Warum?
Plain text testet den normalen Inbound/Reply-Pfad ohne extra Command-Magie.

3) Danach genau unterscheiden

Fall A: normale Textnachricht funktioniert

dann Signal lebt wieder
danach /status testen
wenn /status scheitert, ist es eher ein Command-/Session-Thema, nicht Signal selbst

Fall B: normale Textnachricht funktioniert nicht

dann poste die neuen Signal-Logzeilen
dann schauen wir nur noch auf den Channel-Ingress

#

4) Erst wenn Signal stabil ist, Sachen einzeln wieder einschalten

Meine Reihenfolge wäre:

Signal stabiler Textchat
/status
Heartbeat
einzelne Cronjobs
ganz zuletzt wieder mehr Kontext/Komfort-Features

Also wirklich eins nach dem anderen, sonst weißt du hinterher wieder nicht, was den Ausschlag gegeben hat.

Meine Empfehlung

Der nächste konkrete Test sollte sein:

Gateway restart
Probe grün?
eine einzige normale Signal-Textnachricht

#

passende Signal-Logs daneben

Wenn du magst, poste danach einfach nur:

Probe: grün/rot
Normale Textnachricht: geht/geht nicht
und die neuen Signal-Logzeilen, falls es nicht geht

Ich glaube, du bist jetzt deutlich näher dran als am Anfang.

chilly egret Apr 23, 2026, 3:46 PM

#

2.) openclaw channels status --probe

🦞 OpenClaw 2026.4.21 (f788c88) — I've survived more breaking changes than your last three relationships.

│
◇
Gateway reachable.

Signal default: enabled, configured, running, url:http:XXX, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

grave tendonBOT Apr 23, 2026, 3:47 PM

#

Perfekt, Probe ist grün. Das ist schon mal die halbe Miete.

Jetzt kommt der entscheidende Test:

3) Echte Signal-Nachricht testen

Im Terminal:

openclaw logs --follow | grep -iE 'signal|pair|error|exception'

Dann über Signal eine ganz normale Textnachricht schicken, zum Beispiel:

test

#

Bitte noch nicht /status, erst Plain Text.

Danach sag mir einfach eines von beiden:

„normale Textnachricht funktioniert“
„normale Textnachricht funktioniert nicht“

Und wenn sie nicht funktioniert, poste die neuen Logzeilen aus dem Terminal.
Dann können wir endlich sehen, ob das Problem jetzt noch im Signal-Ingress oder schon wieder im Reply-Pfad sitzt.

chilly egret Apr 23, 2026, 3:51 PM

#

2.b)
openclaw logs --follow | grep -iE 'signal|pair|error|exception'
2026-04-23T15:43:49.751Z error (node:█) [█] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
2026-04-23T15:44:00.666Z info gateway {"subsystem":"gateway"} ready (6 plugins: acpx, browser, device-pair, phone-control, signal, talk-voice; 10.7s)
2026-04-23T15:44:28.034Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} [default] starting provider (http://127.0.0.1:█)
2026-04-23T15:44:34.518Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} signal-cli: INFO DaemonCommand - Starting daemon in single-account mode for +█
2026-04-23T15:44:34.584Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} signal-cli: INFO HttpServerHandler - Started HTTP server on /127.0.0.1:█

Signal default: enabled, configured, running, url:http://127.0.0.1:█, works

grave tendonBOT Apr 23, 2026, 3:51 PM

#

Danke, aber das ist leider immer noch nur der Startup.
Der eigentliche Ingress-Test fehlt noch.

Bitte genau in dieser Reihenfolge:

openclaw logs --follow | grep -iE 'signal|pair|error|exception'
warten, bis du sowas siehst:
```
Signal default ... works
```
erst dann über Signal eine normale Nachricht schicken:
```
test
```
10 Sekunden warten

Dann brauche ich von dir nur eine dieser beiden Antworten:

#

„Nach test kamen neue Logzeilen“ + diese Zeilen
„Nach test kam nichts Neues im Log“

Gerade haben wir nur bewiesen, dass Signal hochfährt, aber noch nicht, ob deine Nachricht reinkommt.

chilly egret Apr 23, 2026, 3:53 PM

#

Keine neuen Zeilen!

grave tendonBOT Apr 23, 2026, 3:54 PM

#

Das ist super wertvoll. Damit wissen wir jetzt:

Deine Signal-Nachricht kommt aktuell gar nicht als Inbound-Event im Gateway an.

Also im Moment nicht der Reply-Pfad, nicht Compaction, nicht das Modell.
Der Bruch sitzt jetzt sehr wahrscheinlich vor OpenClaw, also bei Signal / signal-cli / Device-Link / Account-State.

Damit ich dir den richtigen nächsten Schritt sagen kann, brauche ich jetzt nur diese zwei Infos:

Wie ist Signal bei dir eingerichtet?
- A: per QR als gelinktes Gerät (signal-cli link)
- B: als eigene registrierte Nummer / eigener Bot-Account
Von wo schreibst du dem Bot?
- von derselben Signal-Identität wie der Bot
- oder von einer anderen Signal-Nummer / einem anderen Account

#

Warum ich das frage:

Bei gelinktem Gerät ist der nächste Verdacht oft: Link/Sync kaputt
Bei eigener Bot-Nummer ist der nächste Verdacht eher: Account-/Receive-State in signal-cli
Und wenn du von derselben Identität schreibst, greift ggf. Loop-Protection

Wenn du mir nur kurz mit
„A oder B“ und „gleiche oder andere Identität“ antwortest, kann ich dir den nächsten sinnvollen Schritt direkt sagen.

chilly egret Apr 23, 2026, 4:02 PM

#

1.B Bot mit eigener Signal nummer.
2.B von einem anderen Signal account,

Es hatte alles funktioniert, bis wir gestern über ein sh-skript versucht haben eine nachricht an meinen account zu schicken. Es kam sogar eine nachricht an. Danach war keine kommunikation mehr zum Agenten möglich.

openclaw agent --agent "$AGENT" $SESSION_FLAG \
    --message "$MSG -- Sende diese Nachricht an XXX auf Signal!" \
    --deliver --timeout 60 2>/dev/null || true

grave tendonBOT Apr 23, 2026, 4:03 PM

#

Ja, ich glaube auch, dass du schon einen riesigen Schritt gemacht hast.

Mein aktueller Stand ist jetzt ziemlich klar:

OpenClaw selbst ist wieder deutlich gesünder
Signal-Provider / lokaler Daemon kommen hoch und stehen auf works
aber echte Inbound-Signal-Nachrichten kommen nicht mehr rein
bei eigener Bot-Nummer + anderem Signal-Account ist damit Loop-Protection raus
der Restverdacht liegt jetzt am ehesten auf dem signal-cli Account-/Receive-State, nicht mehr auf OpenClaw

Meine Empfehlung

Ich würde ab hier Signal als separates Problem behandeln.

Empfohlener Weg

Deine jetzigen OpenClaw-Stabilisierungen erstmal so lassen
signal-cli Daten sichern
- laut Doku typischerweise: ~/.local/share/signal-cli/data/

#

Dann den dedizierten Bot-Account auf Signal-Seite reparieren, notfalls neu registrieren / verifizieren

Die in der Doku verifizierten Schritte für eine dedizierte Nummer sind:

signal-cli -a +<BOT_PHONE_NUMBER> register
signal-cli -a +<BOT_PHONE_NUMBER> verify <VERIFICATION_CODE>

Signal-Doku in OpenClaw:
https://docs.openclaw.ai/channels/signal

Warum ich das empfehle

Weil wir inzwischen ziemlich gut eingegrenzt haben:

Channel-Probe grün
kein Inbound-Event bei echter Nachricht
anderer Sender

#

eigene Bot-Nummer

Das riecht leider sehr nach kaputtem Signal-Account-/Receive-Zustand und nicht mehr nach einem OpenClaw-Routingproblem.

Zwei sinnvolle Optionen

Option A, empfohlen:
Bot-Nummer / signal-cli Account reparieren bzw. neu verifizieren.

Option B, vorsichtiger:
Vorher noch einen standalone signal-cli-Test außerhalb von OpenClaw machen, um endgültig zu beweisen, dass schon signal-cli selbst nichts mehr empfängt.

Wenn du willst, gehen wir jetzt Schritt für Schritt durch Option A.
Wenn du lieber maximal vorsichtig sein willst, machen wir erst Option B.

chilly egret Apr 23, 2026, 4:05 PM

#

Lass uns option B versuchen.

grave tendonBOT Apr 23, 2026, 4:06 PM

#

Ja, machen wir. Dann testen wir signal-cli komplett ohne OpenClaw.

Option B, standalone-Test

1) Gateway stoppen

openclaw gateway stop

2) Von deinem anderen Signal-Account eine neue Testnachricht an die Bot-Nummer schicken

Zum Beispiel:

standalone-test

3) Danach auf dem Server direkt `signal-cli` lesen lassen

#

signal-cli -a +<BOT_NUMMER> receive

Was wir daraus lernen

Wenn die Nachricht hier auftaucht → signal-cli kann empfangen, dann liegt das Problem eher bei OpenClaw/Integration
Wenn hier nichts auftaucht → das Problem sitzt schon in signal-cli bzw. beim Signal-Account selbst

Danach bitte nur kurz zurückmelden

„receive hat die Nachricht gezeigt“
oder
„receive hat nichts gezeigt“
oder
die Fehlermeldung, falls eine kommt

Kleine Randnotiz:
Falls signal-cli nicht im PATH ist, sag kurz Bescheid, dann nehmen wir den vollen Pfad.

chilly egret Apr 23, 2026, 4:12 PM

#

signal-cli empfängt die nachricht.

grave tendonBOT Apr 23, 2026, 4:13 PM

#

Das ist ein sehr gutes Ergebnis. Damit ist jetzt klar:

Signal-Account selbst ist okay
signal-cli selbst kann empfangen
der Bruch sitzt also zwischen OpenClaw und dem von OpenClaw verwalteten signal-cli-Daemon, sehr wahrscheinlich bei der Daemon-/SSE-Integration, nicht bei Signal selbst

Damit würde ich jetzt den nächsten Schritt so machen:

Empfehlung: auf external daemon mode umstellen

Also signal-cli separat laufen lassen und OpenClaw nur noch auf den HTTP-Daemon zeigen lassen.

In ~/.openclaw/openclaw.json:

{
  channels: {

#

    signal: {
      httpUrl: "http://127.0.0.1:8080",
      autoStart: false
    }
  }
}

Dann:

1) signal-cli manuell starten

Mit derselben Bot-Nummer wie bisher:

signal-cli -a +<BOT_NUMMER> daemon --http 127.0.0.1:8080 --receive-mode on-start

#

2) In einem zweiten Terminal OpenClaw starten

openclaw gateway start

3) Danach testen

openclaw channels status --probe

Und dann wieder eine normale Signal-Nachricht schicken.

Warum das sinnvoll ist

Wir haben jetzt sauber bewiesen:

standalone signal-cli receive funktioniert
unter OpenClaw-eigenem Daemon kommt nichts rein

#

Das ist genau der Fall, für den external daemon mode oft der pragmatische Workaround ist.

Doku dazu:
https://docs.openclaw.ai/channels/signal

Wenn du willst, machen wir den nächsten Schritt jetzt ganz konkret zusammen:

du stellst httpUrl + autoStart:false
startest signal-cli manuell
und postest dann nur noch:
- channels status --probe
- und ob die normale Signal-Textnachricht wieder ankommt

chilly egret Apr 23, 2026, 4:21 PM

#

Bisher sieht die openclaw.json so aus:
"channels": {
"signal": {
"enabled": true,
"account": "+█",
"cliPath": "/usr/█/█/signal-cli",
"receiveMode": "on-start",
"dmPolicy": "allowlist",
"startupTimeoutMs": 60000,
"allowFrom": [
"uuid:█"
],
"groupPolicy": "allowlist",
"heartbeat": {
"showOk": true,
"showAlerts": true,
"useIndicator": true
},

grave tendonBOT Apr 23, 2026, 4:23 PM

#

Ja, das passt gut, danke.
Ich würde deinen signal-Block jetzt minimal so erweitern, nicht komplett umbauen.

So würde ich ihn ändern

"channels": {
  "signal": {
    "enabled": true,
    "account": "+█",
    "cliPath": "/usr/█/█/signal-cli",
    "httpUrl": "http://127.0.0.1:8080",
    "autoStart": false,
    "receiveMode": "on-start",
    "dmPolicy": "allowlist",
    "startupTimeoutMs": 60000,

#

    "allowFrom": [
      "uuid:█"
    ],
    "groupPolicy": "allowlist",
    "heartbeat": {
      "showOk": true,
      "showAlerts": true,
      "useIndicator": true
    }
  }
}

Wichtig

neu dazu:
- "httpUrl": "http://127.0.0.1:8080"

#

"autoStart": false
den Rest erstmal so lassen
startupTimeoutMs kann drinbleiben, auch wenn es mit autoStart:false erstmal weniger wichtig wird

Danach in dieser Reihenfolge

1) Config speichern

2) signal-cli manuell starten

/usr/█/█/signal-cli -a +<BOT_NUMMER> daemon --http 127.0.0.1:8080 --receive-mode on-start

3) In einem zweiten Terminal OpenClaw starten

openclaw gateway start

#

4) Prüfen

openclaw channels status --probe

5) Dann normale Signal-Textnachricht testen

Wenn du magst, poste danach einfach nur:

Probe: grün/rot
Textnachricht: geht/geht nicht

Dann sehen wir sofort, ob der external-daemon-Workaround greift.

chilly egret Apr 23, 2026, 4:29 PM

#

Oh den Teil hatte ich vergessen:
"groupPolicy": "allowlist",
"heartbeat": {
"showOk": true,
"showAlerts": true,
"useIndicator": true
},
"healthMonitor": {
"enabled": true
}
}
},

Soll ich den healthMonitor an lassen oder auf false setzen?

grave tendonBOT Apr 23, 2026, 4:30 PM

#

Für diesen Test würde ich den healthMonitor temporär auf false setzen.

Warum:

wir wollen gerade den Setup so simpel wie möglich machen
healthMonitor.enabled steuert laut Doku die auto-restarts / health-monitor restarts pro Channel
beim external daemon mode will ich erstmal keine zusätzliche Automatik, die uns wieder dazwischenfunkt

Also für den Debug-Setup würde ich Signal so fahren:

"signal": {
  "enabled": true,
  "account": "+█",
  "cliPath": "/usr/█/█/signal-cli",
  "httpUrl": "http://127.0.0.1:8080",
  "autoStart": false,

#

  "receiveMode": "on-start",
  "dmPolicy": "allowlist",
  "startupTimeoutMs": 60000,
  "allowFrom": [
    "uuid:█"
  ],
  "groupPolicy": "allowlist",
  "heartbeat": {
    "showOk": true,
    "showAlerts": true,
    "useIndicator": true
  },
  "healthMonitor": {
    "enabled": false
  }

#

Meine Empfehlung

für jetzt: healthMonitor = false
wenn Signal wieder stabil läuft: später testweise wieder true

Das ist einfach die sauberere Debug-Reihenfolge.

chilly egret Apr 23, 2026, 4:43 PM

#

openclaw channels status --probe

🦞 OpenClaw 2026.4.21 (f788c88) — Alexa, but with taste.

│
◇
Gateway reachable.

Signal default: enabled, configured, running, url:http:XXX works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

Nachricht kommt im signal-cli an aber nicht in openclaw blockt die allow list? In der allow list ist eineuuid angegeben aber keine Telefonnummer.

grave tendonBOT Apr 23, 2026, 4:44 PM

#

Ja, das kann sehr gut der Grund sein. Ich glaube, du hast da was Echtes gefunden.

Ich habe gerade im Signal-Code nachgeschaut:

OpenClaw bevorzugt sourceNumber vor sourceUuid
und die Allowlist matcht typ-scharf:
- Telefonnummer ↔ Telefonnummer
- UUID ↔ UUID
ein uuid:...-Eintrag matcht nicht auf eine eingehende Telefonnummer

Das heißt:
Wenn dein Sender jetzt als sourceNumber reinkommt, aber in allowFrom nur eine UUID steht, dann wird die DM geblockt.

Mein klarer nächster Schritt

Ergänze in channels.signal.allowFrom zusätzlich die Telefonnummer des sendenden Accounts in E.164-Format.

Also z. B. so:

#

"allowFrom": [
  "uuid:█",
  "+49XXXXXXXXXXX"
]

Wichtig:

mit +
volle internationale Nummer
die Nummer des sendenden Accounts, nicht die Bot-Nummer

Danach

openclaw gateway restart
openclaw channels status --probe

#

Und dann nochmal eine normale Signal-Textnachricht testen.

Warum ich jetzt recht zuversichtlich bin

Das passt perfekt zu deinem Befund:

signal-cli empfängt
OpenClaw sieht sonst keinen Inbound
dmPolicy ist allowlist
allowFrom enthält aktuell nur uuid:...

Das ist genau die Art von Mismatch, die still blocken kann.

Wenn du willst, poste danach nur noch:

allowFrom ergänzt: ja/nein
Textnachricht geht / geht nicht

Ich bin ehrlich gesagt ziemlich optimistisch, dass das jetzt der fehlende Hebel ist.

chilly egret Apr 23, 2026, 4:48 PM

#

allowlist nummer ergänzt. Kommunikation funktioniert wieder! Danke!!!!!!!!!!!

grave tendonBOT Apr 23, 2026, 4:49 PM

#

Yesss, super 🎉

Dann war die eigentliche Ursache am Ende:

dmPolicy: "allowlist"
eingehender Sender kam als Telefonnummer
in allowFrom stand nur die UUID
und Signal matched da typgenau, also uuid ≠ phone

Deshalb hat signal-cli die Nachricht gesehen, OpenClaw sie aber still geblockt.

Ich würde jetzt erstmal:

startupTimeoutMs: 60000 drin lassen
die stabileren Compaction-Einstellungen erstmal drin lassen
Heartbeat / Cronjobs später eins nach dem anderen wieder aktivieren

Glad that helped! 🎉

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

#Ich habe meine Signal Verbindung zu meinem Agenten zerstört.

Mein klarer erster Fix

Wichtig

Damit ist der nächste sinnvolle Schritt:

Ich würde jetzt so vorgehen

Bitte jetzt genau diesen Realtest

Bitte genau so:

Bitte genau so:

Mein aktueller Befund

Schnellster Test, den ich jetzt empfehlen würde

Wichtigste Schlussfolgerung

Meine klare Empfehlung

Nächster sinnvoller Schritt

grep -n -C 6 'glm-5.1:cloud' ~/.openclaw/openclaw.json 75- "ollama": { 76- "baseUrl": "http://█", 77- "apiKey": "█", 78- "api": "ollama", 79- "models": [ 80- { 81: "id": "glm-5.1:cloud", 82- "name": "glm 5.1█", 83- "api": "ollama", 84- "reasoning": false, 85- "input": [ 86- "text" 87- ],

225- } 226- } 227- }, 228- "agents": { 229- "defaults": { 230- "model": { 231: "primary": "ollama/glm-5.1:cloud" 232- }, 233- "models": { 234: "ollama/glm-5.1:cloud": { 235- "params": { 236- "maxTokens": 4096 237- } 238- }, 239- "anthropic/claude-sonnet-4-6": { 240- "params": {

Was ich jetzt konkret machen würde

1) Default ändern

2) Agent Miro ändern

3) Danach

4) Dann sofort Signal testen

Wichtiger Hinweis

Mein Vorschlag für die nächsten Schritte

1) Den jetzigen Zustand erstmal einfrieren

2) Sauberer Baseline-Test für Signal

3) Danach genau unterscheiden

4) Erst wenn Signal stabil ist, Sachen einzeln wieder einschalten

Meine Empfehlung

3) Echte Signal-Nachricht testen

Meine Empfehlung

Empfohlener Weg

Warum ich das empfehle

Zwei sinnvolle Optionen

Option B, standalone-Test

1) Gateway stoppen

2) Von deinem anderen Signal-Account eine neue Testnachricht an die Bot-Nummer schicken

3) Danach auf dem Server direkt signal-cli lesen lassen

Was wir daraus lernen

Danach bitte nur kurz zurückmelden

Empfehlung: auf external daemon mode umstellen

1) signal-cli manuell starten

2) In einem zweiten Terminal OpenClaw starten

3) Danach testen

Warum das sinnvoll ist

So würde ich ihn ändern

Wichtig

Danach in dieser Reihenfolge

1) Config speichern

2) signal-cli manuell starten

3) In einem zweiten Terminal OpenClaw starten

4) Prüfen

5) Dann normale Signal-Textnachricht testen

Meine Empfehlung

Mein klarer nächster Schritt

Danach

Warum ich jetzt recht zuversichtlich bin

grep -n -C 6 'glm-5.1:cloud' ~/.openclaw/openclaw.json
75- "ollama": {
76- "baseUrl": "http://█",
77- "apiKey": "█",
78- "api": "ollama",
79- "models": [
80- {
81: "id": "glm-5.1:cloud",
82- "name": "glm 5.1█",
83- "api": "ollama",
84- "reasoning": false,
85- "input": [
86- "text"
87- ],

225- }
226- }
227- },
228- "agents": {
229- "defaults": {
230- "model": {
231: "primary": "ollama/glm-5.1:cloud"
232- },
233- "models": {
234: "ollama/glm-5.1:cloud": {
235- "params": {
236- "maxTokens": 4096
237- }
238- },
239- "anthropic/claude-sonnet-4-6": {
240- "params": {

2) Agent `Miro` ändern

3) Danach auf dem Server direkt `signal-cli` lesen lassen