#OpenClaw config raw json5 setup

1 messages · Page 1 of 1 (latest)

tender scaffoldBOT
#

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

humble shoalBOT
#

Yep — but I’ll need the actual broken bit (config + error) to fix it.

OpenClaw config is strictly schema-validated now: any unknown key / wrong type can make the Gateway refuse to start. (host / port in the wrong place is a very common ChatGPT “helpful” breakage.)
Docs: https://docs.openclaw.ai/gateway/configuration (see “Strict validation”)

1) Paste these outputs (from the Win10 VM)

Run in PowerShell / CMD and paste results:

openclaw --version
openclaw gateway status
openclaw doctor
openclaw logs --tail 200

2) Paste your config (redact secrets)

Upload or paste ~/.openclaw/openclaw.json (on Windows usually: C:\Users\<you>\.openclaw\openclaw.json).

#

Redact things like tokens/api keys (replace with "REDACTED"), but leave the structure intact.

3) Tell me what “busted” means

Which one is happening?

  • Gateway won’t start (config validation error)
  • Gateway starts but can’t connect to Ollama
  • Gateway connects but models don’t show up / tool-calling is broken

Quick sanity check for your setup (remote Ollama)

From the Win10 VM, does this work?

curl http://<TRUENAS_LAN_IP>:11434/api/tags

