#OpenClaw config raw json5 setup
1 messages · Page 1 of 1 (latest)
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
-
Delete the entire
"providers": [ ... ]section. -
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.
ollama is running when quired from a web page. please update my whole json as per your suggestion
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
botTokenearlier 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/v1URL.
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).
GatewayRequestError: SyntaxError: JSON5: invalid character '*' at 117:29
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 beallowFrom: ["*"]✅
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.
it took that json....saved and now updated....do I need to reboot?
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.
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
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).
it worked....how can I hook up that telegram bot now?
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):
- Telegram channel: https://docs.openclaw.ai/channels/telegram
- Pairing: https://docs.openclaw.ai/channels/pairing
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
- In Telegram: open your bot chat and send “hi” (or
/start) - 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.
this was already in my json > "channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "allowlist",
"streaming": "off"
}
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)
- In Telegram, DM your bot (“hi” or
/start). - 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”.
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".
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(andallowFrom) 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):
- DM your bot on Telegram (“hi”)
- 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
- Find your numeric Telegram user id:
- DM the bot once
- run
openclaw logs --follow - look for
from.id: <number>
- 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.
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"
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 reachingapi.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).
I think I am DMing direct to BossClaw...I put in /start .... then a 'hi...but nothing
If you DM’d /start + hi and got literally nothing back (not even a pairing code), then either:
- OpenClaw isn’t receiving your Telegram messages, or
- 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.
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>
“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 config409 Conflict/ “terminated by other getUpdates request” → another app/OpenClaw instance is using the same bot tokenfetch failed/ DNS/network errors toapi.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
botTokenin 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.
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>
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).
somethnig happened...I repasted the token and now it gives a pairng code on telegram..what do I do with it?
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.
worked well..you can close this and file it as a success
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.
can you remove the bot codes in this?