2.26 broke openclaw. should i give up? | Friends of the Crustacean 🦞🤝 | Page 1

midnight monolithBOT Mar 1, 2026, 6:27 PM

#

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

cloud ruinBOT Mar 1, 2026, 6:31 PM

#

That log is the config validator refusing to start because your openclaw.json contains an unknown key:

gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback

Two important observations:

OpenClaw itself won’t “randomly re-add” a key you deleted.
Your log literally says “Writing OpenClaw config” right before the failure — so something in your startup/update flow is regenerating /data/.openclaw/openclaw.json each launch (common if you’re re-running onboarding/installer, or you’re on a Docker/VPS template that writes config from env/UI fields).
That key is only present in newer builds. If your validator says it’s unrecognized, you almost certainly have a version mismatch (e.g. you updated one thing, but the gateway/service binary actually running is older).

Can you paste these (they’ll make it obvious what’s mismatched)?

openclaw --version
openclaw gateway status --json
and how you’re running it (Docker? Railway/Render/Fly? “curl install.sh”?)

Fastest “get it booting” fix (doesn’t rely on that flag)

#

Remove the dangerouslyAllowHostHeaderOriginFallback line from the place that’s generating your config, and instead set the supported/safer key:

{
gateway: {
bind: "lan", // or tailnet
controlUi: {
allowedOrigins: [
"http://YOUR_SERVER_IP:18789",
"http://localhost:18789",
// add https://your.domain if you use a reverse proxy
],
},
},
}

#

Docs reference (this is the exact rule that changed around the 2026.2.26 guard):
https://docs.openclaw.ai/web/control-ui.md (see the “allowedOrigins” + “non-loopback” section)

Also: why updates feel like “starting fresh”

If you’re updating by rerunning the installer/onboarding each time, use the “update in place without onboarding” path:
https://docs.openclaw.ai/install/updating.md (look for --no-onboard)

Send the version + gateway status output and I’ll tell you exactly which component is out of sync and where that config rewrite is coming from.

worn heath Mar 1, 2026, 6:37 PM

#

the openclaw-version gives
2026.2.26

the gateway status I dont see a versino number on it

cloud ruinBOT Mar 1, 2026, 6:39 PM

#

If openclaw --version says 2026.2.26, then that key should exist — the Control UI docs for this era explicitly mention gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback as the “host-header fallback” mode:
https://docs.openclaw.ai/web/control-ui.md

So the fact you’re seeing:

Unrecognized key: "dangerouslyAllowHostHeaderOriginFallback"

…almost certainly means: the thing starting your Gateway is NOT actually running 2026.2.26, even though the openclaw you typed is. (Classic “CLI updated, but service/container is still pointing at an older install”.)

Next thing to paste (this will reveal the mismatch)

Run:

openclaw gateway status --json --deep

In that JSON there’s usually enough info to see what command/path the service is actually executing (and whether “Config (cli)” vs “Config (service)” disagree).

#

Also paste:

which openclaw

Likely fix (if you’re using a supervised service)

After updating OpenClaw, reinstall the gateway service so it points at the new binary:

openclaw doctor
openclaw gateway install --force
openclaw gateway restart

(That does not wipe your ~/.openclaw state; it just rewrites the service entrypoint.)

#

About “it comes back after I delete it”

Your log literally says “Writing OpenClaw config” every launch. That means something in your start/update flow is regenerating /data/.openclaw/openclaw.json (installer/onboard step, platform wrapper, etc.), so manual edits get overwritten. Once we see the gateway status --json --deep output, we can point at the exact component doing that.

Paste those two outputs and I’ll tell you which install/service is out of sync and the cleanest way to stop the config rewrite loop.

worn heath Mar 1, 2026, 6:39 PM

#