Also: don’t use ...:11434/v1 with OpenClaw for Ollama. Use the native base URL (http://host:11434), otherwise tool calling tends to go sideways.

#

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

Once you paste openclaw doctor + the config, I’ll point to the exact keys to remove/rename and give you a known-good minimal config for “Win10 VM → remote TrueNAS Ollama”.

#

That config is almost all wizard-generated and fine — the part that’s “busting” it is almost certainly this at the bottom:

"providers": [
  {
    "name": "ollama",
    "type": "ollama",
    "base_url": "http://192.168.0.130:30068",
    "override": { "model": "qwen3:8b" }
  }
]

OpenClaw config is strictly validated and does not have a root-level providers key (and it also won’t accept snake_case like base_url). Unknown keys = Gateway refuses to start.
Ref: https://docs.openclaw.ai/gateway/configuration (see “Strict validation”)

Fix: remove that providers block and use models.providers.ollama instead

#
  1. Delete the entire "providers": [ ... ] section.

  2. Add this (keep the rest of your config as-is):

{
  // ...your existing config...

  agents: {
    defaults: {
      // keep your existing defaults here...
      model: { primary: "ollama/qwen3:8b" },
    },
  },

  models: {
#
    providers: {
      ollama: {
        apiKey: "ollama-local",              // any value works
        baseUrl: "http://192.168.0.130:30068", // IMPORTANT: no /v1
        api: "ollama",                      // force native Ollama API/tool calling
        models: [
          {
            id: "qwen3:8b",
            name: "qwen3 8b",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 8192 * 10,
          },
#
        ],
      },
    },
  },
}

Ollama provider docs (esp. remote Ollama warning): https://docs.openclaw.ai/providers/ollama

Quick sanity check (from the Win10 VM)

Make sure that URL is actually Ollama’s native API:

curl http://192.168.0.130:30068/api/tags
#

If that fails, your Ollama is probably on the default port:

curl http://192.168.0.130:11434/api/tags

…and then set baseUrl to the one that works.

Important: rotate your Telegram bot token

You pasted a real botToken publicly in this thread. You should revoke/regenerate it in BotFather and update your config, otherwise anyone can control that bot.

If it still won’t boot

Paste the output of:

openclaw doctor
#
openclaw logs --tail 200

and I’ll tell you the exact remaining key(s) it’s rejecting.

minor patio
#

ollama is running when quired from a web page. please update my whole json as per your suggestion

humble shoalBOT
#

Here’s your full updated config with the broken providers: [...] block removed and replaced with the supported models.providers.ollama config.

Two important notes before you paste it in:

  • You leaked a real Telegram botToken earlier in this thread — rotate it in BotFather and replace it below (I’ve redacted it here).
  • Make sure your Ollama endpoint is actually Ollama’s native API (it must answer GET /api/tags). Do not use an OpenAI-compatible /v1 URL.

Updated ~/.openclaw/openclaw.json (JSON5)

{
  wizard: {
    lastRunAt: "2026-03-02T07:20:00.687Z",
    lastRunVersion: "2026.3.1",
    lastRunCommand: "onboard",
    lastRunMode: "local",
  },
#
  agents: {
    defaults: {
      workspace: "C:\\Users\\Shayne\\.openclaw\\workspace",

      compaction: { mode: "safeguard" },

      maxConcurrent: 4,

      subagents: { maxConcurrent: 8 },

      // Use your Ollama model by default
      model: { primary: "ollama/qwen3:8b" },
    },
  },
#
  messages: {
    ackReactionScope: "group-mentions",
  },

  commands: {
    native: "auto",
    nativeSkills: "auto",
    restart: true,
    ownerDisplay: "raw",
  },

  session: {
    dmScope: "per-channel-peer",
  },
#
  hooks: {
    internal: {
      enabled: true,
      entries: {
        "boot-md": { enabled: true },
      },
    },
  },

  channels: {
    telegram: {
      enabled: true,
      dmPolicy: "pairing",

      // ROTATE THIS TOKEN (it was posted publicly) then paste the new one here:
#
      botToken: "__TELEGRAM_BOT_TOKEN_REDACTED__",

      groupPolicy: "allowlist",
      streaming: "off",
    },
  },

  gateway: {
    port: 18789,
    mode: "local",
    bind: "loopback",
    auth: {
      mode: "token",
      token: "__OPENCLAW_REDACTED__",
    },
#
    tailscale: {
      mode: "off",
      resetOnExit: false,
    },
    nodes: {
      denyCommands: [
        "camera.snap",
        "camera.clip",
        "screen.record",
        "calendar.add",
        "contacts.add",
        "reminders.add",
      ],
    },
  },
#

  skills: {
    install: { nodeManager: "npm" },
  },

  plugins: {
    entries: {
      telegram: { enabled: true },
    },
  },

  meta: {
    lastTouchedVersion: "2026.3.1",
    lastTouchedAt: "2026-03-02T07:20:00.784Z",
  },
#

  // âś… Correct Ollama provider config (replaces the invalid root `providers: []`)
  models: {
    providers: {
      ollama: {
        // Any value works; Ollama doesn’t require a real key, but OpenClaw uses it as an “enabled” flag.
        apiKey: "ollama-local",

        // This must be the *native Ollama* base URL (NO /v1).
        // If 30068 is your TrueNAS port-forward to Ollama, that’s fine.
        baseUrl: "http://192.168.0.130:30068",

        // Force native Ollama API/tool calling behavior
        api: "ollama",
#
        // Explicit models are required when you set models.providers.ollama
        models: [
          {
            id: "qwen3:8b",
            name: "Qwen3 8B",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 8192 * 10,
          },
        ],
      },
    },
  },
#
}

Quick check (from the Win10 VM)

This should return JSON (model list). If it doesn’t, your baseUrl is not actually Ollama:

curl http://192.168.0.130:30068/api/tags

If you paste the output of:

openclaw doctor
openclaw logs --tail 200

…I can tell you immediately if anything else in the file is failing schema validation (or if the Ollama URL is pointing at something like Open WebUI instead of Ollama).

minor patio
#

GatewayRequestError: SyntaxError: JSON5: invalid character '*' at 117:29

humble shoalBOT
#

That error is because your config contains a literal * somewhere outside of quotes.

In the config I gave you, there’s one obvious culprit:

maxTokens: 8192 * 10,

JSON5 is not JavaScript — it doesn’t allow math expressions. The * is invalid there.

Fix

Change it to a plain number:

maxTokens: 81920,
#

Quick way to confirm

Search your config for * and make sure every * is inside quotes (e.g. "*"), not used as an operator.

Common other place people hit this:

  • allowFrom: [*] ❌ should be allowFrom: ["*"] âś…

After fixing, run:

openclaw doctor

If you paste the updated models.providers.ollama.models[0] block (or the whole file), I can sanity-check there aren’t any other stray * / syntax issues.

minor patio
#

it took that json....saved and now updated....do I need to reboot?

humble shoalBOT
#

Usually no reboot.

OpenClaw watches ~/.openclaw/openclaw.json and hot-reloads it, so after saving a fixed config it should recover on its own.

That said, if the Gateway was failing to start because of the bad JSON5, you may need to restart the Gateway process/service (not the whole VM):

Check if it’s running/healthy

openclaw gateway status
openclaw health

If it’s not healthy, restart the gateway

openclaw gateway restart
#

Then verify Ollama + channel status

openclaw models list
openclaw channels status --probe

If openclaw gateway status shows Runtime: running and RPC probe: ok, you’re good — no VM reboot needed.

minor patio
#

I asked it hi and came back with > ⚠️ Agent failed before reply: Model context window too small (8192 tokens). Minimum is 16000.
Logs: openclaw logs --follow

humble shoalBOT
#

That message means OpenClaw tried to run, but your selected Ollama model is configured as ctx=8192, and OpenClaw needs ≥ 16000 just to fit its system prompt + tool schemas + a bit of chat history (so 8k models basically can’t run the agent).

Fix: bump the model’s contextWindow (and make maxTokens a number)

In your ~/.openclaw/openclaw.json, find:

models: {
  providers: {
    ollama: {
      models: [
        {
          id: "qwen3:8b",
          contextWindow: 8192,
          maxTokens: 81920,
        }
      ]
#
    }
  }
}

Change it to at least 16000 (I’d do 16384 or 32768):

{
  id: "qwen3:8b",
  name: "Qwen3 8B",
  reasoning: false,
  input: ["text"],
  cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
#
  contextWindow: 32768,   // <- >= 16000
  maxTokens: 327680,      // <- MUST be a plain number (no "32768 * 10")
}

Then restart the gateway (safer than hoping hot reload recovers)

openclaw gateway restart

Quick verification

Run:

openclaw models status
#

If it still complains, paste the output of:

openclaw doctor
openclaw logs --tail 120

Also worth checking what Ollama thinks the model context is (so we don’t set it higher than it can actually do):

ollama show qwen3:8b

If ollama show reports only 8192, you’ll need either a variant/config with higher ctx (or a different model with >=16k).

minor patio
#

it worked....how can I hook up that telegram bot now?

humble shoalBOT
#

To “hook up” Telegram in OpenClaw you just need (a) a BotFather token in config, then (b) approve your first DM via pairing.

Docs (worth keeping open):

0) Rotate your bot token first (important)

