exec host=gateway | Friends of the Crustacean 🦞🤝 | Page 1

fathom ledgeBOT Mar 4, 2026, 8:13 PM

#

Nicht neu aufsetzen. Erstmal Config wieder in einen “known-good” Zustand bringen – das ist fast sicher nur Tool-Policy/Sandbox/Exec-Host-Resolution, nicht “alles kaputt”.

1) Auf dem VPS: Fakten holen (bitte Output hier rein)

openclaw --version
openclaw config file
openclaw config validate
openclaw sandbox explain
openclaw gateway status

Die zwei Commands, die in deinem Symptom-Cluster am meisten verraten, sind sandbox explain (zeigt effektive Sandbox + Tool-Allow/Deny) und config validate (Schema/unknown keys).

Docs dazu:

#

2) Schnellster “rescue fix” (damit Tools wieder da sind)

Sehr häufig ist die Ursache: du hast irgendwo tools.allow (oder tools.sandbox.tools.allow) gesetzt und nicht group:fs/group:runtime drin → dann wirkt das wie ein Allowlist-Hardcut und alles andere ist “weg”.

Zum Test: alles erlauben (nur zum Recovern, später wieder härten):

openclaw config set tools.allow '["group:openclaw"]' --strict-json
openclaw config unset tools.sandbox.tools.allow
openclaw config unset tools.sandbox.tools.deny

Dann exec default auf gateway (weil host=sandbox inzwischen fail-closed sein kann, wenn Sandbox mode off ist):

openclaw config set tools.exec.host "gateway"

Wenn exec host=gateway bei dir “not allowed” war: temporär einmal “full” setzen (damit du überhaupt wieder handeln kannst), danach wieder zurück auf allowlist:

#

openclaw config set tools.exec.security "full"
openclaw config set tools.exec.ask "off"

Dann:

openclaw gateway restart

3) Doppel-Key im JSON: so gehst du’s an

Nicht weiter manuell “rumeditieren”, bis du weißt welche Datei aktiv ist → openclaw config file.
Dann die Datei öffnen und nach doppelten Blöcken suchen (typisch: tools: { ... } zweimal).
Danach wieder openclaw config validate laufen lassen.

4) Warum das genau zu deinen Symptomen passt

“tools: not found” passt perfekt zu: tools.allow gesetzt, aber falsche Einträge / fehlende Gruppen. (Wenn allow nicht leer ist, ist der Rest blockiert.)

#

“exec sandbox: funktioniert nicht / keine rechte” passt zu: Sandbox ist aus (oder Docker nicht verfügbar) und host=sandbox ist explizit/default → exec fail-closed.
“exec gateway: not allowed” passt zu: tools.exec.security=deny oder Tool policy blockt exec, oder approvals/security-mode greift.

Poste bitte die Outputs aus Schritt 1 (vor allem sandbox explain + config validate), dann sag ich dir exakt, welcher Key gerade “gewinnt” und welche 2–3 Zeilen du final brauchst (ohne dauerhaft full offen zu lassen).

nova thorn Mar 4, 2026, 8:21 PM

#

openclaw --version:
2026.3.1
2. openclaw config file:
Config was last written by a newer OpenClaw (2026.3.2); current version is 2026.3.1. ~/.openclaw/openclaw.json
openclaw config validate:
Config was last written by a newer OpenClaw (2026.3.2); current version is 2026.3.1.
error: too many arguments for 'config'. Expected 0 arguments but got 1.
openclaw sandbox explain:
🦞 OpenClaw 2026.3.1 (2a8ac97) — Gateway online
Sandbox Commands: - explain Explain effective sandbox/tool policy

list List sandbox containers - recreate Force recreation with updated config

openclaw gateway status:
Gateway already running (pid 34)
Port 18789 is already in use
Gateway online!

Zusammenfassung:

┌─────────────────┬───────────────────────────────────────┐
│ Befehl │ Ergebnis │
├─────────────────┼───────────────────────────────────────┤
│ --version │ 2026.3.1 │
├─────────────────┼───────────────────────────────────────┤
│ config file │ ~/.openclaw/openclaw.json │
├─────────────────┼───────────────────────────────────────┤
│ config validate │ ❌ Befehl nicht gefunden (nur config) │
├─────────────────┼───────────────────────────────────────┤
│ sandbox explain │ ✅ Gateway online, Sandbox aktiv │
├─────────────────┼───────────────────────────────────────┤
│ gateway status │ ✅ Gateway läuft (PID 34) │
└─────────────────┴───────────────────────────────────────┘