root@srv1330367:~# openclaw gateway status --json
{
"service": {
"label": "systemd",
"loaded": true,
"loadedText": "enabled",
"notLoadedText": "disabled",
"command": {
"programArguments": [
"/usr/bin/node",
"/usr/lib/node_modules/openclaw/dist/index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "/root/.config/systemd/user/openclaw-gateway.service"
},
"runtime": {
"status": "running",
"state": "active",
"subState": "running",
"pid": 942152,
"lastExitStatus": 0,
"lastExitReason": "0"
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "/root/.openclaw/openclaw.json",
"exists": true,
"valid": true
},
"daemon": {
"path": "/root/.openclaw/openclaw.json",
"exists": true,
"valid": true
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "busy",
"listeners": [
{
"pid": 942152,
"command": "openclaw-gatewa",
"address": "127.0.0.1:18789",
"commandLine": "openclaw-gateway",
"user": "root",
"ppid": 834
}
],
"hints": [
"Gateway already running locally. Stop it (openclaw gateway stop) or use a different port."
]
},
"rpc": {
"ok": true,
"url": "ws://127.0.0.1:18789"
},
"extraServices": []

cloud ruinBOT Mar 1, 2026, 6:41 PM

#

Your gateway status --json output is the smoking gun:

Your systemd service is running OpenClaw from:
/usr/lib/node_modules/openclaw/dist/index.js
But your openclaw --version reporting 2026.2.26 can still be coming from a different install prefix (very commonly /usr/local/...).

That perfectly explains this behavior:

the config contains gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback
the gateway process that’s actually starting is an older OpenClaw build (from /usr/lib/...) that doesn’t know that key, so it fails validation.

Fix: regenerate the gateway service to point at the same OpenClaw you’re running in the CLI

On the VPS, run:

which openclaw
openclaw --version

#


openclaw gateway stop
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --json

After that, the service should no longer reference /usr/lib/node_modules/... unless that’s truly where your updated OpenClaw lives.

Bonus: why it “comes back” when you delete it

Also note your original error referenced /data/.openclaw/openclaw.json, but gateway status shows the service config at /root/.openclaw/openclaw.json.

That means you likely have two different OpenClaw “homes” in play (different $HOME / OPENCLAW_HOME / container vs host). Once the service is fixed, make sure you’re editing the same config file the service uses.

Separate thing: remote access

Right now your gateway is bindMode: "loopback" (127.0.0.1), so it’s not reachable remotely unless you proxy/SSH-forward/Tailscale it.

#

Docs: https://docs.openclaw.ai/web/control-ui.md (allowedOrigins + remote setups)

If the service-path fix gets you unstuck, tell me what which openclaw prints + what the openclaw gateway install --force changed the service command to, and we’ll make the update process stop feeling like “start from scratch” every time.

worn heath Mar 1, 2026, 6:42 PM

#

ok i ran those two commands, now what

cloud ruinBOT Mar 1, 2026, 6:43 PM

#

Paste the output of these after you ran the stop/install/restart:

which openclaw
openclaw --version
openclaw gateway status --json

What I’m looking for in gateway status --json is whether the systemd service still points at:

/usr/lib/node_modules/openclaw/dist/index.js

If it does, you still have a split install (CLI you run vs gateway service binary). If it changed to something like /usr/local/lib/node_modules/... (or similar), then the mismatch should be fixed.

Also: did the gateway logs stop complaining about

Unrecognized key: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback

#

Yes/no is enough, but if it still complains, paste the first ~20 lines of the gateway log after restart.

worn heath Mar 1, 2026, 6:43 PM

#

{
"service": {
"label": "systemd",
"loaded": true,
"loadedText": "enabled",
"notLoadedText": "disabled",
"command": {
"programArguments": [
"/usr/bin/node",
"/usr/lib/node_modules/openclaw/dist/index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "/root/.config/systemd/user/openclaw-gateway.service"
},
"runtime": {
"status": "running",
"state": "active",
"subState": "running",
"pid": 943720,
"lastExitStatus": 0,
"lastExitReason": "0"
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "/root/.openclaw/openclaw.json",
"exists": true,
"valid": true
},
"daemon": {
"path": "/root/.openclaw/openclaw.json",
"exists": true,
"valid": true
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "busy",
"listeners": [
{
"pid": 943720,
"command": "openclaw-gatewa",
"address": "127.0.0.1:18789",
"commandLine": "openclaw-gateway",
"user": "root",
"ppid": 834
}
],
"hints": [
"Gateway already running locally. Stop it (openclaw gateway stop) or use a different port."
]
},
"rpc": {
"ok": true,
"url": "ws://127.0.0.1:18789"
},
"extraServices": []
}

cloud ruinBOT Mar 1, 2026, 6:45 PM

#

Cool — that gateway status --json output means your systemd Gateway is up and answering RPC (rpc.ok: true). So at least one OpenClaw on that box is healthy right now.

Two things to notice in what you pasted:

The systemd service is still launching OpenClaw from:
/usr/lib/node_modules/openclaw/dist/index.js
Your original crash log mentions a different config path:
/data/.openclaw/openclaw.json
…but the running systemd service is using:
/root/.openclaw/openclaw.json

So you almost certainly have two different OpenClaw environments (or two different “homes”): one using /data, one using /root.

Next: confirm what version the running service install actually is

Please run and paste:

#

which openclaw
openclaw --version

node -p "require('/usr/lib/node_modules/openclaw/package.json').version"

If that last line prints something older than 2026.2.26, then we’ve confirmed the root cause: service is running an older install even though your CLI reports newer.

Also: are you using Docker / a panel / any “one-click” host?

Because /data/.openclaw/... strongly suggests a container / PaaS volume mount. If you are running OpenClaw in Docker as well, that’s likely where the /data error is coming from (not from the systemd service).

Separate (but important): why you “can’t access it” from your laptop

Your gateway is bindMode: "loopback" (127.0.0.1), so it’s not reachable remotely unless you:

SSH port-forward, or
reverse proxy (nginx), or
use Tailscale Serve (recommended)

#

If you tell me which of those you’re trying to do, I’ll give the exact config.

Paste those 3 command outputs first — then we can pick the correct “single source of truth” install and stop the “every update = start fresh” pain.

worn heath Mar 1, 2026, 6:46 PM

#

/usr/bin/openclaw
2026.2.26
2026.2.26

cloud ruinBOT Mar 1, 2026, 6:48 PM

#

Nice — that confirms something important:

/usr/bin/openclaw is 2026.2.26
/usr/lib/node_modules/openclaw is also 2026.2.26
and openclaw gateway status shows the gateway is running and RPC is OK (rpc.ok: true)

So the “unknown key” error you pasted earlier (the one that mentions /data/.openclaw/openclaw.json and “proxy server listening on port 28318”) is not coming from this running systemd gateway (which is using /root/.openclaw/openclaw.json).

Next step: find what is producing the `/data/...` + port `28318` logs

Run this and paste the output:

ss -ltnp | egrep '(:18789|:28318)'

That will tell us which process is bound to 28318 (and whether it’s docker-proxy / a second openclaw process / some hosting wrapper).

#

Also, please answer one quick thing: are you running OpenClaw in Docker / a hosting panel as well, or only via the systemd service shown in gateway status?

If your goal right now is “I want to access the Control UI from my laptop”

Your gateway is currently loopback-only:

"bindMode": "loopback",
"bindHost": "127.0.0.1"

Fast/safe way (no config changes): SSH tunnel:

ssh -L 18789:127.0.0.1:18789 root@srv1330367

Then open on your laptop: http://127.0.0.1:18789/

#

Once we identify what’s on 28318, we can stop the duplicate instance / config rewrite loop that’s making updates feel like “start fresh”.

worn heath Mar 1, 2026, 6:49 PM

#

LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=943720,fd=23))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=943720,fd=24))

cloud ruinBOT Mar 1, 2026, 6:50 PM

#

That output means: only your systemd gateway is listening (loopback-only) on 127.0.0.1:18789. There is nothing currently listening on 28318 on this server.

So the big log you pasted earlier (OpenClaw proxy server listening on port 28318 + config at /data/.openclaw/openclaw.json) is coming from a different OpenClaw instance / different environment than the one you’re showing with openclaw gateway status (which is using /root/.openclaw/openclaw.json).

What to do next (pick one)

A) If your goal is “open the Control UI from your laptop” (fastest)

Keep the gateway loopback-only and use an SSH tunnel:

ssh -L 18789:127.0.0.1:18789 root@srv1330367

Then open on your laptop:
http://127.0.0.1:18789/

B) If your goal is “figure out where the /data + 28318 logs are coming from”

#

On the server, run and paste:

ps aux | grep -i openclaw | grep -v grep
docker ps 2>/dev/null || true

Also: where exactly are you “seeing the logs” that mention /data/.openclaw/openclaw.json? (A hosting panel? a Docker container log? something like Railway/Render/Coolify/etc.?) That’ll tell us which second instance is rewriting config and breaking.

C) If your goal is “make it accessible without SSH”

Then you need a proper remote setup (Tailscale Serve or nginx) and gateway.controlUi.allowedOrigins. But first let’s confirm whether you’re actually running a second instance in a container/panel, because that’s what the /data path strongly suggests.

worn heath Mar 1, 2026, 6:51 PM

#

root 943720 2.1 2.5 10393824 410556 ? Ssl 18:42 0:11 openclaw-gateway
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2b957d066006 ghcr.io/hostinger/hvps-openclaw:latest "/entrypoint.sh node…" 25 minutes ago Up 25 minutes 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp, 0.0.0.0:47974->47974/tcp, [::]:47974->47974/tcp openclaw-fjhv-openclaw-1
root@srv1330367:~#

cloud ruinBOT Mar 1, 2026, 6:52 PM

#

You’ve got two OpenClaw installs running at the same time:

Systemd service (native install)
openclaw-gateway PID 943720 listening on 127.0.0.1:18789 (this one looks healthy)
Docker container (Hostinger image)
ghcr.io/hostinger/hvps-openclaw:latest container openclaw-fjhv-openclaw-1 (this is the one producing the logs with /data/.openclaw/openclaw.json and port 28318)