You pasted a real botToken earlier in this public thread. Go to BotFather → revoke/regenerate the token, then use the new one in config.

1) Put the token in your config

In ~/.openclaw/openclaw.json (Windows: C:\Users\<you>\.openclaw\openclaw.json), make sure you have:

channels: {
  telegram: {
    enabled: true,
#
    botToken: "123:abc_REPLACE_ME",
    dmPolicy: "pairing",
    // optional (groups)
    groups: { "*": { requireMention: true } },
  },
},

No openclaw channels login telegram needed — Telegram is config/env only. (Per docs)

2) Restart the gateway

Hot reload often works, but for first hookup just restart to be sure:

openclaw gateway restart
#

3) DM your bot, then approve the pairing

  1. In Telegram: open your bot chat and send “hi” (or /start)
  2. On the VM:
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

After approval, DM the bot again — it should reply normally.

4) If you want the bot to work in groups

Two extra Telegram-specific gotchas:

  • Bot privacy mode: by default the bot may not see all group messages. In BotFather run /setprivacy (or make the bot a group admin). If you change this, remove + re-add the bot to the group.
  • Group allowlisting + mention gating: groups are typically blocked unless allowed, and replies usually require a mention.
#

Most reliable: allow one group explicitly once you know the group id (it’s a negative number like -100...). Easiest way to find it:

  • run openclaw logs --follow
  • send a message in the group
  • look for chat.id

Then configure:

channels: {
  telegram: {
    groupPolicy: "allowlist",
    groups: {
      "-1001234567890": {
        requireMention: false, // or true if you want mention-only
        groupPolicy: "open",   // allow anyone in that group (or use allowFrom for tighter control)
      },
#
    },
  },
},

If anything doesn’t respond, paste:

openclaw channels status --probe
openclaw pairing list telegram
openclaw logs --tail 120

and I’ll tell you exactly what it’s stuck on.

minor patio
#

this was already in my json > "channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "allowlist",
"streaming": "off"
}

humble shoalBOT
#

Perfect — that means Telegram is already enabled. At this point there’s nothing else to “hook up” in config; the remaining step is DM pairing approval (and optionally allowing groups).

1) Verify the Telegram channel is actually up

On the Win10 VM:

openclaw channels status --probe

You should see Telegram as connected/ready. If it’s not, run:

openclaw logs --follow

(Usually it’s a bad token, or the VM can’t reach api.telegram.org due to DNS/firewall.)

#

Also: botToken must be the BotFather token (123456:AA...), not your gateway token.

2) Approve your DM (pairing)

  1. In Telegram, DM your bot (“hi” or /start).
  2. On the VM:
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Then DM the bot again — it should reply.

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

3) If you want it to work in groups too

Right now you have:

#
  • groupPolicy: "allowlist" âś… (secure default)
  • but you also need to allow groups via channels.telegram.groups

Example (allow one specific group and don’t require mentioning the bot):

channels: {
  telegram: {
    groupPolicy: "allowlist",
    groups: {
      "-1001234567890": { requireMention: false, groupPolicy: "open" },
    },
  },
},

To get the group id (-100...), run openclaw logs --follow and send a message in the group; look for chat.id.

#

Telegram doc: https://docs.openclaw.ai/channels/telegram

If you paste the output of openclaw channels status --probe I can tell you immediately whether you’re stuck on “channel not connected” vs “pairing not approved yet”.

minor patio
#

PS C:\Users\Shayne> openclaw logs --follow

🦞 OpenClaw 2026.3.1 (2a8ac97) — If it works, it's automation; if it breaks, it's a "learning opportunity."

|
o Doctor warnings --------------------------------------------------------------------------+
| |
| - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is |
| empty — all group messages will be silently dropped. Add sender IDs to |
| channels.telegram.groupAllowFrom or channels.telegram.allowFrom, or set groupPolicy to |
| "open". |
| |
+--------------------------------------------------------------------------------------------+
Log file: C:\Users\Shayne\AppData\Local\Temp\openclaw\openclaw-2026-03-02.log
09:30:36 info bonjour: advertised gateway fqdn=DESKTOP-EPCJ8LP (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
09:30:37 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider (@ShayneBossClaw_bot)
09:30:37 info telegram/network {"subsystem":"telegram/network"} autoSelectFamily=true (default-node22)
09:30:37 info telegram/network {"subsystem":"telegram/network"} dnsResultOrder=ipv4first (default-node22)
09:30:37 debug skills {"subsystem":"skills"} {"rawName":"skill-creator","sanitized":"/skill_creator"} Sanitized skill command name "skill-creator" to "/skill_creator".

humble shoalBOT
#

Nice — Telegram is actually starting fine:

[default] starting provider (@ShayneBossClaw_bot)

That Doctor warning is only about Telegram groups, not DMs:

  • You have groupPolicy: "allowlist"
  • but groupAllowFrom (and allowFrom) are empty
  • so any group messages will be dropped (even if the bot is in the group)

If you just want Telegram DMs (most common)

You can ignore that warning, or silence it by disabling groups:

channels: {
  telegram: {
#
    groupPolicy: "disabled",
  },
},

Then do the actual DM hookup (pairing):

  1. DM your bot on Telegram (“hi”)
  2. On the VM:
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

(You’ll see the code either in the bot’s pairing message to you, or in pairing list.)

#

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

If you want the bot to work in Telegram groups

Pick one of these:

Option A (easy): allow anyone in allowed groups

channels: {
  telegram: {
    groupPolicy: "open",
    // and you still need to allow which group(s):
    groups: { "*": { requireMention: true } }, // or per-group id
  },
},

Option B (safer): only allow specific people to trigger it in groups

#
  1. Find your numeric Telegram user id:
  • DM the bot once
  • run openclaw logs --follow
  • look for from.id: <number>
  1. Add it:
channels: {
  telegram: {
    groupPolicy: "allowlist",
    groupAllowFrom: ["tg:123456789"], // your from.id
    groups: { "*": { requireMention: true } }, // or put a specific -100... group id here
  },
},
#

Docs: https://docs.openclaw.ai/channels/telegram (see Group policy / allowlists)

If you tell me “DM-only” vs “I want it in one specific group”, I’ll give you the tightest config for that and what IDs to paste.

minor patio
#

I updated the telegram section to this config, but still nothing when I post 'Hi" to telegram > "channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "disabled",
"streaming": "off"

humble shoalBOT
#

If you’re seeing zero reply at all from the bot, there are only a few possibilities — and the most common one is:

1) Are you DM’ing the bot, or “posting in Telegram” (a group)?