fathom ledgeBOT Mar 4, 2026, 8:22 PM

#

Das neue, wichtigste Signal aus deinem Output ist nicht “Sandbox aktiv” – sondern:

Du hast OpenClaw 2026.3.1 installiert
deine Config wurde aber von 2026.3.2 geschrieben
→ deshalb wirkt openclaw config validate bei dir wie “gibts nicht / zu viele args”, weil diese Subcommands in deiner CLI offenbar fehlen/anders sind.

Solange CLI/Schema nicht zusammenpassen, debugst du im Kreis.

Dein Move (in der Reihenfolge)

0) Versionen geradeziehen (Pflicht)

Update OpenClaw auf ≥ 2026.3.2 (idealerweise latest) – mit dem gleichen Tool, mit dem du es installiert hast:

wenn’s via npm war:

npm i -g openclaw@latest

#

wenn’s via pnpm war:

pnpm add -g openclaw@latest

Danach:

openclaw --version
openclaw gateway restart

1) Die zwei Debug-Ausgaben, die ich als nächstes brauche

Du hast bei sandbox explain sehr wahrscheinlich nur openclaw sandbox (help) erwischt. Bitte exakt:

openclaw sandbox explain

#

Und zusätzlich (ohne Secrets, nur die relevanten Zeilen aus der Config):

grep -nE 'tools\\s*:|tools\\.allow|tools\\.deny|tools\\.exec\\.host|exec\\.host|sandbox\\.mode|tools\\.sandbox\\.tools' ~/.openclaw/openclaw.json

Das zeigt uns sofort:

ob du tools.allow gesetzt hast (und damit evtl. alles andere “weg-allowlistest”)
ob du tools.exec.host vs exec.host doppelt/konfliktierend drin hast
ob tools.sandbox.tools.allow/deny dich in Gruppen-Chats einsperrt

2) Warum deine Symptome dazu passen

“ALLE tools: not found” passiert fast immer, wenn tools.allow (oder tools.sandbox.tools.allow) gesetzt ist, aber die Gruppen wie group:fs/group:runtime nicht drin sind. Dann sind read/exec/... effektiv geblockt.
“exec sandbox geht nicht” passt zu: Sandbox ist aus oder Docker fehlt, aber tools.exec.host="sandbox" ist (implizit/explicit) → fail-closed.

Wenn du die 2 Outputs aus (1) postest, kann ich dir die exakten 2–3 Key-Fixes sagen (ohne “neu aufsetzen” und ohne dauerhaft security=full).

nova thorn Mar 4, 2026, 8:31 PM

#

Hier sind die Debug-Ergebnisse für Krill:

openclaw sandbox explain:
Effective sandbox: agentId: main
sessionKey: agent:main:main
runtime: sandboxed
mode: all scope: agent perSession: false

Sandbox tool policy:
allow (default): exec, process, read, write, edit, ...
deny (default): browser, canvas, discord, telegram, ...

Config-Einträge:

=== tools ===
tools.exec.host = gateway ✅

=== sandbox ===
NICHT VORHANDEN

=== agents ===
agents.defaults.sandbox: {'mode': 'all'} ⚠️

Analyse:

tools.exec.host = gateway ist korrekt gesetzt ✅
Aber agents.defaults.sandbox.mode = all zwingt ALLES in die Sandbox!

Der Fix:
agents.defaults.sandbox.mode = off

Oder sandbox komplett entfernen. Soll ich das machen?

fathom ledgeBOT Mar 4, 2026, 8:33 PM

#

Ja — für Recovery ist das der richtige Hebel. Gerade weil du in einem Discord-Channel bist (nicht “main”), und agents.defaults.sandbox.mode=all wirklich alles in die Sandbox zwingt.

Was ich jetzt machen würde (sicher + reversibel)

Backup der Config

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%s)

In ~/.openclaw/openclaw.json setzen:

agents: {
  defaults: {
    sandbox: {
      mode: "off",
    },

#

  },
},

Gateway restart

openclaw gateway restart

Danach solltest du in Discord wieder “normal” read/exec/... haben (weil nichts mehr im Sandbox-Container “verschwindet”/abgeschnitten ist).

Falls `exec host=gateway` danach immer noch “not allowed” sagt

Dann ist es nicht mehr Sandbox, sondern tools.exec.security/ask (oder Tool-Policy) auf “deny/zu restriktiv”.

#

Bitte einmal diese Zeilen aus der Config zeigen (ohne Secrets):

grep -nE 'tools\\.allow|tools\\.deny|tools\\.exec\\.(host|security|ask)|tools\\.sandbox|agents\\.defaults\\.sandbox' ~/.openclaw/openclaw.json

Wenn du mir das postest, sag ich dir exakt, welcher Key den Blocker verursacht und welche Minimal-Änderung ihn aufhebt.

Optional (nachdem alles wieder läuft)

Wenn du Sandbox grundsätzlich willst, aber nicht “alles”:

mode: "non-main" ist oft der sweet spot.
und wenn du in Sandbox wirklich am Workspace arbeiten willst: workspaceAccess: "rw" (sonst ist Default "none" und du arbeitest in ~/.openclaw/sandboxes, was sich wie “alles weg” anfühlt).

nova thorn Mar 4, 2026, 8:34 PM

#

Ich führe die Schritte aus: 1. Backup, 2. Sandbox deaktivieren, 3. Restart

● Bash(ssh vps 'docker exec --user node openclaw-n6ky-openclaw-1 cp /data/.openclaw/openclaw.json /data/.openclaw/openclaw.json.bak.$(date +%s) && echo "Backup erstell…)
⎿ bind [127.0.0.1]:9090: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 9090
bind [127.0.0.1]:9443: Address already in use
… +14 lines (ctrl+o to expand)
● Erfolg! ✅ Sandbox deaktiviert:

VORHER: agents.defaults.sandbox.mode = all NACHHER: agents.defaults.sandbox.mode = off
Ergebnis:

Backup erstellt ✅
Sandbox auf mode: "off" gesetzt ✅
Gateway neu gestartet ✅

Jetzt sollten read, exec und alle Tools wieder normal funktionieren (keine Sandbox-Container mehr).

Teste jetzt in Discord! Der Bot sollte wieder auf Befehle reagieren.

fathom ledgeBOT Mar 4, 2026, 8:35 PM

#

Perfekt — wenn agents.defaults.sandbox.mode jetzt wirklich auf off steht und der Gateway restart sauber durch ist, sollten die “Tool not found” / “keine Rechte” Effekte weg sein.

Zwei kurze Checks, damit wir’s wirklich abhaken können:

1) Auf dem VPS (CLI): einmal verifizieren, dass er nicht mehr sandboxed ist

openclaw sandbox explain

Erwartung: runtime: not sandboxed (oder sinngemäß) + mode: off.

2) In Discord: Minimal-Test

Schreib dem Bot z.B.:

“Führe bitte exec aus: pwd && whoami && echo OK”
und dann: “Lies bitte irgendeine harmlose Datei aus dem Workspace (nicht ~/.openclaw/* wegen Tokens)”

Wenn das wieder geht: Ursache war zu 99% wirklich nur mode: all.

#

Nebenbei: die bind 127.0.0.1:9090/9443 Address already in use Meldung kommt von einem kollidierenden SSH Port-Forward (irgendwo läuft noch ein Tunnel). Wenn dich das weiter nervt, müssen wir kurz schauen, welcher Prozess die Ports hält — aber das ist getrennt von der Tool-Wiederbelebung.

Wenn’s jetzt läuft, markier gern die Lösung im Thread (Apps → Mark Solution), dann ist das für die nächsten “Sandbox jail” Fälle auffindbar.

nova thorn Mar 4, 2026, 8:38 PM

#

führe aus:
❤️
Klicken, um zu reagieren
😂
Klicken, um zu reagieren
👍🏿
Klicken, um zu reagieren
Reaktion hinzufügen
Antworten
Weiterleiten
Mehr
[21:38]Mittwoch, 4. März 2026 21:38
läuft!

/data/.openclaw/workspace
node
OK

verzeichnis: /data/.openclaw/workspace,
user: node,
status: OK

fathom ledgeBOT Mar 4, 2026, 8:39 PM

#

Gut — das ist der saubere “grüne” Test:

Workspace: /data/.openclaw/workspace
User: node
exec läuft wieder und Tools sind zurück

Wenn das so bleibt, war die Root-Cause wirklich agents.defaults.sandbox.mode=all (Sandbox-Jail) + die Host/Sandbox-Verwirrung.

Wenn du magst:

Lass es erstmal auf mode: "off" (stabilster Zustand).
Später, wenn du wieder Isolation willst: mode: "non-main" + je nach Bedarf workspaceAccess: "rw" (sonst arbeitest du wieder in der Sandbox-Workspace-Welt).

Und bitte im Thread die Lösung markieren (Rechtsklick auf die Lösung → Apps → Mark Solution), dann ist’s für die nächste Person auffindbar.

nova thorn Mar 4, 2026, 11:30 PM

#

aktuelle openclaw version: 2026.3.1

aber aufgepasst: die config wurde von 2026.3.2 geschrieben (laut meta-daten). das war das problem heute - version mismatch!

was das bedeutet:

• binary: 2026.3.1 (alt)
• config: 2026.3.2 (neu)
• deshalb gab es probleme mit tools

soll ich ein update auf 2026.3.2 oder latest machen?

fathom ledgeBOT Mar 4, 2026, 11:31 PM

#

Ja — ich würde updaten, und zwar so, dass Config-Version und Binary-Version wieder zusammenpassen. Dieser “Config was last written by newer OpenClaw …” Hinweis ist genau die Art Drift, die später wieder zu seltsamen Effekten führt (fehlende Subcommands, andere Defaults, Tool-Policy-/Sandbox-Verhalten).

Welche Zielversion?

Minimal-invasiv: update auf 2026.3.2 (passt exakt zu deiner Config-Meta).
Besser langfristig: update auf latest stable (damit du nicht direkt beim nächsten “Config-write” wieder driftest).

Wie updaten? (hängt davon ab, wie du OpenClaw betreibst)

A) Wenn du OpenClaw im Docker-Setup laufen hast (sieht bei dir so aus)

Backup hast du ja schon gemacht (gut).
Update-Flow ist im Kern: neues Image holen + Container neu starten.

Wenn du ein Remote-Image nutzt (z.B. GHCR), typischerweise:

docker compose pull
docker compose up -d

#

Wenn du aus Repo/Dockerfile selbst baust:

git pull
docker compose build --pull
docker compose up -d

Danach prüfen (wichtig: im Container, nicht auf deinem Laptop):

docker exec -it openclaw-n6ky-openclaw-1 openclaw --version

(Containernamen bei dir ist ja openclaw-n6ky-openclaw-1.)

B) Wenn es ein globales npm/pnpm-install ist (ohne Docker)

npm:

#

npm i -g openclaw@latest

pnpm:

pnpm add -g openclaw@latest

Dann openclaw gateway restart.

Erfolgskriterium

Nach dem Update sollte die Warnung verschwinden, wenn du openclaw config file oder ähnliches aufrufst (kein “written by newer OpenClaw…” mehr), und openclaw --version sollte zur “writer”-Version passen (oder neuer sein).

Wenn du mir sagst, ob du GHCR image pull oder local build machst (bzw. kurz docker compose ps/dein compose service-name), sag ich dir den exakt passenden Update-Befehl ohne Ratespiel.

nova thorn Mar 4, 2026, 11:34 PM

#

Habe openclaw bei hostinger im vps container

fathom ledgeBOT Mar 4, 2026, 11:35 PM

#

Alles klar — dann ist das bei dir ein Docker/VPS-Deployment. In dem Fall ist ein Update im Kern: neues Image ziehen (oder neu bauen) und Container neu starten. Da deine State/Config unter /data/.openclaw liegt und als Volume gemountet ist, bleibt das dabei normalerweise erhalten.

1) Erst rausfinden: Compose oder “docker run”?

Auf dem VPS:

docker inspect openclaw-n6ky-openclaw-1 --format '{{.Config.Image}}'
docker inspect openclaw-n6ky-openclaw-1 --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'

Wenn der zweite Befehl einen Pfad ausgibt → du nutzt docker compose (perfekt).
Wenn leer → wahrscheinlich docker run oder ein anderes Orchestrierungstool.

2A) Wenn es Docker Compose ist (empfohlen)

Dann:

#

cd "<DER_PFAD_AUS_OBEN>"
docker compose pull
docker compose up -d

Falls du lokal buildest (statt pull):

git pull
docker compose build --pull
docker compose up -d

2B) Wenn es kein Compose ist

Dann sag kurz, was docker inspect ... --format '{{.Config.Image}}' ausgibt (nur den Image-String, keine Secrets). Dann geb ich dir den risikoärmsten “pull + recreate” Ablauf, ohne dass du Volumes/env verlierst.

3) Danach verifizieren

#

docker exec -it openclaw-n6ky-openclaw-1 openclaw --version

Ziel: Binary-Version ≥ Config-Writer-Version (also mindestens 2026.3.2), dann ist der Mismatch weg.

Wenn du mir die 2 docker inspect Outputs postest, kann ich dir exakt sagen, ob du “pull latest” machen solltest oder ob du gerade auf einem lokal gebauten Image sitzt.

nova thorn Mar 4, 2026, 11:37 PM

#

Kann ich nicht einfach den uodate knopf bei hostinger drücken? 💪

fathom ledgeBOT Mar 4, 2026, 11:37 PM

#

Nicht wirklich “einfach so” – kommt drauf an, was dieser Hostinger-Button aktualisiert.

In den meisten VPS-Panels bedeutet “Update” eher:

OS-/Panel-Updates, Reboot, Kernel, Security Patches
ggf. “Rebuild/Reset” der VM

Das zieht normalerweise nicht automatisch ein neues Docker-Image für deinen laufenden OpenClaw-Container. Und ein “Rebuild” kann dir im schlimmsten Fall den Container neu erstellen (oder alles wipen), wenn Volumes nicht sauber konfiguriert sind.

Wenn du den “1-Knopf-Update” für OpenClaw willst, ist das unter Docker praktisch:

cd <compose-dir>
docker compose pull
docker compose up -d

Das macht genau das, was du meinst: neue Version holen + Container ersetzen, ohne deine gemounteten /data/.openclaw-Daten anzufassen (sofern das als Volume gemountet ist).

#

Wenn du mir sagst, wie der Button bei Hostinger genau heißt (“Update”, “Redeploy”, “Rebuild”, “Restart”) oder einen Screenshot/kurze Beschreibung schickst, kann ich dir sagen, ob der gefahrlos ist oder eher ein “alles neu”-Knopf.

nova thorn Mar 4, 2026, 11:39 PM

#

Kann mein agent das update selbst machen?

fathom ledgeBOT Mar 4, 2026, 11:39 PM

#

In deinem Setup (OpenClaw läuft in einem VPS-Container) ist die ehrliche Antwort: nein, nicht sinnvoll/zuverlässig.

Warum:

Dein Agent kann per exec nur in seiner eigenen Laufzeit arbeiten (im Container als node).
Ein Update bedeutet aber praktisch: neues Docker-Image ziehen und den Container ersetzen (docker compose pull && up -d).
Das kann ein Prozess im Container normalerweise nicht sauber für sich selbst machen (außer du mountest ihm den Docker-Socket rein → das ist ein dicker Security-Footgun und wird nicht empfohlen).
Und selbst wenn’s “geht”: wenn er sich beim Update selbst abschießt, verlierst du genau in dem Moment das Tooling/den Zugriff.

Empfehlung: Update manuell per SSH auf dem VPS-Host (oder über ein sauberes Compose-Deploy), z.B.:

cd <compose-dir>
docker compose pull
docker compose up -d

#

Wenn du unbedingt “agent-managed” willst, macht man das eher über einen separaten Management-Node/Runner (nicht den gleichen Container, der sich selbst ersetzen soll).

nova thorn Mar 5, 2026, 8:47 AM

#

schreib mir mal was für claude code, der soll das fixen, bin faul

fathom ledgeBOT Mar 5, 2026, 8:47 AM

#

You are Claude Code acting as a cautious SRE helping me fix/update an OpenClaw deployment on a Hostinger VPS running in Docker.

Context
- OpenClaw is running in a container. Container name seen before: openclaw-n6ky-openclaw-1
- Persistent state/workspace is on the host under /data/.openclaw (mounted into the container)
- openclaw --version currently shows 2026.3.1, but the config metadata says it was written by 2026.3.2 (version mismatch)
- Yesterday tools “died” because agents.defaults.sandbox.mode was set to "all". We fixed it by setting agents.defaults.sandbox.mode="off" in the config and restarting the gateway. Tools now work again.
Goal now: remove the version mismatch cleanly (upgrade to 2026.3.2 or latest stable) WITHOUT losing any persisted data.

Hard rules
- Do NOT print or paste secrets (gateway token, API keys, OAuth tokens). If you need to show config snippets, only grep specific keys and redact values.
- Before changing anything: create backups of /data/.openclaw/openclaw.json (and if present /data/.openclaw/exec-approvals.json).
- Prefer deterministic Docker update steps over “control panel buttons”.
- Explain what you’re doing and why. Ask before any destructive step (rm, prune, rebuild without volumes).

#

Tasks
1) Determine how the container was started:
   - Is it docker compose or docker run?
   - Commands:
     - docker inspect openclaw-n6ky-openclaw-1 --format '{{.Config.Image}}'
     - docker inspect openclaw-n6ky-openclaw-1 --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'
     - docker ps --no-trunc | grep -i openclaw
2) Identify what image/tag we’re running (e.g. ghcr.io/openclaw/openclaw:<tag> or local build).
3) Upgrade OpenClaw so binary >= config writer version:
   - If using compose + remote image: update tag to 2026.3.2 or latest stable, then:
       docker compose pull
       docker compose up -d
   - If using compose + local build from repo: git pull, rebuild with pull, restart:
       git pull
       docker compose build --pull

#

       docker compose up -d
   - If it’s docker run (no compose): propose the safest recreate procedure that preserves the volume mounts and env, and ask for confirmation before executing.
4) After upgrade, verify:
   - docker exec -it openclaw-n6ky-openclaw-1 openclaw --version
   - openclaw gateway status (inside container if that’s where CLI is)
   - Confirm the mismatch warning is gone when reading config.
5) Confirm sandbox config remains:
   - agents.defaults.sandbox.mode should be "off" (or propose "non-main" later, but keep it off for now).
   - Show only non-secret grep lines:
       grep -nE 'agents\\.defaults\\.sandbox|tools\\.exec\\.(host|security|ask)' /data/.openclaw/openclaw.json

When done
- Summarize exactly what changed (image tag, compose file/env changes, config change if any).
- Provide a rollback plan (pin image tag back, restore config backup, restart).

#

Wenn du willst, sag mir kurz, ob du ein docker-compose.yml hast (und wo), dann kann ich den Prompt auch auf dein konkretes Compose-Setup zuschneiden.

nova thorn Mar 5, 2026, 2:16 PM

#

hallo?

fathom ledgeBOT Mar 5, 2026, 2:16 PM

#

Was brauchst du als Nächstes — Update auf 2026.3.2/latest durchziehen, oder willst du erst die Docker/Compose-Details (Image/Tag/Compose-Dir) checken?

Wenn du mir diese zwei Outputs gibst, sag ich dir den exakten Update-Befehl für dein Setup:

docker inspect openclaw-n6ky-openclaw-1 --format '{{.Config.Image}}'
docker inspect openclaw-n6ky-openclaw-1 --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'

nova thorn Mar 5, 2026, 2:17 PM

#

2026.3.2 existiert nicht als Docker Image — Hostinger hat es noch nicht veröffentlicht. latest ist aktuell das neueste verfügbare.

fathom ledgeBOT Mar 5, 2026, 2:19 PM

#

Wenn es kein ghcr.io/openclaw/openclaw:2026.3.2 Tag gibt, dann ist das sehr wahrscheinlich einfach (noch) kein Release-Tag – und Hostinger “veröffentlicht” da auch nichts; die Tags kommen vom OpenClaw-Registry (GHCR).

Was das praktisch heißt:

Nimm latest (stable), wenn du Ruhe willst. Das ist der empfohlene Weg für VPS-Setups.
Das “Config was last written by newer …” ist (aktuell) nur ein Warnhinweis anhand von meta.lastTouchedVersion in openclaw.json – das allein macht Tools nicht kaputt. Euer echter Ausfall war agents.defaults.sandbox.mode=all.

Wenn dich die Warnung nervt:

Du kannst sie ignorieren, oder
die Config einmal mit der laufenden Version “neu speichern”, sodass meta.lastTouchedVersion wieder auf deine Version gestempelt wird (z.B. via Configure/Wizard) – aber nur, wenn du dabei nichts aus Versehen überschreibst.

Wenn du mir einmal den laufenden Image-String gibst, sag ich dir, ob du gerade wirklich auf latest bist oder auf irgendwas Hostinger-spezifischem:

docker inspect openclaw-n6ky-openclaw-1 --format '{{.Config.Image}}'

nova thorn Mar 5, 2026, 2:27 PM

#

Das erklärt alles: Hostinger pflegt ihr eigenes Fork/Wrapper-Image und 2026.3.2 kommt aus dem offiziellen ghcr.io/openclaw/openclaw Registry — die beiden sind entkoppelt. Die Warnung ist also harmlos, wir sind auf dem aktuellen Hostinger-Stand.
Zusammenfassung des heutigen Status:

✅ gog installiert & autorisiert
✅ Gateway läuft, Tools funktionieren
✅ sandbox.mode=off (Fix von gestern aktiv)
⚠️ Version-Warnung → ignorieren, löst sich wenn Hostinger ihr Image updated

fathom ledgeBOT Mar 5, 2026, 2:28 PM

#

Genau so würde ich’s auch einordnen.

Wenn alles läuft, ist die sinnvolle Haltung:

Warnung ignorieren (rein kosmetisch: meta.lastTouchedVersion), solange openclaw sandbox explain + Tooling sauber sind.
Dein eigentlicher Fix bleibt: agents.defaults.sandbox.mode="off".

Wenn du irgendwann schneller/neuer als Hostinger sein willst, hast du zwei Optionen:

Auf das offizielle Image wechseln (ghcr.io/openclaw/openclaw:latest oder :main), oder
Selbst aus dem Repo bauen (dann kontrollierst du Version/Tag komplett).

Und wenn das hier jetzt “done” ist: bitte im Thread die Lösung markieren (Apps → Mark Solution), dann finden’s die nächsten Sandbox-Opfer schneller.

nova thorn Mar 5, 2026, 2:29 PM

#

vielleicht haben wir noch mehr probleme, openclaw hat täglich neue bugs bei mir

fathom ledgeBOT Mar 5, 2026, 2:30 PM

#

Das glaub ich dir sofort – aber “täglich neue Bugs” ist leider zu unspezifisch, um sinnvoll zu debuggen. Lass uns das sauber aufdröseln, sonst wird’s nur noch mehr Chaos.

Ich brauch pro Problem genau diese Infos

Pick bitte 1 konkretes Problem (das nervigste) und poste:

Exakte Fehlermeldung (copy/paste, nicht paraphrasiert)
Was hast du gemacht, direkt davor? (welcher Chat-Befehl / welche Aktion im Control UI)
Welche Version läuft wirklich im Container:

docker exec -it openclaw-n6ky-openclaw-1 openclaw --version

Gateway Health/Status:

docker exec -it openclaw-n6ky-openclaw-1 openclaw gateway status --json

Wenn du Logs hast, am besten ein kurzer Ausschnitt um den Fehlerzeitpunkt (Secrets bitte weglassen).

#

Zwei Meta-Tipps (damit’s nicht “jeden Tag” eskaliert)

Mach pro Bug bitte einen Thread / ein Thema. Sonst ist das später weder für dich noch für andere auffindbar.
Wenn es wirklich ein reproduzierbarer Bug im Code ist: am Ende bitte GitHub Issue mit Repro-Schritten + Logs (das ist der Weg, wie es gefixt wird).

Schick mir das erste konkrete Error-Set (oben 1–4), dann gehen wir’s Schritt für Schritt durch.

nova thorn Mar 5, 2026, 2:31 PM

#

dann ist das jetzt hier solved!

#exec host=gateway