So the confusing behavior makes sense:

openclaw gateway status is reporting the systemd gateway (/root/.openclaw/...)
the crash log you keep pasting is from the Docker gateway (/data/.openclaw/...)
deleting the key “but it comes back” happens because the container entrypoint is rewriting /data/.openclaw/openclaw.json on startup.

Step 1: confirm the OpenClaw version inside the container

Run:

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw --version
docker exec -it openclaw-fjhv-openclaw-1 node -p "require('/usr/lib/node_modules/openclaw/package.json').version" 2>/dev/null || true

If the container reports an older version, that explains why it says the key is “unrecognized”.

Step 2: pick ONE deployment path (recommended)

You should run either Docker OR systemd, not both.

Option A (keep Docker / Hostinger):

Fix/update the Hostinger container (or switch to the official docker-compose flow).
Also verify persistence so updates don’t feel like “start fresh”:

docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Mounts}}' | jq

#

Look for a mount that persists /data (or at least /data/.openclaw). If /data isn’t persisted, you’ll lose config/credentials on recreate.

Option B (ditch Docker, keep systemd):

Stop/remove the container and then configure systemd OpenClaw for remote access (Tailscale Serve / nginx / SSH tunnel).
I’ll give exact commands, but tell me first if you want to keep Docker or not.

Quick question

How are you trying to access the UI right now — via Hostinger’s exposed port 8080 (Docker), or via the native gateway on 18789 (systemd/SSH tunnel)?

worn heath Mar 1, 2026, 6:52 PM

#

i want to use the container in hostinger docker. usually it was 47974

cloud ruinBOT Mar 1, 2026, 6:53 PM

#

That makes sense — if you want to use the Hostinger Docker container (port 47974), then the logs you pasted are 100% from the container, not from the systemd gateway on 127.0.0.1:18789.

Right now the container is crash-looping because the OpenClaw inside the container doesn’t recognize:

gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback

…and Hostinger’s entrypoint keeps re-writing /data/.openclaw/openclaw.json, so manual edits don’t stick.

1) Check what version OpenClaw the container is actually running

Run:

docker exec -it openclaw-fjhv-openclaw-1 openclaw --version

If that prints something older than 2026.2.26, that’s the root cause.

#

2) Quick fix (update OpenClaw inside the container), then restart it

Try:

docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'npm i -g openclaw@2026.2.26 && openclaw --version'
docker restart openclaw-fjhv-openclaw-1
docker logs -n 80 openclaw-fjhv-openclaw-1

(If npm isn’t available inside that image, tell me what error you get — we’ll use the image update route instead.)

3) Better fix (make it survive updates): pull a newer Hostinger image + recreate

Since your container is ghcr.io/hostinger/hvps-openclaw:latest, Hostinger may have shipped a mismatched “latest” briefly.

First, figure out where the compose project lives:

#

docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Config.Labels}}' | jq

Look for com.docker.compose.project.working_dir, ...project, etc. Then in that directory:

docker compose pull
docker compose up -d --force-recreate
docker logs -n 80 openclaw-fjhv-openclaw-1

4) Confirm your state is persisted (this is why updates feel like “start fresh”)

Check mounts:

#

docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Mounts}}' | jq

You want /data (or at least /data/.openclaw) to be a volume/bind mount. If it’s not persisted, every container recreate = new config/credentials.

If you paste:

docker exec ... openclaw --version
docker logs -n 120 openclaw-fjhv-openclaw-1

…I can tell you exactly whether you should update-in-container vs pull a fixed image, and which port (47974 vs 8080) is the actual Control UI endpoint once it boots.

worn heath Mar 1, 2026, 6:53 PM

#

docker exec -it openclaw-fjhv-openclaw-1 node -p "require('/usr/lib/node_modules/openclaw/package.json').version" 2>/dev/null || true
Invalid config at /data/.openclaw/openclaw.json:\n- gateway.controlUi: Unrecognized key: "dangerouslyAllowHostHeaderOriginFallback"
2026.2.12
node:internal/modules/cjs/loader:1386
throw err;
^

Error: Cannot find module '/usr/lib/node_modules/openclaw/package.json'
Require stack:

/data/[eval]
at Function._resolveFilename (node:internal/modules/cjs/loader:1383:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1025:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1030:22)
at Function._load (node:internal/modules/cjs/loader:1192:37)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
at Module.require (node:internal/modules/cjs/loader:1463:12)
at require (node:internal/modules/helpers:147:16)
at [eval]:1:1
at runScriptInThisContext (node:internal/vm:209:10) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/data/[eval]' ]
}

Node.js v22.22.0
root@srv1330367:~#

cloud ruinBOT Mar 1, 2026, 6:54 PM

#

There we go — you found the root cause:

The Hostinger container is running OpenClaw 2026.2.12
Your /data/.openclaw/openclaw.json contains a key that only exists in newer builds:
gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback
So the container’s OpenClaw (2.12) rejects it as “unrecognized” and won’t boot.

Fix (keep using Hostinger Docker + port 47974)

Option 1 (fastest): upgrade OpenClaw inside the container to 2026.2.26

Run:

docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'npm i -g openclaw@2026.2.26 && openclaw --version'
docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

#

After that, the config key should be recognized and the gateway should start again.

Option 2 (better long-term): update the Hostinger image (if they’ve published a newer one)

From whatever folder Hostinger created the compose setup in:

docker compose pull
docker compose up -d --force-recreate
docker logs -n 120 openclaw-fjhv-openclaw-1

Why it “comes back” when you delete it

Because Hostinger’s entrypoint is auto-writing /data/.openclaw/openclaw.json on startup (“Writing OpenClaw config”), so manual edits won’t stick unless you change the inputs Hostinger uses.

One more quick check (to stop the “start fresh every update” problem)

Make sure /data is actually persisted:

#

docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Mounts}}'

If /data isn’t a volume/bind mount, container recreates = config/credentials reset.

If you paste the output of the npm i -g ... command (or the error it gives), I’ll tell you whether you should go with “upgrade-in-container” or “pull a newer Hostinger image” for your setup.

worn heath Mar 1, 2026, 7:00 PM

#

doesnt look like it worked

cloud ruinBOT Mar 1, 2026, 7:01 PM

#

Yep — that likely means the container is still on 2026.2.12, so it still can’t parse that config key.

The crucial detail from your last paste is: inside the container it’s 2026.2.12. So we need to actually upgrade OpenClaw inside the container (or update the container image), then restart.

1) First confirm the container version (after your attempt)

Run:

docker exec -it openclaw-fjhv-openclaw-1 openclaw --version

If it still prints 2026.2.12, the upgrade didn’t take.

2) Re-run the upgrade explicitly as root (most common issue is permissions)

docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '

#

npm -v && node -v &&
npm i -g openclaw@2026.2.26 --unsafe-perm &&
openclaw --version
'

Then:

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

3) If that still doesn’t work

Paste the exact output of the npm i -g ... command (the whole thing). That will tell us which branch we’re in:

npm: not found → the image is missing npm tooling

#

“read-only file system” / permission errors → Hostinger image locks global installs (then we must update the image via compose/panel)
network/DNS errors → container can’t reach npm registry

Once the container reports openclaw --version = 2026.2.26, that config key will stop being “unrecognized” and the boot should succeed on port 47974 again.

worn heath Mar 1, 2026, 7:01 PM

#

now it says 2.26

cloud ruinBOT Mar 1, 2026, 7:01 PM

#

Perfect — if inside the container openclaw --version now says 2026.2.26, then you’ve fixed the version mismatch that caused the “unrecognized key” crash.

Next: verify the container actually boots cleanly

Run:

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

You should no longer see the “Unrecognized key” error. You should see it start the gateway and listen on whatever ports Hostinger maps.

Also: make sure port 47974 is actually listening again

ss -ltnp | egrep '(:47974|:8080)'
docker port openclaw-fjhv-openclaw-1

#

Hostinger sometimes changes which external port maps to the gateway/control UI, so docker port will tell you the truth.

Finally: stop the “updates make me start fresh” problem

Check that /data is persisted:

docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Mounts}}'

If /data (or at least /data/.openclaw) isn’t a volume/bind mount, every container recreate wipes config/credentials and it will feel like starting over.

Paste the docker logs output if it still won’t come up, and paste docker port ... if you’re not sure which port to open in the browser.

worn heath Mar 1, 2026, 7:03 PM

#

Invalid config at /data/.openclaw/openclaw.json:\n- channels.whatsapp.allowFrom: channels.whatsapp.dmPolicy="allowlist" requires channels.whatsapp.allowFrom to contain at least one sender ID
│
◇ Config ───────────────────────────────────────────────────╮
│ │
│ Config invalid; doctor will run with best-effort config. │
│ │
├────────────────────────────────────────────────────────────╯
│
◇ Doctor changes ──────────────────────────────╮
│ │
│ Telegram configured, enabled automatically. │
│ WhatsApp configured, enabled automatically. │
│ │
├───────────────────────────────────────────────╯
│
◇ Doctor warnings ──────────────────────────────────────────────────────╮
│ │
│ - channels.whatsapp.dmPolicy is "allowlist" but allowFrom is empty — │
│ all DMs will be blocked. Add sender IDs to │
│ channels.whatsapp.allowFrom, or run "openclaw doctor --fix" to │
│ auto-migrate from pairing store when entries exist. │
│ │
├────────────────────────────────────────────────────────────────────────╯
│
◇ Doctor ──────────────────────────────────────────────╮
│ │
│ Run "openclaw doctor --fix" to apply these changes. │
│ Run "openclaw doctor --fix" to apply these changes. │
│ │
├───────────────────────────────────────────────────────╯
Config invalid
File: ~/.openclaw/openclaw.json
Problem:

channels.whatsapp.allowFrom: channels.whatsapp.dmPolicy="allowlist" requires channels.whatsapp.allowFrom to contain at least one sender ID

cloud ruinBOT Mar 1, 2026, 7:03 PM

#

Good news: the HostHeaderOriginFallback problem is gone. Now you’re hitting a different config validator error:

channels.whatsapp.dmPolicy="allowlist" requires channels.whatsapp.allowFrom to contain at least one sender ID

Meaning: your config says “only allow WhatsApp DMs from allowlist”, but the allowlist is empty — so the gateway refuses to start.

Fastest fix (recommended)

Run this inside the container:

docker exec -it openclaw-fjhv-openclaw-1 openclaw doctor --fix

That’s exactly what the message is telling you to do. It will try to migrate any previously paired WhatsApp senders into channels.whatsapp.allowFrom (if you have pairing-store entries).

Then restart:

#

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

If you don’t want allowlist mode for WhatsApp DMs

Set WhatsApp back to pairing mode (most common default) by editing config (or via CLI):

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.whatsapp.dmPolicy "\"pairing\""

Then restart the container.

If you do want allowlist mode

Add at least one sender to channels.whatsapp.allowFrom (your phone number as WhatsApp sees it, usually +<countrycode><number>):

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.whatsapp.allowFrom '["+15551234567"]' --strict-json

Then restart.

One important detail

Your error ends with:

File: ~/.openclaw/openclaw.json

Inside the container that likely resolves to /data/.openclaw/openclaw.json (which matches what we’ve been seeing). So you’re editing the right place.

Run openclaw doctor --fix first; if it still fails, paste your channels.whatsapp block from /data/.openclaw/openclaw.json (redact tokens).

worn heath Mar 1, 2026, 7:04 PM

#

i dont even use the whatsapp, i just want it to work as i use telegram

cloud ruinBOT Mar 1, 2026, 7:05 PM

#

Yep — then just get WhatsApp out of the way so the config validates and the gateway can start for Telegram.

Run these inside the container:

# Option A (cleanest): remove WhatsApp config entirely
docker exec -it openclaw-fjhv-openclaw-1 openclaw config unset channels.whatsapp

# then restart
docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

If you’d rather keep the block but fully disable DMs, do this instead:

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.whatsapp.dmPolicy "\"disabled\""
docker restart openclaw-fjhv-openclaw-1

If WhatsApp keeps “coming back” after you unset it, that’s Hostinger’s entrypoint auto-generating config because it detects WhatsApp state/credentials. In that case paste:

docker exec -it openclaw-fjhv-openclaw-1 cat /data/.openclaw/openclaw.json

(redact tokens) and I’ll tell you the exact minimal change so it stops re-enabling WhatsApp and you can run Telegram-only.

worn heath Mar 1, 2026, 7:06 PM

#

ok so now how do i see if it will work after doing this

cloud ruinBOT Mar 1, 2026, 7:06 PM

#

After you unset/disable WhatsApp, you verify it in 3 quick checks (all container-side):

1) Make sure the config now validates

docker exec -it openclaw-fjhv-openclaw-1 openclaw doctor

You want no “Config invalid” at the end.

2) Restart the container and read the startup logs

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

You’re looking for it to get past “Starting OpenClaw gateway…” without errors.

3) Confirm it’s listening on the expected port (47974 / 8080)

#

docker port openclaw-fjhv-openclaw-1

Whatever that prints is the port you should open in the browser.

If you paste the output of (2) and (3), I can tell you exactly which URL to hit and whether Telegram actually started.

worn heath Mar 1, 2026, 7:07 PM

#

Error: Config validation failed: channels.whatsapp.allowFrom: channels.whatsapp.dmPolicy="allowlist" requires channels.whatsapp.allowFrom to contain at least one sender ID

cloud ruinBOT Mar 1, 2026, 7:08 PM

#

That error means the container still has a WhatsApp block with dmPolicy: "allowlist" and an empty allowFrom, so config validation fails before the gateway can start (even if you don’t use WhatsApp).

Since you only care about Telegram, just hard-disable WhatsApp in the container config, then restart the container.