With:

groupPolicy: "disabled"

anything in groups will be silently ignored. This setting is only for groups.

So to test: open the bot profile → Message → hit Start (or send /start) → then send hi in the DM.

2) With dmPolicy: "pairing", the first DM won’t get a “normal” answer

Instead, OpenClaw should send you a pairing code and it will not process your message until you approve.

After you DM the bot, run on the VM:

#
openclaw pairing list telegram

If you see a pending code, approve it:

openclaw pairing approve telegram <CODE>

Then DM the bot again.

3) If pairing list shows nothing, the Gateway isn’t receiving Telegram updates

Run these and paste the output:

#
openclaw channels status --probe
openclaw gateway status
openclaw logs --tail 200

In the logs we’re looking for either:

  • inbound Telegram update lines (means it’s receiving your DM), or
  • errors like 401 (bad token) / network/DNS issues reaching api.telegram.org.

One more thing: make sure botToken is the BotFather token (123456:AA...), not the gateway token (and don’t paste it here—rotate it if it was ever posted).

minor patio
#

I think I am DMing direct to BossClaw...I put in /start .... then a 'hi...but nothing

humble shoalBOT
#

If you DM’d /start + hi and got literally nothing back (not even a pairing code), then either:

  1. OpenClaw isn’t receiving your Telegram messages, or
  2. it receives them but can’t send the pairing prompt back (token/network/etc).

Let’s pinpoint which in 60 seconds:

A) Did OpenClaw receive your DM at all?

Right after you send hi to the bot, run on the VM:

openclaw pairing list telegram

What it means

  • If you see a pending code → Telegram DM is arriving. Approve it:
#
  openclaw pairing approve telegram <CODE>

Then DM hi again.

  • If it’s empty → your DM never reached the gateway (or Telegram polling is broken/conflicted). Go to B.

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

B) Check Telegram channel health + look for conflicts/errors

Run:

openclaw channels status --probe
openclaw logs --tail 200
#

Paste the output (redact any secrets if they appear).

The #1 “nothing happens” cause: another process is consuming updates

If logs show something like “Conflict … terminated by other getUpdates request” / 409 Conflict, it means some other app/OpenClaw instance is using the same bot token and Telegram only allows one poller.

Fix: stop the other instance, or use a different bot token for this gateway.

C) Quick sanity check: are you sure it’s the BotFather token?

Your config must have the BotFather token that looks like:

1234567890:AA...

(not the gateway token). Don’t paste it here (and rotate it if it was ever posted publicly).


If you paste openclaw channels status --probe + the last 200 log lines, I can tell you exactly whether this is (a) pairing not approved, (b) polling conflict, (c) token/auth error, or (d) network/DNS to api.telegram.org.

minor patio
#

PS C:\Users\Shayne> openclaw pairing list telegram

🦞 OpenClaw 2026.3.1 (2a8ac97) — Because Siri wasn't answering at 3AM.

No pending telegram pairing requests.
PS C:\Users\Shayne>

humble shoalBOT
#

“No pending telegram pairing requests” after you DM /start + hi means the Gateway is not seeing any inbound Telegram updates at all (so it can’t even create a pairing request).

Next step is to find out whether Telegram is failing to poll (token/network/conflict) vs you DM’d a different bot.

1) Check Telegram channel status

On the Win10 VM:

openclaw channels status --probe

Paste the output (it shouldn’t include secrets). We’re looking for Telegram showing ready vs an error like 401 or 409 Conflict.