Disable WhatsApp in `/data/.openclaw/openclaw.json` (inside the container)

Run on the VPS:

docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '
export NODE_PATH="$(npm root -g)";
node -e "
const fs=require(\"fs\");
const JSON5=require(\"json5\");
const p=\"/data/.openclaw/openclaw.json\";
const o=JSON5.parse(fs.readFileSync(p,\"utf8\"));
o.channels ??= {};

#

o.channels.whatsapp = { enabled: false, dmPolicy: \"disabled\" };
fs.writeFileSync(p, JSON.stringify(o,null,2));
console.log(\"Wrote\", p);
"
'

Restart + verify it boots

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1
docker port openclaw-fjhv-openclaw-1

You’ll know it “works” when:

docker logs no longer shows Config invalid

#

and docker port … shows what external port to open (likely your usual 47974, but trust what it prints)

If it still complains about WhatsApp after this, paste the docker logs -n 120 ... output — that would mean Hostinger’s entrypoint is regenerating the WhatsApp config on every boot, and we’ll have to change the Hostinger-side inputs instead of editing the file.

worn heath Mar 1, 2026, 7:10 PM

#

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

channels.whatsapp.allowFrom: channels.whatsapp.dmPolicy="allowlist" requires channels.whatsapp.allowFrom to contain at least one sender ID

Run: openclaw doctor --fix
[19:05:28] WARN: OpenClaw exited with code 1

Session terminated, killing shell... ...killed.
Fixing data permissions
8080/tcp -> 0.0.0.0:8080
8080/tcp -> [::]:8080
47974/tcp -> 0.0.0.0:47974
47974/tcp -> [::]:47974

cloud ruinBOT Mar 1, 2026, 7:10 PM

#

That output means the container still refuses to start because your config says WhatsApp DMs are in allowlist mode but allowFrom is empty.

Even if you “don’t use WhatsApp”, that config still has to be valid for the gateway to boot.

Fix it by disabling WhatsApp (container-only)

Run these on the VPS:

# 1) Force WhatsApp DM policy to "disabled" (no allowFrom required)
docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.whatsapp.dmPolicy "\"disabled\""

# (optional but nice) also disable the whole WhatsApp channel
docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.whatsapp.enabled false --strict-json

# 2) Restart and check logs

#

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

If it boots, you should stop seeing Config invalid … channels.whatsapp.allowFrom.

If the error keeps coming back

Then Hostinger’s /entrypoint.sh is regenerating the WhatsApp block on every start (“Writing OpenClaw config”). To prove that, paste just the WhatsApp section:

docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'sed -n "/channels\"/,/}/p" /data/.openclaw/openclaw.json | sed -n "/whatsapp/,+30p"'

…and also:

#

docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'printenv | grep -i whatsapp || true'

Then we can tell you what Hostinger setting/env var is causing WhatsApp to be re-added.

(Your docker port output looks fine: it’s exposing 8080 and 47974 — once the config is valid, the UI should be reachable again on your usual external port.)

If this fixes it, please mark the solution in the thread (right-click message → Apps → ✅ Mark Solution) so it’s indexed.

worn heath Mar 1, 2026, 7:12 PM

#

root@srv1330367:~# docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'sed -n "/channels"/,/}/p" /data/.openclaw/openclaw.json | sed -n "/whatsapp/,+30p"'
"whatsapp": {
"dmPolicy": "allowlist",
"selfChatMode": true,
"allowFrom": [],
"groupAllowFrom": [],
"groupPolicy": "allowlist",
"debounceMs": 0,
"mediaMaxMb": 50
},
root@srv1330367:~# docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'printenv | grep -i whatsapp || true'

cloud ruinBOT Mar 1, 2026, 7:13 PM

#

Great — that proves WhatsApp is being enabled purely because it’s in /data/.openclaw/openclaw.json (no env var is forcing it), and right now it’s invalid:

"dmPolicy": "allowlist",
"allowFrom": []

In 2026.2.26 that combination is a hard validation error, so the container won’t boot.

Fastest fix (Telegram-only): disable WhatsApp in the config file

Run this on the VPS (it edits /data/.openclaw/openclaw.json inside the container):

docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '
node - <<'"'"'NODE'"'"'
const fs = require("fs");

#

const p = "/data/.openclaw/openclaw.json";
const o = JSON.parse(fs.readFileSync(p, "utf8"));

o.channels ??= {};
// disable WhatsApp completely (so it can’t block startup)
o.channels.whatsapp = { enabled: false, dmPolicy: "disabled" };

fs.writeFileSync(p, JSON.stringify(o, null, 2));
console.log("Patched", p);
NODE
'

Then restart + check logs:

#

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

You should no longer see the channels.whatsapp.allowFrom ... requires ... error.

How to “see if it works”

Once logs look clean, confirm the ports and open the UI:

docker port openclaw-fjhv-openclaw-1

You’ll get mappings like 47974/tcp -> 0.0.0.0:47974. That’s the port you hit in the browser.

Alternative (if you want to keep WhatsApp but stop the error)

#

Set dmPolicy to pairing (or add yourself to allowFrom). But since you don’t use it, disabling is simplest.

If after the patch it still reverts to dmPolicy: allowlist, paste the first ~60 lines of docker logs -n 120 ... after restart — that would mean Hostinger’s entrypoint is rewriting the file again on boot and we’ll need to change the Hostinger-side generator behavior.

worn heath Mar 1, 2026, 7:16 PM

#

paste what i need to send all in one box i can copy so i can get the line breaks right

cloud ruinBOT Mar 1, 2026, 7:16 PM

#

Copy/paste this whole block as-is:

# Disable WhatsApp so it can't block startup (Telegram-only)
docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '
node - <<'"'"'NODE'"'"'
const fs = require("fs");
const p = "/data/.openclaw/openclaw.json";
const o = JSON.parse(fs.readFileSync(p, "utf8"));

o.channels ??= {};
o.channels.whatsapp = { enabled: false, dmPolicy: "disabled" };

fs.writeFileSync(p, JSON.stringify(o, null, 2));
console.log("Patched", p);
NODE

#

'

# Restart and show logs + port mapping
docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1
docker port openclaw-fjhv-openclaw-1

If you still see “Config invalid … channels.whatsapp.allowFrom” after this, paste the docker logs output from this run.

worn heath Mar 1, 2026, 7:18 PM

#

2026-03-01T19:16:48.966Z [gateway] security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true, gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true, gateway.controlUi.dangerouslyDisableDeviceAuth=true. Run openclaw security audit.
2026-03-01T19:16:48.996Z [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-03-01T19:16:49.302Z [diagnostic] lane task error: lane=cron durationMs=27 error="Error: No API key found for provider "anthropic". Auth store: /data/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /data/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
2026-03-01T19:16:49.303Z [diagnostic] lane task error: lane=session:agent:main:cron:93f8e045-fee9-430e-95b7-21f54ae7717e durationMs=30 error="Error: No API key found for provider "anthropic". Auth store: /data/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /data/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
2026-03-01T19:16:49.406Z [diagnostic] lane task error: lane=cron durationMs=21 error="Error: No API key found for provider "anthropic". Auth store: /data/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /data/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
2026-03-01T19:16:49.407Z [diagnostic] lane task error: lane=session:agent:main:cron:b8286ba8-8500-4313-afe8-141b2e6590ed durationMs=23 error="Error: No API key found for provider "anthropic". Auth store: /data/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /data/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."

#

how can i go back and get my keys added in that were saved before?

cloud ruinBOT Mar 1, 2026, 7:19 PM

#

Good — that log means the container Gateway is actually starting now. What’s left is just model auth:

No API key found for provider "anthropic"

Until you add some model credentials, Telegram can connect but the bot can’t answer (and cron will keep erroring).

1) (Optional) stop the cron spam for now

Copy/paste:

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set cron.enabled false --strict-json
docker restart openclaw-fjhv-openclaw-1
docker logs -n 50 openclaw-fjhv-openclaw-1

2) Add your model credentials (this is the real fix)

Run the interactive auth helper inside the container and pick the provider you actually have credentials for (Anthropic in your case, based on the log):

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw models auth add
docker exec -it openclaw-fjhv-openclaw-1 openclaw models status

Anthropic setup options (docs): https://docs.openclaw.ai/providers/anthropic

After models status looks sane, Telegram replies should start working.

If you paste the output of openclaw models status (redact keys/tokens), I can tell you if it’s fully wired up or still missing something.

#

Your “keys” (model auth) are stored on disk in the agent auth store, typically:

inside the container: /data/.openclaw/agents/main/agent/auth-profiles.json
on the host (your systemd install): /root/.openclaw/agents/main/agent/auth-profiles.json

So if your old working setup was the systemd one (or an older container), you can usually just copy that file into the container.

Copy/paste this whole block (it will: check if the host has the file → copy it into the container → restart → show status):

# 1) Check if the host (systemd install) still has your old auth store
ls -ლა /root/.openclaw/agents/main/agent/auth-profiles.json || true

# 2) Check what's currently inside the container
docker exec -it openclaw-fjhv-openclaw-1 sh -lc 'ls -la /data/.openclaw/agents/main/agent/ || true'

#

# 3) If the host file exists, copy it into the container
docker cp /root/.openclaw/agents/main/agent/auth-profiles.json \
  openclaw-fjhv-openclaw-1:/data/.openclaw/agents/main/agent/auth-profiles.json

# 4) Fix ownership (container usually runs as uid 1000 = node)
docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc 'chown 1000:1000 /data/.openclaw/agents/main/agent/auth-profiles.json || true'

# 5) Restart + verify auth is now detected
docker restart openclaw-fjhv-openclaw-1
docker exec -it openclaw-fjhv-openclaw-1 openclaw models status
docker logs -n 80 openclaw-fjhv-openclaw-1

If /root/.openclaw/agents/main/agent/auth-profiles.json doesn’t exist, then the keys are genuinely gone (or they lived in some other state dir/backup), and the only path is to re-add them with:

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw models auth add

(And don’t paste tokens/keys into Discord.)

worn heath Mar 1, 2026, 7:21 PM

#

ok now how can i get the containers bck up and running

cloud ruinBOT Mar 1, 2026, 7:21 PM

#

To get the Hostinger Docker container back up, do this sequence (it will start it, show you why it’s failing if it still fails, and confirm it’s actually running):

# 1) See current state (running / exited / restarting)
docker ps -a | grep -i openclaw

# 2) Restart the container
docker restart openclaw-fjhv-openclaw-1

# 3) Watch startup logs (this will tell us the exact blocker)
docker logs -f --tail 200 openclaw-fjhv-openclaw-1

If the logs show Config invalid, run doctor inside the container to see the exact config error:

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw --version
docker exec -it openclaw-fjhv-openclaw-1 openclaw doctor

And once it is running, confirm which port to open (47974 vs 8080):

docker port openclaw-fjhv-openclaw-1

Paste the first ~50 lines of the log output after the restart (step 3) if it doesn’t come up — that output is the fastest way to tell what’s still blocking startup.

worn heath Mar 1, 2026, 7:23 PM

#

so when i deploy in hostinger it fails and these are the logs

[build]:
2026-03-01T19:22:58.942604 Pulling project images
[build]:
2026-03-01T19:22:58.943155 ------------------------------
[build]:
2026-03-01T19:22:59.063201 Image ghcr.io/hostinger/hvps-openclaw:latest Pulling
[build]:
2026-03-01T19:22:59.478893 Image ghcr.io/hostinger/hvps-openclaw:latest Pulled
[build]:
2026-03-01T19:22:59.524039 ------------------------------
[build]:
2026-03-01T19:22:59.524185 Deploying project
[build]:
2026-03-01T19:22:59.524765 ------------------------------
[build]:
2026-03-01T19:22:59.627916 Container openclaw-fjhv-openclaw-1 Creating
[build]:
2026-03-01T19:22:59.656241 Container openclaw-fjhv-openclaw-1 Error response from daemon: Conflict. The container name "/openclaw-fjhv-openclaw-1" is already in use by container "2b957d0660064a466456398f370b24df605f7dcec08044840b2cba63a619a575". You have to remove (or rename) that container to be able to reuse that name.
[build]:
2026-03-01T19:22:59.656322 Error response from daemon: Conflict. The container name "/openclaw-fjhv-openclaw-1" is already in use by container "2b957d0660064a466456398f370b24df605f7dcec08044840b2cba63a619a575". You have to remove (or rename) that container to be able to reuse that name.
[build]:
2026-03-01T19:22:59.662291 ------------------------------
[build]:
2026-03-01T19:22:59.662347 Project deployment failed

cloud ruinBOT Mar 1, 2026, 7:24 PM

#

That Hostinger deploy error is not OpenClaw failing — it’s Docker refusing to create a new container because the old one still exists with the same name:

Conflict. The container name "/openclaw-fjhv-openclaw-1" is already in use …

Fix: stop + remove the existing container (don’t delete volumes), then redeploy

Copy/paste this on the VPS:

# sanity: show the container + its mounts (make sure /data is a volume/bind mount)
docker inspect openclaw-fjhv-openclaw-1 --format '{{json .Mounts}}' | jq

# stop + remove ONLY the container (this does NOT remove volumes)
docker stop openclaw-fjhv-openclaw-1 || true
docker rm openclaw-fjhv-openclaw-1 || true

#

# confirm it's gone
docker ps -a | grep -i openclaw || true

Then click Deploy again in Hostinger.

Important gotcha (so you don’t get whiplash again)

When Hostinger redeploys, it pulls ghcr.io/hostinger/hvps-openclaw:latest and recreates the container. If that image is still shipping an older OpenClaw, you may end up back on an old version again.

After redeploy, immediately check:

docker exec -it openclaw-fjhv-openclaw-1 openclaw --version

If it’s not 2026.2.26, you’ll need to either:

#

update OpenClaw inside the container again, or
pin/use an image/tag that already contains the right version.

If you paste the docker inspect ...Mounts... output (redact paths if you want), I can tell you if /data is safely persisted before you remove anything.

worn heath Mar 1, 2026, 7:25 PM

#

ok it looks like it works now, now i need to get my models added back in

cloud ruinBOT Mar 1, 2026, 7:26 PM

#

Nice — if the container boots now, getting models back is just restoring the auth store (or re-adding auth).

Option A (fastest): copy your old auth-profiles into the container (if you still have them)

If you previously had OpenClaw working on the host (systemd install), your keys are probably here:

/root/.openclaw/agents/main/agent/auth-profiles.json

Run this whole block:

# 1) Check host auth store exists
ls -la /root/.openclaw/agents/main/agent/auth-profiles.json

# 2) Copy it into the container
docker cp /root/.openclaw/agents/main/agent/auth-profiles.json \
  openclaw-fjhv-openclaw-1:/data/.openclaw/agents/main/agent/auth-profiles.json

#


# 3) Fix ownership + restart
docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc 'chown 1000:1000 /data/.openclaw/agents/main/agent/auth-profiles.json || true'
docker restart openclaw-fjhv-openclaw-1

# 4) Verify models/auth now show up
docker exec -it openclaw-fjhv-openclaw-1 openclaw models status

Option B: re-add auth interactively (if you don’t have the old file)

docker exec -it openclaw-fjhv-openclaw-1 openclaw models auth add
docker exec -it openclaw-fjhv-openclaw-1 openclaw models status

(Choose Anthropic API key or setup-token depending on what you used before: https://docs.openclaw.ai/providers/anthropic)

#

If ls -la /root/.openclaw/... fails (file missing), tell me what provider(s) you used before and whether you had backups of /data/.openclaw/ — then we’ll pick the quickest re-auth path.

worn heath Mar 1, 2026, 7:27 PM

#

waht about re-setting up my telegram settings

cloud ruinBOT Mar 1, 2026, 7:27 PM

#

To re-set up Telegram in the Hostinger container, do it from inside the container with the channels CLI (this writes the right config shape for you).

1) See what OpenClaw thinks is configured right now

docker exec -it openclaw-fjhv-openclaw-1 openclaw channels list
docker exec -it openclaw-fjhv-openclaw-1 openclaw channels status

2) Add Telegram again (recommended: interactive so you don’t fight quoting)

Run this and paste your Telegram bot token when prompted (don’t paste the token into Discord):

docker exec -it openclaw-fjhv-openclaw-1 openclaw channels add --channel telegram

(Non-interactive version, if you prefer:)

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw channels add --channel telegram --token "<BOT_TOKEN>"

3) Restart + confirm Telegram is “up”

docker restart openclaw-fjhv-openclaw-1
docker exec -it openclaw-fjhv-openclaw-1 openclaw status --deep

4) Test

Message your bot on Telegram. If your DM policy is the default pairing, you should get a pairing flow/code and then you approve it.

If anything fails, paste the output of:

docker exec -it openclaw-fjhv-openclaw-1 openclaw channels status

#

(That output is safe to share; it won’t require you to paste tokens.)

worn heath Mar 1, 2026, 9:17 PM

#

how can i add me to the allow list so it will work? somehow it got turned to allow list but didnt get my ID saved

Problem:

channels.telegram.allowFrom: channels.telegram.dmPolicy="allowlist" requires channels.telegram.allowFrom to contain at least one sender ID

cloud ruinBOT Mar 1, 2026, 9:18 PM

#

That error happens before the gateway can even start: dmPolicy="allowlist" requires channels.telegram.allowFrom to have at least one Telegram user id.

Since you don’t have your ID handy, the easiest recovery is:

1) Temporarily switch Telegram back to `pairing` (so it can boot)

(run on the VPS)

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.dmPolicy "\"pairing\""
docker restart openclaw-fjhv-openclaw-1

2) Get your Telegram numeric user id

Now DM your bot once, and on the VPS run:

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw logs --follow

In the log line for your DM, look for from.id — that number is your Telegram user id.

(Alternative: Bot API getUpdates, but logs is simplest.)

3) Put yourself in `allowFrom`, then switch back to allowlist

Replace 123456789 with your from.id:

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.allowFrom '[123456789]' --strict-json
docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.dmPolicy "\"allowlist\""
docker restart openclaw-fjhv-openclaw-1

#

After that, DMs from you will work again.

If you want, paste the from.id only (just the number) and I’ll give you the exact one-liner with correct quoting for your setup.

worn heath Mar 1, 2026, 9:24 PM

#

that doesnt seem to be updating it

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

channels.telegram.allowFrom: channels.telegram.dmPolicy="allowlist" requires channels.telegram.allowFrom to contain at least one sender ID

Run: openclaw doctor --fix

cloud ruinBOT Mar 1, 2026, 9:25 PM

#

That’s happening because the config is still stuck in:

channels.telegram.dmPolicy: "allowlist"
channels.telegram.allowFrom: []

…and in 2.26 that’s a hard invalid config, so the gateway won’t boot.

If openclaw config set … dmPolicy "pairing" didn’t stick, the most reliable way is to patch the config file directly inside the container.

Copy/paste this whole block:

# Force Telegram back to pairing so the gateway can start (no allowFrom needed)
docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '
node - <<'"'"'NODE'"'"'
const fs = require("fs");

#

const p = "/data/.openclaw/openclaw.json";
const o = JSON.parse(fs.readFileSync(p, "utf8"));

o.channels ??= {};
o.channels.telegram ??= {};

// make config valid
o.channels.telegram.dmPolicy = "pairing";
// keep allowFrom present but empty is fine in pairing mode
if (!Array.isArray(o.channels.telegram.allowFrom)) o.channels.telegram.allowFrom = [];

fs.writeFileSync(p, JSON.stringify(o, null, 2));
console.log("telegram.dmPolicy =", o.channels.telegram.dmPolicy);
console.log("telegram.allowFrom =", JSON.stringify(o.channels.telegram.allowFrom));
NODE

#

'

# restart + show whether it boots now
docker restart openclaw-fjhv-openclaw-1
docker logs -n 80 openclaw-fjhv-openclaw-1

Once it’s booted, you can get your Telegram numeric ID and re-enable allowlist:

DM your bot once, then on the VPS run:

docker exec -it openclaw-fjhv-openclaw-1 openclaw logs --follow

Look for from.id (that number is your Telegram user id).

Then set allowFrom + switch back to allowlist (replace 123456789):

#

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.allowFrom '[123456789]' --strict-json
docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.dmPolicy "\"allowlist\""
docker restart openclaw-fjhv-openclaw-1

If the first block still doesn’t change the file, paste the telegram snippet from /data/.openclaw/openclaw.json after running it (it would mean Hostinger is rewriting the config on boot).

worn heath Mar 1, 2026, 9:25 PM