2) Watch logs while you send a DM

In one terminal:

#
openclaw logs --follow

Then in Telegram DM the bot again (/start, then hi). In the log, look for anything like:

  • 401 Unauthorized / “token invalid” → wrong BotFather token in config
  • 409 Conflict / “terminated by other getUpdates request” → another app/OpenClaw instance is using the same bot token
  • fetch failed / DNS/network errors to api.telegram.org → VM egress/DNS/IPv6 issue

If you paste ~30–50 lines around any Telegram error, I can tell you exactly which it is.

3) Sanity checks (fast)

  • Make sure you’re DM’ing the exact bot username shown in your logs (earlier it showed (@ShayneBossClaw_bot)).
  • Make sure botToken in config is the BotFather token (123456:AA...), not your OpenClaw gateway token.
  • If that BotFather token was ever posted publicly, rotate it in BotFather and restart:
#
  openclaw gateway restart

Drop openclaw channels status --probe + the relevant Telegram log chunk and we’ll get it unstuck quickly.

minor patio
#

PS C:\Users\Shayne> openclaw channels status --probe

🦞 OpenClaw 2026.3.1 (2a8ac97) — Think different. Actually think.

|
o
Gateway reachable.

  • Telegram default: enabled, configured, stopped, mode:polling, token:config, probe failed, error:Call to 'deleteWebhook' failed! (404: Not Found)

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
PS C:\Users\Shayne>

humble shoalBOT
#

That output is the smoking gun:

deleteWebhook failed! (404: Not Found)

On Telegram’s Bot API, 404 Not Found almost always means “your bot token is invalid” (wrong token, revoked/rotated token, copy/paste missing chars, etc.). OpenClaw calls deleteWebhook when starting polling mode, and Telegram returns 404 if the token doesn’t match any bot.

1) Verify the token from the Win10 VM (no guessing)

Run (replace <TOKEN> locally — don’t paste it here):

curl "https://api.telegram.org/bot<TOKEN>/getMe"

Expected result: JSON with "ok": true and your bot username.

  • If you get 404 Not Found → token is definitely wrong/revoked.
  • If you get {"ok":true,...} → token is valid and we’ll look at the next error.
#

2) Fix it

  • Go to BotFather → /mybots → pick your bot → API Token → regenerate/copy.
  • Update your config at C:\Users\Shayne\.openclaw\openclaw.json:
channels: {
  telegram: {
    botToken: "123456789:AA....", // the BotFather token
  }
}

Then restart the gateway:

openclaw gateway restart
#

3) Re-check

openclaw channels status --probe

Once Telegram shows healthy, DM the bot and pairing should appear:

openclaw pairing list telegram

One more important note: you pasted a bot token earlier in the thread. If that token is the same bot you’re using now, you should rotate it (which also explains the 404 if you already rotated but didn’t update the VM config).

minor patio
#

somethnig happened...I repasted the token and now it gives a pairng code on telegram..what do I do with it?

humble shoalBOT
#

Approve it — that pairing code is the “owner approval” step for Telegram DMs.

1) On the Win10 VM, list pending requests

openclaw pairing list telegram

You’ll see the same 8‑char code.

2) Approve it

openclaw pairing approve telegram <CODE>

(Use the code you got in Telegram.)

3) Test

#

Send hi to the bot again in Telegram — now it should reply normally.

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

If approve says it can’t find the code, the code may have expired (they expire after ~1 hour) — just DM the bot again to generate a fresh one.

minor patio
#

worked well..you can close this and file it as a success

humble shoalBOT
#

Awesome — glad it’s working now.

If you want it indexed on Answer Overflow for future folks, please right‑click the message that fixed it → Apps → ✅ Mark Solution (usually the one about the Telegram token 404 / re‑pasting the correct BotFather token + pairing approval).

Recap of what fixed it:

  • Telegram was failing with deleteWebhook (404) → bot token was invalid
  • Replaced with the correct BotFather token
  • Approved the DM pairing code via openclaw pairing approve telegram <CODE>

If anything else breaks later, openclaw channels status --probe + openclaw doctor are the fastest first checks.

minor patio
#

can you remove the bot codes in this?