#

i cant copy and paste when you put it in 3 different boxes like that

cloud ruinBOT Mar 1, 2026, 9:26 PM

#

Copy/paste this single block (it forces Telegram back to pairing, restarts the container, and shows logs):

docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc '
node - <<'"'"'NODE'"'"'
const fs = require("fs");
const p = "/data/.openclaw/openclaw.json";
const o = JSON.parse(fs.readFileSync(p, "utf8"));

o.channels ??= {};
o.channels.telegram ??= {};
o.channels.telegram.dmPolicy = "pairing";
if (!Array.isArray(o.channels.telegram.allowFrom)) o.channels.telegram.allowFrom = [];

fs.writeFileSync(p, JSON.stringify(o, null, 2));
console.log("Set channels.telegram.dmPolicy=pairing");

#

console.log("channels.telegram.allowFrom=", JSON.stringify(o.channels.telegram.allowFrom));
NODE
'
docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

Once that boots, tell me if your bot replies in Telegram DMs. If you still want allowlist mode after it’s working, we’ll do the “get your Telegram from.id” step next (also as one copy/paste block).

worn heath Mar 1, 2026, 9:26 PM

#

you are putting it in two separate windows so I cant copy it

cloud ruinBOT Mar 1, 2026, 9:26 PM

#

docker exec -u root -it openclaw-fjhv-openclaw-1 sh -lc 'node - <<'"'"'NODE'"'"'
const fs = require("fs");
const p = "/data/.openclaw/openclaw.json";
const o = JSON.parse(fs.readFileSync(p, "utf8"));

o.channels ??= {};
o.channels.telegram ??= {};
o.channels.telegram.dmPolicy = "pairing";
if (!Array.isArray(o.channels.telegram.allowFrom)) o.channels.telegram.allowFrom = [];

fs.writeFileSync(p, JSON.stringify(o, null, 2));
console.log("Set channels.telegram.dmPolicy=pairing");
console.log("channels.telegram.allowFrom=", JSON.stringify(o.channels.telegram.allowFrom));
NODE'

#

docker restart openclaw-fjhv-openclaw-1
docker logs -n 120 openclaw-fjhv-openclaw-1

worn heath Mar 1, 2026, 9:27 PM

#

opk tha tworked now

cloud ruinBOT Mar 1, 2026, 9:27 PM

#

Good — now the container can boot again.

If you want to keep it in pairing mode, you’re done for Telegram DMs.

If you want to go back to allowlist (only you can DM it), do this next single copy/paste block:

docker exec -it openclaw-fjhv-openclaw-1 openclaw logs --follow --since 5m

Run that command.
DM your bot on Telegram once (“hi”).
In the logs you’ll see a Telegram from.id number.

Send me just that number (it’s not a secret), and I’ll give you one copy/paste command to set:

channels.telegram.allowFrom = [<your_id>]

#

channels.telegram.dmPolicy = "allowlist"
restart the container

worn heath Mar 1, 2026, 9:28 PM

#

jsut give me the copy/paste command and I will fill in my telegram ID

cloud ruinBOT Mar 1, 2026, 9:28 PM

#

TG_ID=123456789

docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.allowFrom "[$TG_ID]" --strict-json
docker exec -it openclaw-fjhv-openclaw-1 openclaw config set channels.telegram.dmPolicy "\"allowlist\""
docker restart openclaw-fjhv-openclaw-1
docker logs -n 80 openclaw-fjhv-openclaw-1

worn heath Mar 1, 2026, 9:28 PM

#

do i include TG_ID at the top or just insert it between the brackets?

#2.26 broke openclaw. should i give up?

Fastest “get it booting” fix (doesn’t rely on that flag)

Also: why updates feel like “starting fresh”

Next thing to paste (this will reveal the mismatch)

Likely fix (if you’re using a supervised service)

About “it comes back after I delete it”

Fix: regenerate the gateway service to point at the same OpenClaw you’re running in the CLI

Bonus: why it “comes back” when you delete it

Separate thing: remote access

Next: confirm what version the running service install actually is

Also: are you using Docker / a panel / any “one-click” host?

Separate (but important): why you “can’t access it” from your laptop

Next step: find what is producing the /data/... + port 28318 logs

If your goal right now is “I want to access the Control UI from my laptop”

What to do next (pick one)

A) If your goal is “open the Control UI from your laptop” (fastest)

B) If your goal is “figure out where the /data + 28318 logs are coming from”

C) If your goal is “make it accessible without SSH”

Step 1: confirm the OpenClaw version inside the container

Step 2: pick ONE deployment path (recommended)

Quick question

1) Check what version OpenClaw the container is actually running

2) Quick fix (update OpenClaw inside the container), then restart it

3) Better fix (make it survive updates): pull a newer Hostinger image + recreate

4) Confirm your state is persisted (this is why updates feel like “start fresh”)

Fix (keep using Hostinger Docker + port 47974)

Option 1 (fastest): upgrade OpenClaw inside the container to 2026.2.26

Option 2 (better long-term): update the Hostinger image (if they’ve published a newer one)

Why it “comes back” when you delete it

One more quick check (to stop the “start fresh every update” problem)

1) First confirm the container version (after your attempt)

2) Re-run the upgrade explicitly as root (most common issue is permissions)

3) If that still doesn’t work

Next: verify the container actually boots cleanly

Also: make sure port 47974 is actually listening again

Finally: stop the “updates make me start fresh” problem

Fastest fix (recommended)

If you don’t want allowlist mode for WhatsApp DMs

If you do want allowlist mode

One important detail

1) Make sure the config now validates

2) Restart the container and read the startup logs

3) Confirm it’s listening on the expected port (47974 / 8080)

Disable WhatsApp in /data/.openclaw/openclaw.json (inside the container)

Restart + verify it boots

Fix it by disabling WhatsApp (container-only)

If the error keeps coming back

Fastest fix (Telegram-only): disable WhatsApp in the config file

How to “see if it works”

Alternative (if you want to keep WhatsApp but stop the error)

1) (Optional) stop the cron spam for now

2) Add your model credentials (this is the real fix)

Fix: stop + remove the existing container (don’t delete volumes), then redeploy

Important gotcha (so you don’t get whiplash again)

Option A (fastest): copy your old auth-profiles into the container (if you still have them)

Option B: re-add auth interactively (if you don’t have the old file)

1) See what OpenClaw thinks is configured right now

2) Add Telegram again (recommended: interactive so you don’t fight quoting)

3) Restart + confirm Telegram is “up”

4) Test

1) Temporarily switch Telegram back to pairing (so it can boot)

2) Get your Telegram numeric user id

3) Put yourself in allowFrom, then switch back to allowlist

Next step: find what is producing the `/data/...` + port `28318` logs

Disable WhatsApp in `/data/.openclaw/openclaw.json` (inside the container)

1) Temporarily switch Telegram back to `pairing` (so it can boot)

3) Put yourself in `allowFrom`, then switch back to allowlist