good bot | Friends of the Crustacean 🦞🤝 | Page 1

warped karma Feb 27, 2026, 7:44 PM

#

Discord default: enabled, configured, stopped, token:config, probe failed, error:Failed to resolve Discord application id

low basinBOT Feb 27, 2026, 7:46 PM

#

That probe output usually means OpenClaw can’t fetch your bot’s Application ID from Discord’s API (/oauth2/applications/@me) using the token you provided — so the Discord provider bails out before it even connects.

A couple quick checks that narrow it down fast:

What version are you on? (this matters; some versions hide the real underlying error)

openclaw --version
node --version

From the same machine running the gateway, does this succeed? (don’t paste the token in chat)

curl -sS -H "Authorization: Bot YOUR_TOKEN" \
https://discord.com/api/v10/oauth2/applications/@me

If this returns 401/403 → it’s the wrong token (common mixup: client secret / user token / whitespace). Regenerate “Bot Token” in the Developer Portal.
If this returns JSON with an id → token + network are fine, and it’s likely an OpenClaw-side bug/version issue.

#

Grab the real error from logs while probing:

openclaw logs --follow
# in another terminal:
openclaw channels status --probe

Docs refs (command ladder + Discord setup):

If you paste back (a) openclaw --version and (b) whether the curl .../oauth2/applications/@me call works (just yes/no + HTTP status), I can tell you the most likely fix. If it looks like the known bug, it’s worth tracking/updating on this issue: https://github.com/openclaw/openclaw/issues/17080

warped karma Feb 27, 2026, 7:49 PM

#

Versions:
2026.2.26
v22.22.0

curl output:
{"id":"1473708201764720814","name":"Shelldon","icon":"ab117317a2d943f38afee1d0f3fdeb17","description":"Clip's OpenClaw Bot","type":null,"bot":{"id":"1473708201764720814","username":"Shelldon","avatar":"ab117317a2d943f38afee1d0f3fdeb17","discriminator":"1088","public_flags":0,"flags":0,"bot":true,"banner":"4102a201eb8bc8f339678d8e10e73350","accent_color":null,"global_name":null,"avatar_decoration_data":null,"collectibles":null,"display_name_styles":null,"banner_color":null,"clan":null,"primary_guild":null},"summary":"","is_monetized":false,"is_verified":false,"is_discoverable":false,"bot_public":false,"bot_require_code_grant":false,"integration_types_config":{"0":{},"1":{}},"verify_key":"115630f3c88904cf74cd5fb37532d7af1d4d46db03e8638493c8a2db5d443685","flags":11051008,"hook":true,"storefront_available":false,"redirect_uris":[],"interactions_endpoint_url":null,"role_connections_verification_url":null,"owner":{"id":"251016047765749760","username":".clip.","avatar":"beb9e74c727794ac8e055df1efcb01be","discriminator":"0","public_flags":256,"flags":256,"banner":null,"accent_color":3498594,"global_name":"clipster","avatar_decoration_data":null,"collectibles":null,"display_name_styles":null,"banner_color":"#356262","clan":{"identity_guild_id":null,"identity_enabled":false,"tag":null,"badge":null},"primary_guild":{"identity_guild_id":null,"identity_enabled":false,"tag":null,"badge":null}},"approximate_guild_count":1,"approximate_user_install_count":0,"approximate_user_authorization_count":0,"interactions_event_types":[],"interactions_version":1,"explicit_content_filter":0,"rpc_application_state":0,"store_application_state":1,"verification_state":1,"integration_public":false,"integration_require_code_grant":false,"discoverability_state":1,"discovery_eligibility_flags":2500,"monetization_state":1,"verification_eligibility_flags":123676,"monetization_eligibility_flags":247524,"bot_approximate_guild_count":1,"team":null,"internal_guil

low basinBOT Feb 27, 2026, 7:51 PM

#

Nice — that curl https://discord.com/api/v10/oauth2/applications/@me response proves the token is valid and the Discord API is reachable from that machine. So this isn’t an “intents” problem or a bad bot token.

At this point the goal is: find out what the gateway’s Node fetch is failing with (timeout / 429 / DNS/IPv6 / TLS / proxy). In 2026.2.26 the logs should usually include a more specific “cause”.

Can you grab the Discord channel logs right after a restart?

openclaw gateway restart
openclaw channels logs --channel discord
# (or) openclaw logs --follow # and paste the discord-related lines when it exits

Two quick “this catches it surprisingly often” checks if logs show a timeout/network error:

Compare IPv4 vs IPv6 from the same host:

#

curl -4 -sS -H "Authorization: Bot YOUR_TOKEN" https://discord.com/api/v10/oauth2/applications/@me >/dev/null && echo ipv4_ok
curl -6 -sS -H "Authorization: Bot YOUR_TOKEN" https://discord.com/api/v10/oauth2/applications/@me >/dev/null && echo ipv6_ok

Confirm the gateway service is using the same config/user you’re testing with:

openclaw gateway status --deep

Paste whatever error lines you see from channels logs / logs --follow (no secrets) and we can pin it to one of: 429/rate-limit, 4s timeout, IPv6 routing, or a regression worth attaching to the existing bug report (#17080).

warped karma Feb 27, 2026, 7:54 PM

#

channel logs:
Log file: /tmp/openclaw/openclaw-2026-02-27.log
Channel: discord
2026-02-27T17:17:50.383Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:17:50.385Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 6/10 in 162s
2026-02-27T17:20:32.851Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:20:33.057Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:20:33.059Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 7/10 in 300s
2026-02-27T17:25:33.093Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:25:33.121Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:25:33.124Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 8/10 in 300s
2026-02-27T17:30:33.507Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:30:33.916Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:30:33.918Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 1/10 in 5s
2026-02-27T17:30:39.359Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:30:39.391Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:30:39.393Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 2/10 in 10s
2026-02-27T17:30:50.094Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:30:50.368Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id

this goes on foreve

#

output of curl:
ipv4_ok
ipv6_ok

low basinBOT Feb 27, 2026, 7:56 PM

#

Yeah — with that curl /oauth2/applications/@me working, your bot token is good and Discord is reachable. So this error is almost certainly “OpenClaw’s Node fetch to that same endpoint is failing, but your current log level is hiding the actual cause.”

Two things to do next:

1) Turn on debug file logs (so we can see why app-id resolution fails)

Per the logging docs, the /tmp/openclaw/*.log file is controlled by logging.level (not --verbose):
https://docs.openclaw.ai/gateway/logging

Run:

openclaw config set logging.level '"debug"' --json
openclaw gateway restart

openclaw channels logs --channel discord

If it still doesn’t show the underlying error, bump to trace:

#

openclaw config set logging.level '"trace"' --json
openclaw gateway restart

What we’re looking for in the logs is usually something like:

Discord application ID fetch failed (429|5xx) (rate limit / transient)
fetch failed / timeout
TLS/cert errors

2) Test “curl works but Node fetch fails” (common culprit: IPv6 or TLS/CA)

Run this from the gateway machine:

Node fetch test (matches what OpenClaw uses):

T='YOUR_TOKEN' node -e "fetch('https://discord.com/api/v10/oauth2/applications/@me',{headers:{Authorization:'Bot '+process.env.T}}).then(r=>r.text().then(t=>console.log(r.status,t))).catch(e=>console.error('NODE_FETCH_ERR',e))"

#

IPv4 vs IPv6 quick check:

curl -4 -sS -H "Authorization: Bot YOUR_TOKEN" https://discord.com/api/v10/oauth2/applications/@me >/dev/null && echo ipv4_ok
curl -6 -sS -H "Authorization: Bot YOUR_TOKEN" https://discord.com/api/v10/oauth2/applications/@me >/dev/null && echo ipv6_ok

If Node fetch fails but curl works → usually a TLS CA / corporate MITM situation, or broken IPv6 routing. (The Node command’s error text will tell us which.)
If Node fetch works too → then it’s likely the token stored in OpenClaw config isn’t the exact token you tested with (extra quotes/whitespace/prefix). Easiest fix is to re-set it via:

openclaw config set channels.discord.token '"PASTE_RAW_TOKEN_ONLY_NO_Bot_PREFIX"' --json
openclaw gateway restart

Paste back the output of the Node fetch test + the first debug/trace log line that mentions “application ID fetch …” and we’ll have a concrete next step.

#

Cool — ipv4_ok + ipv6_ok rules out the common “IPv6 blackhole” problem.

Given:

curl …/oauth2/applications/@me works (valid token + network OK)
OpenClaw still can’t resolve app id
logs don’t show the underlying failure

The two most likely remaining causes are:

OpenClaw is not actually using the same token you tested with (service is reading a different config/user, or token in config has whitespace/quotes)
Node’s fetch in the gateway is timing out/throwing, but your current log level isn’t capturing the cause

A) Check config mismatch (super common with services/containers)

Please run and paste the non-secret parts:

openclaw gateway status --deep

#

Look specifically for lines like “Config (cli)” vs “Config (service)” and confirm they point to the same config file/user.

B) Sanity-check what OpenClaw has stored for the token (without revealing it)

This prints only metadata (length / whitespace / prefix):

openclaw config get channels.discord.token --json | node -e '
let s=""; process.stdin.on("data",d=>s+=d);
process.stdin.on("end",()=>{ const t=JSON.parse(s);
console.log({len:t.length, hasWhitespace:/\\s/.test(t), startsWithBot:t.startsWith("Bot "), dotCount:(t.match(/\\./g)||[]).length});
});'

If hasWhitespace: true or startsWithBot: true, fix it by re-setting the token (token only, no Bot prefix) and restarting.

C) Reproduce the exact fetch OpenClaw does (4s timeout)

This mimics the gateway’s “fetch app id with a 4s timeout” behavior:

#

T='YOUR_TOKEN' node -e '
const ac=new AbortController();
setTimeout(()=>ac.abort(),4000);
fetch("https://discord.com/api/v10/oauth2/applications/@me",{
signal: ac.signal,
headers:{Authorization:"Bot "+process.env.T}
}).then(async r=>console.log("status",r.status, "body", (await r.text()).slice(0,200)))
.catch(e=>console.error("NODE_FETCH_ERR", e.name, e.message));
'

D) If we still don’t see a cause: turn on debug file logs

openclaw config set logging.level '"debug"' --json
openclaw gateway restart

#

openclaw channels logs --channel discord

(Logging docs: https://docs.openclaw.ai/gateway/logging)

If you paste (A) the gateway status --deep config path bits and (C) the Node fetch result, we can usually pinpoint this immediately. If both look clean, it’s very likely a real bug worth adding to: https://github.com/openclaw/openclaw/issues/17080

warped karma Feb 27, 2026, 8:00 PM

#

ipv4 and 6 check output:
ipv4_ok
ipv6_ok

after debug change:
Log file: /tmp/openclaw/openclaw-2026-02-27.log
Channel: discord
2026-02-27T17:31:12.214Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:31:12.217Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 4/10 in 42s
2026-02-27T17:31:54.530Z info {"subsystem":"gateway/channels/discord"} [default] starting provider
2026-02-27T17:31:54.563Z error {"subsystem":"gateway/channels/discord"} [default] channel exited: Failed to resolve Discord application id
2026-02-27T17:31:54.565Z info {"subsystem":"gateway/channels/discord"} [default] auto-restart attempt 5/10 in 88s
2026-02-27T17:33:23.079Z info {"subsystem":"gateway/channels/discord"} [default] starting provider

low basinBOT Feb 27, 2026, 8:01 PM

#

The “starting provider” → “exited” happening in ~20–40ms strongly suggests it’s not even getting to a real HTTP round-trip. That usually happens when the token string OpenClaw reads from config fails normalization (extra quotes, whitespace, or a Bot prefix), so applicationId resolves to undefined immediately.

Do this without revealing the token:

1) Check what the stored token looks like (metadata only)

openclaw config get channels.discord.token --json | node -e '
let s=""; process.stdin.on("data",d=>s+=d);
process.stdin.on("end",()=>{ const t=JSON.parse(s);
console.log({
len: t.length,
hasWhitespace: /\s/.test(t),
startsWithBot: t.startsWith("Bot "),
startsWithQuote: t.startsWith("\"") || t.startsWith("'"),
dotCount: (t.match(/\./g)||[]).length
});

#

});'

If you see hasWhitespace: true or startsWithBot: true or startsWithQuote: true, fix by re-setting the token cleanly:

openclaw config set channels.discord.token '"PASTE_TOKEN_HERE_NO_Bot_PREFIX"' --json
openclaw gateway restart

2) If metadata looks clean, verify Node fetch (OpenClaw uses Node fetch, not curl)

Run locally (don’t paste the token here):

T='YOUR_TOKEN' node -e '
const ac=new AbortController(); setTimeout(()=>ac.abort(),4000);

#

fetch("https://discord.com/api/v10/oauth2/applications/@me",{
signal: ac.signal,
headers:{Authorization:"Bot "+process.env.T}
}).then(async r=>console.log("status",r.status,"body", (await r.text()).slice(0,120)))
.catch(e=>console.error("NODE_FETCH_ERR", e.name, e.message));
'

3) Optional: stop the restart spam while testing

openclaw config set channels.discord.enabled false --json
openclaw gateway restart
# (re-enable after fixing)

Reply with the metadata output from step (1). That will usually make the problem obvious immediately.

warped karma Feb 27, 2026, 8:04 PM

#

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-27.log
Command: /usr/local/Cellar/node@22/22.22.0/bin/node /usr/local/Cellar/node@22/22.22.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 90217)
RPC probe: ok

Listening: 127.0.0.1:18789

{ len: 21, hasWhitespace: false, startsWithBot: false, dotCount: 0 }

NODE_FETCH_ERR TypeError fetch failed

low basinBOT Feb 27, 2026, 8:06 PM

#

This is the smoking gun:

NODE_FETCH_ERR TypeError fetch failed

OpenClaw’s Discord “application id resolution” uses Node’s fetch under the hood. So if Node itself can’t make outbound HTTPS requests, OpenClaw will always die here — even though curl works.

On macOS this is most often one of:

a firewall / network filter (Little Snitch, LuLu, corporate endpoint security) blocking Node specifically
TLS interception / custom root CA (Node doesn’t trust the system keychain by default, so HTTPS fails)

0) Stop the restart spam while debugging

openclaw config set channels.discord.enabled false --json
openclaw gateway restart

1) Get the real Node error (the “cause”)

#

Run (don’t paste token):

T='YOUR_TOKEN' node -e '
const ac=new AbortController(); setTimeout(()=>ac.abort(),4000);
fetch("https://discord.com/api/v10/oauth2/applications/@me",{
signal: ac.signal,
headers:{Authorization:"Bot "+process.env.T}
}).then(async r=>console.log("status",r.status))
.catch(e=>{ console.error("ERR", e); console.error("CAUSE", e.cause); });
'

Also test if it’s “all HTTPS is broken in Node” vs “Discord only”:

node -e 'fetch("https://example.com").then(r=>console.log("example",r.status)).catch(e=>{console.error("example err",e); console.error("cause",e.cause);})'

#

2) What to do depending on what you see

If the cause mentions certificate / UNABLE_TO_VERIFY_LEAF_SIGNATURE / self signed certificate
→ that’s TLS inspection / missing CA trust for Node. Fix is usually NODE_EXTRA_CA_CERTS=... (corp root CA PEM) or adjusting how Node is launched.
If the cause is ETIMEDOUT / ECONNRESET / EHOSTUNREACH
→ very likely a firewall/security tool blocking Node. You’ll need to allow outgoing connections for the Node binary:
/usr/local/Cellar/node@22/22.22.0/bin/node

Once Node fetch works, you can re-enable Discord:

openclaw config set channels.discord.enabled true --json
openclaw gateway restart

Paste the CAUSE ... line (it won’t include your token) and we can point to the exact fix.

warped karma Feb 27, 2026, 8:13 PM

#

ERR TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
[cause]: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}
}
CAUSE Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}

example err TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
[cause]: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}
}
cause Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}

low basinBOT Feb 27, 2026, 8:15 PM

#

Perfect, that error explains everything:

UNABLE_TO_GET_ISSUER_CERT_LOCALLY means Node can’t validate HTTPS certificates on your machine. OpenClaw’s Discord setup uses Node’s fetch, so it fails immediately (and it’ll also fail for any HTTPS call, even https://example.com, which you confirmed).

This is almost always a corporate TLS proxy / custom root CA situation on macOS: curl trusts the macOS Keychain, but Node (by default) uses its own CA bundle.

Fast fix (recommended): make Node use the macOS system cert store

Test in your shell first:

NODE_OPTIONS="--use-system-ca" node -e 'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error(e, e.cause))'

If that prints ok 200, you’re good.

Apply it to the LaunchAgent (so the gateway gets it too)

Quick (not permanent) test for the current login session:

#

launchctl setenv NODE_OPTIONS "--use-system-ca"
openclaw gateway restart
openclaw channels status --probe

If that fixes Discord, make it persistent by adding it to your LaunchAgent plist:

File: ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Add (or extend) this section:

<key>EnvironmentVariables</key>
<dict>
<key>NODE_OPTIONS</key>

#

<string>--use-system-ca</string>
</dict>

Then reload the agent (pick one approach):

launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist

…and restart:

openclaw gateway restart

#

Alternative fix: export your org’s root CA + use NODE_EXTRA_CA_CERTS

If --use-system-ca doesn’t work for some reason, the other standard approach is exporting the proxy/root cert from Keychain to a PEM file and setting NODE_EXTRA_CA_CERTS=/path/to/root.pem in the same LaunchAgent EnvironmentVariables.

Once Node HTTPS works, the Discord “Failed to resolve Discord application id” error should disappear.

If after fixing TLS you still get that error, we’ll re-check the stored bot token (your earlier len: 21, dotCount: 0 looks like the config value might not be the real Discord token).

warped karma Feb 27, 2026, 8:16 PM

#

it did not print 200 lol:
TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
[cause]: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}
} Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}

low basinBOT Feb 27, 2026, 8:18 PM

#

That output means Node can’t trust any HTTPS certs on your Mac:

UNABLE_TO_GET_ISSUER_CERT_LOCALLY

So OpenClaw failing to “resolve Discord application id” is just a symptom — Node fetch() is broken even for https://example.com, so Discord can never start.

--use-system-ca not helping usually means your network is doing TLS inspection and the intercepting root CA is not in the place Node is reading from, or it’s only in your login keychain / not trusted as a root CA.

Fix path that works reliably: add the intercept/root CA to Node via `NODE_EXTRA_CA_CERTS`

1) Find the issuer (so you know which cert to export)

Run:

curl -vI https://example.com 2>&1 | egrep -i "issuer:|subject:|SSL certificate"

If you see something like “Zscaler”, “Cisco Umbrella”, “Cloudflare Gateway”, “Netskope”, etc → yep, TLS inspection.

#

2) Export that root cert from Keychain Access

Keychain Access → search for the issuer name you saw above → select the root certificate → File → Export…
Export as .cer (or .pem if offered).

3) Convert to PEM (if you exported .cer)

openssl x509 -inform der -in ~/Downloads/CorpRoot.cer -out ~/corp-root.pem

4) Test Node HTTPS using that CA

NODE_EXTRA_CA_CERTS=~/corp-root.pem node -e \
'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error(e, e.cause))'

Once this prints ok 200, OpenClaw will be able to fetch Discord’s application id.

5) Make it apply to the LaunchAgent gateway

#

Edit ~/Library/LaunchAgents/ai.openclaw.gateway.plist and add:

<key>EnvironmentVariables</key>
<dict>
<key>NODE_EXTRA_CA_CERTS</key>
<string>/Users/YOU/corp-root.pem</string>
</dict>

Then reload the agent and restart:

launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist
openclaw gateway restart

#

If you paste the issuer/subject lines from the curl -vI output, I can tell you exactly what cert to look for in Keychain.

warped karma Feb 27, 2026, 8:21 PM

#

subject: CN=example.com
issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
SSL certificate verify ok.

low basinBOT Feb 27, 2026, 8:23 PM

#

That curl -vI output is normal public PKI (Cloudflare intermediate) and SSL certificate verify ok, so this is not a corporate MITM/root-CA problem.

What it does mean: your Node process has a broken/empty CA trust store (so it can’t verify any HTTPS, even example.com). OpenClaw’s Discord probe uses Node fetch(), so it dies instantly.

1) First: check if an env var is breaking TLS for Node

Run:

env | egrep 'NODE_OPTIONS|NODE_EXTRA_CA_CERTS|SSL_CERT_FILE|SSL_CERT_DIR' || true

Then try with a completely clean env (this often immediately fixes it):

env -u NODE_OPTIONS -u NODE_EXTRA_CA_CERTS -u SSL_CERT_FILE -u SSL_CERT_DIR \
node -e 'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error(e, e.cause))'

#

2) If that still fails: force Node to use bundled CAs (bypass OpenSSL/system store)

NODE_OPTIONS="--use-bundled-ca" node -e \
'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error(e, e.cause))'

If that prints ok 200, you’ve found the fix: set the same NODE_OPTIONS for the gateway LaunchAgent (in ~/Library/LaunchAgents/ai.openclaw.gateway.plist under EnvironmentVariables), reload, restart.

3) Quick sanity check: does your Node even have bundled roots?

node -p "require('tls').rootCertificates.length"

This should be a big number (100+). If it’s 0, your Node build/install is borked.

4) Pragmatic “just make it work” fix

If the above doesn’t fix it, reinstall Node from the official installer (nodejs.org) or via nvm, and update the LaunchAgent’s Command path (your plist currently hardcodes the Homebrew Node path).

#

Once node fetch https://example.com returns 200, OpenClaw Discord will stop throwing “Failed to resolve Discord application id”.

If you paste the output of (1) and the result of the “clean env” fetch, I can tell which branch you’re on.

warped karma Feb 27, 2026, 8:25 PM

#

step 1 and 2 complete and still getting similar outputs:
TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
[cause]: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}
} Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1697:34)
at TLSSocket.emit (node:events:519:28)
at TLSSocket._finishInit (node:_tls_wrap:1095:8)
at ssl.onhandshakedone (node:_tls_wrap:881:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}
node output: 146

low basinBOT Feb 27, 2026, 8:27 PM

#

Got it — so:

curl verifies the cert chain fine (SSL certificate verify ok)
Node still fails with UNABLE_TO_GET_ISSUER_CERT_LOCALLY
tls.rootCertificates.length = 146 (so Node has a CA bundle, but it still doesn’t trust what it’s seeing)

That combo usually means: Node is not using the same CA bundle that curl/system trust uses, or it’s missing the specific root needed for Cloudflare’s chain on your box.

First, pause the Discord crash loop while we fix TLS

openclaw config set channels.discord.enabled false --json
openclaw gateway restart

Fix: point Node at a CA bundle that definitely works on macOS

Option A (fast): use macOS’s `/etc/ssl/cert.pem`

#

Try:

NODE_EXTRA_CA_CERTS=/etc/ssl/cert.pem node -e \
'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error("fail",e.cause||e))'

If that prints ok 200, you can apply the same env var to the LaunchAgent (so OpenClaw inherits it).

Option B (most reliable): export macOS trusted roots to a PEM file

Create a PEM bundle:

mkdir -p ~/.openclaw
cat \
<(security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain) \
<(security find-certificate -a -p /Library/Keychains/System.keychain) \
> ~/.openclaw/macos-ca.pem

#

Test Node:

NODE_EXTRA_CA_CERTS=~/.openclaw/macos-ca.pem node -e \
'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error("fail",e.cause||e))'

Make it permanent for the Gateway LaunchAgent

Edit ~/Library/LaunchAgents/ai.openclaw.gateway.plist and add:

<key>EnvironmentVariables</key>
<dict>
<key>NODE_EXTRA_CA_CERTS</key>
<string>/Users/YOURUSER/.openclaw/macos-ca.pem</string>
</dict>

#

Reload + restart:

launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist
openclaw gateway restart

Then re-enable Discord:

openclaw config set channels.discord.enabled true --json
openclaw gateway restart
openclaw channels status --probe

If you tell me whether Option A (/etc/ssl/cert.pem) makes Node print ok 200, I can tell you if you can stop there or need the Keychain export route.

warped karma Feb 27, 2026, 8:31 PM

#

option A printed 200 ok! now whaT??

low basinBOT Feb 27, 2026, 8:31 PM

#

Great — that means the fix is simply: make the gateway’s Node process use /etc/ssl/cert.pem as its CA bundle.

1) Make it permanent for the LaunchAgent (recommended)

Edit: ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Inside the top-level <dict> ... </dict> add (or merge with existing EnvironmentVariables):

<key>EnvironmentVariables</key>
<dict>
<key>OPENCLAW_GATEWAY_PORT</key>
<string>18789</string>

<key>NODE_EXTRA_CA_CERTS</key>
<string>/etc/ssl/cert.pem</string>
</dict>

#

(Keep your existing OPENCLAW_GATEWAY_PORT there if it already exists; don’t duplicate keys.)

Then reload + restart:

launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist
openclaw gateway restart

2) Re-enable Discord + verify

openclaw config set channels.discord.enabled true --json
openclaw gateway restart
openclaw channels status --probe

#

You should no longer see “Failed to resolve Discord application id”, and the bot should come online.

If it still fails, the next thing to check is your Discord token value (earlier you had len: 21, dotCount: 0, which is suspiciously short for a bot token), but fix TLS first and re-probe — in most cases Discord just starts working immediately.

warped karma Feb 27, 2026, 8:32 PM

#

zsh: parse error near `\n'

low basinBOT Feb 27, 2026, 8:32 PM

#

That zsh: parse error near \\n'` is just your shell choking on a pasted multiline command / mismatched quotes.

Use these one-liners (safe to paste as-is):

Quick test (Node HTTPS with the working CA bundle)

NODE_EXTRA_CA_CERTS=/etc/ssl/cert.pem node -e 'fetch("https://example.com").then(r=>console.log("ok",r.status)).catch(e=>console.error("fail",e.cause||e))'

Quick “make OpenClaw work right now” (no plist edit yet)

launchctl setenv NODE_EXTRA_CA_CERTS /etc/ssl/cert.pem
openclaw gateway restart
openclaw channels status --probe

If that makes Discord go online, then make it permanent by adding NODE_EXTRA_CA_CERTS=/etc/ssl/cert.pem to ~/Library/LaunchAgents/ai.openclaw.gateway.plist under EnvironmentVariables and reloading the agent.

#

If you paste the exact command you ran that triggered the parse error, I can point out the specific quote/newline that broke it.

warped karma Feb 27, 2026, 8:33 PM

#

is there an automated way i can make this permanent in the CLI rather than editing the .plist file manually ? just ask me what info you need os you can give me the commands

low basinBOT Feb 27, 2026, 8:35 PM

#

Yep — you can do it fully from the CLI. The key thing is: NODE_EXTRA_CA_CERTS has to be in the launchd process environment (not OpenClaw config), because Node’s TLS stack reads it before OpenClaw code runs.

Option 1 (easy, but resets on reboot)

launchctl setenv NODE_EXTRA_CA_CERTS /etc/ssl/cert.pem
openclaw gateway restart

Option 2 (permanent) — patch the LaunchAgent plist via CLI (no manual editing)

This will add the env var to ~/Library/LaunchAgents/ai.openclaw.gateway.plist, then reload it:

PLIST="$HOME/Library/LaunchAgents/ai.openclaw.gateway.plist"

# ensure EnvironmentVariables dict exists
/usr/libexec/PlistBuddy -c "Add :EnvironmentVariables dict" "$PLIST" 2>/dev/null || true

#


# add or update NODE_EXTRA_CA_CERTS
/usr/libexec/PlistBuddy -c "Add :EnvironmentVariables:NODE_EXTRA_CA_CERTS string /etc/ssl/cert.pem" "$PLIST" 2>/dev/null \
|| /usr/libexec/PlistBuddy -c "Set :EnvironmentVariables:NODE_EXTRA_CA_CERTS /etc/ssl/cert.pem" "$PLIST"

# reload the agent
launchctl unload "$PLIST" 2>/dev/null || true
launchctl load "$PLIST"

openclaw gateway restart
openclaw channels status --probe

After that, Node fetch() should work in the gateway, and Discord should get past “resolve application id”.

One extra heads-up: earlier your stored Discord token metadata looked odd (len: 21, dotCount: 0). A real Discord bot token is much longer and usually has 2 dots. If Discord still fails after the TLS fix, we’ll fix the token next with:

#

openclaw config set channels.discord.token '"PASTE_REAL_BOT_TOKEN_HERE"' --json
openclaw gateway restart

warped karma Feb 27, 2026, 8:46 PM

#

i didnt do the config set command yet but this is what i got when i did the --probe:

#

Discord default: disabled, configured, stopped, token:config, error:disabled

low basinBOT Feb 27, 2026, 8:47 PM

#

Can you paste the exact openclaw channels status --probe output you got (feel free to redact anything sensitive)? Right now I’m guessing which failure mode you’re in.

That said: since we proved Node TLS was the real blocker, the next most likely reason you’d still see “Failed to resolve Discord application id” is simply that the token stored in OpenClaw config is not the real bot token.

You already had this earlier:

len: 21, dotCount: 0 for channels.discord.token

A real Discord Bot Token is much longer and usually contains 2 dots. If the gateway is now able to do HTTPS, a wrong token will still surface as the same “Failed to resolve…” error.

Next step (do this now, don’t paste the token in chat)

Set the bot token again (this overwrites whatever’s currently in config):

openclaw config set channels.discord.token '"PASTE_THE_REAL_DISCORD_BOT_TOKEN_HERE"' --json
openclaw config set channels.discord.enabled true --json

#

openclaw gateway restart
openclaw channels status --probe

If it still fails after that, also paste:

openclaw channels logs --channel discord

(Those logs won’t include the token, and they’ll tell us whether it’s auth vs something else.)

#

That output is literally just: Discord is disabled in config, so the gateway won’t even try to start it.

Do these two steps (don’t paste your token in chat):

openclaw config set channels.discord.token '"PASTE_REAL_DISCORD_BOT_TOKEN_HERE"' --json
openclaw config set channels.discord.enabled true --json
openclaw gateway restart
openclaw channels status --probe

If it still fails after re-enabling, paste:

openclaw channels logs --channel discord

(And quick sanity check: a real Discord bot token is long and usually has 2 dots — earlier your stored value looked way too short.)

warped karma Feb 27, 2026, 8:50 PM

#

Discord default: enabled, configured, running, bot:@Shelldon, token:config, intents:content=limited, works

low basinBOT Feb 27, 2026, 8:50 PM

#

Perfect — that’s the “all good” state:

running
bot: @Shelldon
works

The intents: content=limited just means Discord “Message Content Intent” isn’t fully enabled/available (or you’re not verified for full access). It’ll still work for slash commands/mentions, but if you want the bot to reliably read normal message text in guild channels, go to the Discord Developer Portal → your app → Bot → Privileged Gateway Intents → enable Message Content Intent (and restart the gateway after).

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

warped karma Feb 27, 2026, 8:52 PM

#

getting Connection error. message in discord when talking to it

low basinBOT Feb 27, 2026, 8:53 PM

#

If Discord now probes as running … works, then the Discord connection is fine — the “Connection error.” you’re seeing in chat is almost always the model/provider call failing (API key missing, provider outage, baseURL wrong for a local model, etc.). We need the gateway log line that accompanies it.

Do this:

In a terminal:

openclaw logs --follow

Then send one simple DM to the bot in Discord (e.g. “hi”).
Copy/paste the new log lines that appear right when you get “Connection error.” (they should mention something like provider=..., model=..., or a stacktrace). No secrets should be in there, but redact if you see anything token-like.

Quick sanity check (make sure your TLS fix is actually in the service env, not just your shell):

launchctl getenv NODE_EXTRA_CA_CERTS

#

It should print:

/etc/ssl/cert.pem

Post those logs and I’ll tell you exactly which config knob/credential is missing (or if it’s a known provider-side “Connection error.” case).

warped karma Feb 27, 2026, 8:54 PM

#

20:54:28 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=a6bdbda0-6e0b-43ce-89ca-c15c91d3d01b
20:54:29 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=a6bdbda0-6e0b-43ce-89ca-c15c91d3d01b isError=true error=Connection error.
20:54:29 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=a6bdbda0-6e0b-43ce-89ca-c15c91d3d01b sessionId=447852cc-bcbc-4395-8c67-c515711a978c durationMs=19271
20:54:29 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=447852cc-bcbc-4395-8c67-c515711a978c sessionKey=agent:main:discord:direct:251016047765749760 prev=processing new=idle reason="run_completed" queueDepth=0
20:54:29 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=447852cc-bcbc-4395-8c67-c515711a978c totalActive=0
20:54:29 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=a6bdbda0-6e0b-43ce-89ca-c15c91d3d01b sessionId=447852cc-bcbc-4395-8c67-c515711a978c durationMs=19334 aborted=false
20:54:29 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=19338 active=0 queued=0
20:54:29 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:discord:direct:251016047765749760 durationMs=19343 active=0 queued=0

low basinBOT Feb 27, 2026, 8:55 PM

#

Those log lines mean Discord is fine — the agent run is failing when it tries to call your model provider, and the provider error string being surfaced is just "Connection error." (no details yet).

Let’s make it show which provider/model is failing and whether it’s auth/network/TLS:

1) Confirm the gateway service really has the TLS env fix

launchctl getenv NODE_EXTRA_CA_CERTS

Should print:

/etc/ssl/cert.pem

(If it’s empty, the gateway may still be running without the env var and model HTTPS can fail.)

2) Show which model/provider OpenClaw is using + probe auth

#

openclaw models status --probe --plain

Paste that output (it shouldn’t include secrets; redact anything that looks like a key just in case).

This usually immediately reveals:

missing/expired auth profile
a provider baseURL that’s unreachable (LM Studio / Ollama / etc.)
provider returning “Connection error.”

3) If the probe output still isn’t specific, crank logs for one repro

Temporarily:

openclaw config set logging.level '"trace"' --json
openclaw gateway restart
openclaw logs --follow

#

Then send one “hi” to the bot and paste the new lines around the failure (you’ll often get the underlying HTTP/TLS error at trace).

Known gotcha

There’s an open bug where some providers literally return "Connection error." and OpenClaw may not fail over to fallbacks correctly in some versions: https://github.com/openclaw/openclaw/issues/20931
So if models status --probe shows you’re on one of those providers, the practical workaround is “switch primary provider/model or configure fallbacks”.

Post the openclaw models status --probe --plain output and we’ll go straight to the fix.

warped karma Feb 27, 2026, 8:56 PM

#

launchctl getenv NODE_EXTRA_CA_CERTS
/etc/ssl/cert.pem
clip@Calebs-MacBook-Pro ~ % openclaw models status --probe --plain

🦞 OpenClaw 2026.2.26 (bc50708) — Claws out, commit in—let's ship something mildly responsible.

[openclaw] Failed to start CLI: Error: --probe cannot be used with --plain output.
at modelsStatusCommand (file:///usr/local/Cellar/node@22/22.22.0/lib/node_modules/openclaw/dist/models-fnuRRwDK.js:1308:38)
at Object.run (file:///usr/local/Cellar/node@22/22.22.0/lib/node_modules/openclaw/dist/run-main-C4nHOyrc.js:320:10)
at async runCli (file:///usr/local/Cellar/node@22/22.22.0/lib/node_modules/openclaw/dist/run-main-C4nHOyrc.js:395:6)

PS I have my model running on the other computer, is it not reaching that one maybe?

low basinBOT Feb 27, 2026, 8:57 PM

#

The models status error is just CLI flags: --probe and --plain can’t be combined.

Run either:

openclaw models status --probe

or (no live probes):

openclaw models status --plain

On the “Connection error.” part: yep, if your model is running on another computer, this is a very common cause — the Gateway (your Mac running OpenClaw) can only reach it if the model server is listening on the LAN and your OpenClaw config points to the other machine’s IP, not localhost.

#

1) From the Mac running OpenClaw, verify you can reach the model server

Depending on what you’re running:

LM Studio (OpenAI-compatible) usually:

curl -sS http://OTHER_PC_IP:1234/v1/models

Ollama usually:

curl -sS http://OTHER_PC_IP:11434/api/tags

(Replace OTHER_PC_IP + port with your actual server/port.)

If that curl fails, fix it on the model machine first (bind to 0.0.0.0, allow the port through firewall, same network, etc.).

#

2) Then show what OpenClaw thinks your model/provider is

Run and paste the output (no secrets in it):

openclaw models status

Once we see which provider/model is configured, I can tell you the exact config knob to point it at the other computer (base URL / host), and then it should stop replying “Connection error.” in Discord.

warped karma Feb 27, 2026, 8:58 PM

#

curl -sS http://10.119.17.83:11434/api/tags
{"models":[{"name":"qwen2.5-coder:7b","model":"qwen2.5-coder:7b","modified_at":"2026-02-19T13:53:43.0263772-06:00","size":4683087561,"digest":"dae161e27b0e90dd1856c8bb3209201fd6736d8eb66298e75ed87571486f4364","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"7.6B","quantization_level":"Q4_K_M"}},{"name":"llama3.1:8b","model":"llama3.1:8b","modified_at":"2026-02-19T13:53:01.0049721-06:00","size":4920753328,"digest":"46e0c10c039e019119339687c3c1757cc81b9da49709a3b3924863ba87ca666e","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"8.0B","quantization_level":"Q4_K_M"}},{"name":"mistral-small3.2:24b","model":"mistral-small3.2:24b","modified_at":"2026-02-19T11:31:19.4684377-06:00","size":15177384862,"digest":"5a408ab55df5c1b5cf46533c368813b30bf9e4d8fc39263bf2a3338cfa3b895b","details":{"parent_model":"","format":"gguf","family":"mistral3","families":["mistral3"],"parameter_size":"24.0B","quantization_level":"Q4_K_M"}},{"name":"qwen3-coder:30b","model":"qwen3-coder:30b","modified_at":"2026-02-19T11:28:47.7908247-06:00","size":18556700761,"digest":"06c1097efce0431c2045fe7b2e5108366e43bee1b4603a7aded8f21689e90bca","details":{"parent_model":"","format":"gguf","family":"qwen3moe","families":["qwen3moe"],"parameter_size":"30.5B","quantization_level":"Q4_K_M"}}]}%

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : vllm/ollama/mistral-small3.2:24b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAY...4Ev1jqig
ollama effective=models.json:ol...al | models.json=ol...al | source=models.json: ~/.openclaw/agents/main/agent/models.json
vllm effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | vllm:default=sk...al | models.json=VL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

low basinBOT Feb 27, 2026, 8:59 PM

#

Good news: your Mac can reach the other machine’s Ollama (/api/tags worked). So the remaining “Connection error.” is almost certainly just OpenClaw still trying to talk to local Ollama at 127.0.0.1:11434 (the default).

To use Ollama on another host, you need an explicit Ollama provider config with baseUrl pointing at http://10.119.17.83:11434 (docs: https://docs.openclaw.ai/providers/ollama). Note: explicit config disables auto-discovery, so you must list at least one model.

1) Configure OpenClaw to use your remote Ollama (copy/paste)

Pick one model you actually have (from your /api/tags output). Example: qwen2.5-coder:7b

openclaw config set models.providers.ollama --strict-json '
{
baseUrl: "http://10.119.17.83:11434",
apiKey: "ollama-local",
api: "ollama",
models: [
{
id: "qwen2.5-coder:7b",

#

name: "Qwen2.5 Coder 7B",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,
maxTokens: 8192 * 10,
},
],
}'

2) Point your agent at that model + restart

openclaw config set agents.defaults.model.primary '"ollama/qwen2.5-coder:7b"' --json
openclaw gateway restart

#

3) Verify

openclaw models list | rg "ollama|qwen2.5-coder"
openclaw models status

If you still get “Connection error.” after this, paste the output of:

openclaw models status

…and I’ll tell you exactly what it’s still trying to use (wrong provider, wrong model id, etc.).

warped karma Feb 27, 2026, 9:00 PM

#

I want to use mistral cna you give me the config for this one

low basinBOT Feb 27, 2026, 9:01 PM

#

Yep — you are reaching the other computer (your curl http://10.119.17.83:11434/api/tags proves it). The “Connection error.” is because OpenClaw is still configured to call the wrong provider/model:

Default: vllm/ollama/mistral-small3.2:24b is parsed as provider vllm, model id ollama/mistral-small3.2:24b (because OpenClaw splits on the first /).
You almost certainly meant: ollama/mistral-small3.2:24b.

Also, Ollama-on-another-machine requires setting models.providers.ollama.baseUrl to that host (docs: https://docs.openclaw.ai/providers/ollama).

Run these commands (copy/paste; no secrets involved):

1) Point Ollama provider at the other computer

openclaw config set models.providers.ollama --strict-json '{"baseUrl":"http://10.119.17.83:11434","apiKey":"ollama-local","api":"ollama","models":[{"id":"mistral-small3.2:24b","name":"mistral-small3.2 24B","reasoning":false,"input":["text"],"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0},"contextWindow":8192,"maxTokens":81920}]}'

2) Fix the default model to use the ollama provider (not vllm)

#

openclaw config set agents.defaults.model.primary '"ollama/mistral-small3.2:24b"' --json

3) Restart + verify

openclaw gateway restart
openclaw models status

After this, openclaw models status should show Default: ollama/mistral-small3.2:24b (not vllm/...), and the Discord “Connection error.” should stop.

If it still errors, paste the new openclaw models status output and we’ll see what provider it’s actually trying to call.

#

If you want to use Mistral via your remote Ollama box (the one at 10.119.17.83:11434), here’s the config.

Option A) CLI commands (recommended)

Copy/paste:

# Point the ollama provider at the OTHER machine (explicit config)
openclaw config set models.providers.ollama --strict-json '{
baseUrl: "http://10.119.17.83:11434",
apiKey: "ollama-local",
api: "ollama",
models: [
{
id: "mistral-small3.2:24b",
name: "Mistral Small 3.2 24B",
reasoning: false,

#

input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,
maxTokens: 81920,
},
],
}'

# IMPORTANT: provider/model is split on the first "/" — this must start with "ollama/"
openclaw config set agents.defaults.model.primary '"ollama/mistral-small3.2:24b"' --json

openclaw gateway restart

Option B) Raw JSON5 snippet (if you prefer file editing)

In ~/.openclaw/openclaw.json:

#

{
models: {
providers: {
ollama: {
baseUrl: "http://10.119.17.83:11434",
apiKey: "ollama-local",
api: "ollama",
models: [
{
id: "mistral-small3.2:24b",
name: "Mistral Small 3.2 24B",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,

#

maxTokens: 81920,
},
],
},
},
},
agents: {
defaults: {
model: { primary: "ollama/mistral-small3.2:24b" },
},
},
}

After restarting, run:

#

openclaw models status

If you tell me whether you want Mistral via Ollama (what you’re doing now) or Mistral via a vLLM/OpenAI-compatible server, I can give the exact config for that too (different api + baseUrl).

warped karma Feb 27, 2026, 9:04 PM

#

⚠️ Agent failed before reply: Model context window too small (8192 tokens). Minimum is 16000.
Logs: openclaw logs --follow

#

please fix

low basinBOT Feb 27, 2026, 9:05 PM

#

That error is coming from the model config we set: it currently says your Ollama Mistral model has a context window of 8192, but OpenClaw’s agent requires ≥ 16000 (tool schemas + system prompt are big), so it refuses to run.

Fix = bump the model’s contextWindow in the Ollama provider entry to 16384 (or higher) and restart.

CLI fix (recommended)

# bump context window for your configured ollama model entry
openclaw config set models.providers.ollama.models[0].contextWindow 16384 --strict-json
openclaw config set models.providers.ollama.models[0].maxTokens 4096 --strict-json

openclaw gateway restart

(If models[0] isn’t the Mistral entry because you’ve added more models, run openclaw config get models.providers.ollama and tell me what index Mistral is at, and I’ll give the exact command.)

Important note

This change only tells OpenClaw “you have 16k context”. The underlying Ollama model/server also has to actually support it, otherwise you’ll later hit a “context length exceeded” type error. To sanity-check the model’s reported context on the Ollama box:

#

curl -sS http://10.119.17.83:11434/api/show -d '{"name":"mistral-small3.2:24b"}' | head

Once contextWindow >= 16000, the “Agent failed before reply” block should go away.

#

Yep — you just need to tell OpenClaw that the Mistral Ollama model has a ≥16k context window (right now it’s set to 8192, so OpenClaw refuses to run).

Run these:

1) Confirm Mistral is `models[0]` (so we edit the right entry)

openclaw config get models.providers.ollama.models

You should see an entry with:
id: "mistral-small3.2:24b"

2) Set contextWindow to 16384 and restart

(assuming Mistral is the first entry, i.e. models[0])

openclaw config set models.providers.ollama.models[0].contextWindow 16384 --strict-json

#

openclaw config set models.providers.ollama.models[0].maxTokens 4096 --strict-json
openclaw gateway restart

3) Verify

openclaw models status

If mistral-small3.2:24b is not models[0], tell me what index it is (paste the output of step 1), and I’ll give you the exact one-liner with the correct [index].

warped karma Feb 27, 2026, 9:06 PM

#

zsh: no matches found: models.providers.ollama.models[0].contextWindow
zsh: no matches found: models.providers.ollama.models[0].maxTokens

low basinBOT Feb 27, 2026, 9:06 PM

#

That’s just zsh globbing on the [...] in the config path. Quote the path (or use noglob) and it’ll work.

Run these:

openclaw config set 'models.providers.ollama.models[0].contextWindow' 16384 --strict-json
openclaw config set 'models.providers.ollama.models[0].maxTokens' 4096 --strict-json
openclaw gateway restart

Alternative (same thing):

noglob openclaw config set models.providers.ollama.models[0].contextWindow 16384 --strict-json
noglob openclaw config set models.providers.ollama.models[0].maxTokens 4096 --strict-json

#

If Mistral isn’t at index 0, run:

openclaw config get models.providers.ollama.models

and tell me which index contains id: "mistral-small3.2:24b" and I’ll give the exact commands for that index.

warped karma Feb 27, 2026, 9:06 PM

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/mistral-small3.2:24b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAY...4Ev1jqig
ollama effective=models.json:ol...al | models.json=ol...al | source=models.json: ~/.openclaw/agents/main/agent/models.json
vllm effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | vllm:default=sk...al | models.json=VL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

low basinBOT Feb 27, 2026, 9:06 PM

#

Nice — that output means OpenClaw is now correctly set to:

Default: ollama/mistral-small3.2:24b

So the “Minimum is 16000” config gate should be gone.

Next: test an actual reply

Restart (just to be sure everything reloaded):

openclaw gateway restart

DM the bot in Discord: hi

If it still fails, there are 2 common follow-ups

A) You still see “Model context window too small …”

#

→ paste the exact error + run:

openclaw logs --follow

B) You see “context length exceeded” / similar (different error)
→ that means Ollama itself is running the model with <16k context. Check what Ollama reports:

curl -sS http://10.119.17.83:11434/api/show -d '{"name":"mistral-small3.2:24b"}' | head -80

Paste that snippet and we’ll adjust.

If the bot replies now, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed.

warped karma Feb 27, 2026, 9:12 PM

#

he responded. I asked a simple yes no question and it took him like 3 minutes to respond is that normal for self hosted?

low basinBOT Feb 27, 2026, 9:13 PM

#

3 minutes for a yes/no is not normal if everything’s healthy — but it can be normal for self‑hosted if any of these are true:

The model is huge / slow on that machine (your default is mistral-small3.2:24b, which is heavy; Q4 on consumer hardware can be painfully slow).
It’s running on another computer over the network (adds some latency, but usually seconds, not minutes).
Ollama is CPU-bound / out of VRAM and swapping, or the box is busy.
Long context: once the conversation grows, even simple questions take longer because it’s processing a lot of tokens.

Quick checks (fastest way to pinpoint)

On the Mac (OpenClaw host), time a raw Ollama call:

time curl -sS http://10.119.17.83:11434/api/generate \
-d '{"model":"mistral-small3.2:24b","prompt":"Answer only YES or NO: Is 2+2=4?","stream":false}' \
| head -c 200

On the Ollama machine, check if it’s GPU/CPU and how loaded it is:

#

ollama ps

Practical fix

If you want snappy chat, switch to a smaller model (e.g. your qwen2.5-coder:7b or llama3.1:8b) for daily convo, and keep the 24B model for “heavy” tasks.

Example:

openclaw config set agents.defaults.model.primary '"ollama/llama3.1:8b"' --json
openclaw gateway restart

If you paste:

what hardware the Ollama box is (CPU + GPU + RAM), and
output of ollama ps
…I can tell you what kind of speed to expect and which model will feel “instant” on that setup.

warped karma Feb 27, 2026, 9:15 PM

#

ollama output: mistral-small3.2:24b 5a408ab55df5 19 GB 58%/42% CPU/GPU 16384 2 minutes from now

low basinBOT Feb 27, 2026, 9:16 PM

#

3 minutes is not “normal” in general, but it is totally plausible with your current setup.

Your ollama ps line explains it:

mistral-small3.2:24b is 19 GB
58%/42% CPU/GPU means it doesn’t fit fully in VRAM, so a big chunk runs on CPU → very slow.
… 2 minutes from now means the model is going to unload soon; if you hit it after unload, the next request has to reload 19 GB first (can easily add 30–120s).

How to make it faster

Use a smaller default model for chat (7B/8B), and keep the 24B model for heavy stuff.

You already have llama3.1:8b and qwen2.5-coder:7b on that Ollama box — those will be dramatically faster.

Keep the model loaded longer on the Ollama host (so you don’t pay reload time). Ollama supports this via keep-alive (env/API). If you tell me whether Ollama is running as an app on macOS / systemd on Linux / Windows, I’ll give the exact one-liner to set it.
If you really want the 24B model to be “snappy”, you generally need a GPU with enough VRAM to get close to 100% GPU in ollama ps (or use a smaller / more aggressively quantized model).

If you paste the Ollama machine specs (CPU, GPU, RAM), I can recommend which of your installed models will feel “instant” and what kind of tokens/sec you should expect.

warped karma Feb 27, 2026, 9:17 PM

#

this was the output for the time curl {"model":"mistral-small3.2:24b","created_at":"2026-02-27T21:15:56.6224343Z","response":"YES","done":true,"done_reason":"stop","context":[17,4568,1584,42301,2784,29121,1032,1051,1046,1050,1044,1261,435curl -sS http://10.119.17.83:11434/api/generate -d 0.01s user 0.01s system 0% cpu 9.279 total
head -c 200 0.00s user 0.00s system 0% cpu 9.278 total

low basinBOT Feb 27, 2026, 9:17 PM

#

That’s actually a great sign: the raw Ollama call returned in ~9.3s end-to-end. So the 3 minute Discord delay isn’t “the model is slow” — it’s something else around OpenClaw (queueing / retry / model unload+reload / long context / streaming edits).

Two quick notes from what you pasted:

Your terminal output got mangled because time + curl + the JSON response all printed together. But the important bit is the timing: ~9s.
9s for a YES/NO on a 24B model over LAN is still kinda slow-ish, but nowhere near 3 minutes.

Let’s pinpoint the 3-minute delay

1) Check if the model is constantly unloading

Your ollama ps showed “2 minutes from now”. If you ask after it unloads, the next prompt pays a big reload cost.

On the Ollama host, increase keep-alive (pick one):

easiest: set the server env var OLLAMA_KEEP_ALIVE (exact command depends on whether that host is macOS app / Linux systemd / Windows). Tell me which OS the Ollama host is and I’ll give the exact one-liner.

2) Check whether OpenClaw is queueing or retrying

On the Mac running OpenClaw, run:

#

openclaw logs --follow

Then ask the bot one short question again and look for:

multiple retries to the model provider
a long gap between “received message” and “embedded run agent start”
anything like “cooldown”, “retry”, “timeout”, “queueDepth”

If you paste ~20 lines around the run (from “received message” through the error/success), we can tell exactly where the time went.

Quick pragmatic improvement

If you want “instant” chat while keeping Mistral for heavier tasks, set your default to an 8B model:

openclaw config set agents.defaults.model.primary '"ollama/llama3.1:8b"' --json

#

openclaw gateway restart

(And you can switch back to Mistral when needed.)

One question: what OS is the Ollama host (the 10.119.17.83 machine)? macOS/Linux/Windows?

warped karma Mar 1, 2026, 5:05 AM

#

Where are the character soul and identity files located typically on Mac?

low basinBOT Mar 1, 2026, 5:06 AM

#

On macOS, those live in your agent workspace directory.

Default workspace path:

~/.openclaw/workspace/
If you’re using a non-default profile: ~/.openclaw/workspace-<profile>/

So you’ll typically find:

~/.openclaw/workspace/SOUL.md
~/.openclaw/workspace/IDENTITY.md

To confirm what your active workspace is, check your config:

openclaw config get agents.defaults.workspace

Docs (includes the full “workspace file map” for SOUL.md, IDENTITY.md, etc.):
https://docs.openclaw.ai/concepts/agent-workspace

warped karma Mar 1, 2026, 5:08 AM

#

I’m getting this error when asking the bot to do initial setup:

I apologize, but I was unable to locate the files WORKFLOW_AUTO.md and memory/2026-02-28.md in the specified directory. Could you please verify the file paths or provide the correct locations for these files? This will help me proceed with the initial setup for OpenClaw and ensure that the identity, user, and soul files are set up appropriately.

low basinBOT Mar 1, 2026, 5:08 AM

#

That message isn’t a “Discord setup” problem — it’s your agent prompt looking for workspace files that don’t exist.

A couple key points:

SOUL.md, IDENTITY.md, USER.md, AGENTS.md normally live in your workspace (default on macOS: ~/.openclaw/workspace/).
memory/YYYY-MM-DD.md is just the daily log file under workspace/memory/.
WORKFLOW_AUTO.md is not a standard OpenClaw bootstrap file — it’s coming from some custom workflow/prompt you’re using. You can either remove that requirement, or create a placeholder file.

Fix (recommended): let OpenClaw seed the workspace files

Confirm your workspace path:

openclaw config get agents.defaults.workspace

(if it prints nothing, default is ~/.openclaw/workspace)

Seed missing defaults (creates files if missing, doesn’t overwrite existing):

#

openclaw setup

If the agent still complains about those exact filenames

That means your instructions explicitly reference them.

For the memory file: create the folder + a daily file if you want:

mkdir -p ~/.openclaw/workspace/memory
touch ~/.openclaw/workspace/memory/2026-02-28.md

For WORKFLOW_AUTO.md: either remove the reference from your workspace instructions, or create an empty placeholder in the workspace:

touch ~/.openclaw/workspace/WORKFLOW_AUTO.md

#

If you paste the output of:

ls -la ~/.openclaw/workspace

(and whether you’re using a custom profile/workspace), I can tell you exactly which file is missing and where it should go.

warped karma Mar 2, 2026, 7:56 PM

#

workspace location:
/Users/clip/.openclaw/workspace

setup output:
Config OK: ~/.openclaw/openclaw.json
Workspace OK: ~/.openclaw/workspace
Sessions OK: ~/.openclaw/agents/main/sessions

Let me know next steps

low basinBOT Mar 2, 2026, 8:01 PM

#

That specific failure happens very early in the Discord provider startup: OpenClaw tries to call Discord’s API to fetch your application id (/oauth2/applications/@me). If that request fails (bad token / wrong token type / network / timeout), the channel stops and you see:

Failed to resolve Discord application id

Next steps I’d do (in this order):

Confirm versions (important)

openclaw --version
node --version

Get a more informative probe result (JSON includes HTTP status/error)

openclaw channels status --probe --timeout 30000 --json

Paste the discord section (redact any token strings if they appear).

#

Verify the exact endpoint that’s failing (don’t paste the token)
From the same machine where the gateway runs:

curl -i -H "Authorization: Bot <YOUR_TOKEN>" https://discord.com/api/v10/users/@me
curl -i -H "Authorization: Bot <YOUR_TOKEN>" https://discord.com/api/v10/oauth2/applications/@me

Tell me just the HTTP status codes (200/401/403/timeout).

Quick sanity checks

Make sure you used the Bot Token (Developer Portal → Bot → Reset Token), not “Client Secret”.
If you recently reset the token, ensure your config has the new token and then:

openclaw gateway restart

If curl is 200 but OpenClaw still fails, it’s likely a Node/network edge case (there are a couple open bug reports around this). In that case, please share:

#

openclaw channels logs --channel discord --lines 200

…and we can compare it to the known issues and decide whether to escalate to a GitHub issue with your probe JSON.

Docs refs:

warped karma Mar 2, 2026, 8:06 PM

#

low basin If you paste the output of: ```bash ls -la ~/.openclaw/workspace ``` (and whethe...

you are calling an old message, please respond to this one i am replying to:

workspace location:
/Users/clip/.openclaw/workspace

setup output:
Config OK: ~/.openclaw/openclaw.json
Workspace OK: ~/.openclaw/workspace
Sessions OK: ~/.openclaw/agents/main/sessions

Let me know next steps

low basinBOT Mar 2, 2026, 8:06 PM

#

Your workspace/config setup looks fine — this error is purely the Discord channel failing its startup probe (it can’t fetch the bot’s application id from https://discord.com/api/v10/oauth2/applications/@me).

Next steps (please run + paste outputs, don’t paste your token):

Versions

openclaw --version
node --version

Confirm the gateway is actually running + reachable

openclaw status
openclaw gateway status

Get the detailed Discord probe info (best signal)

#

openclaw channels status --probe --timeout 30000 --json

Paste the discord part.

Grab the Discord channel logs around the crash

openclaw channels logs --channel discord --lines 200

Sanity-check the token locally (share only the HTTP status codes you get)

curl -i -H "Authorization: Bot <TOKEN>" https://discord.com/api/v10/users/@me
curl -i -H "Authorization: Bot <TOKEN>" https://discord.com/api/v10/oauth2/applications/@me

What we’re looking for:

#

If either curl returns 401/403 → token is wrong (common: not the Bot Token, or token got reset but config still has the old one).
If curl is 200/200 but OpenClaw still fails → likely a network/proxy/TLS/fetch edge case or an OpenClaw bug; the --json probe + logs will tell us which.

Docs ref (same flow): https://docs.openclaw.ai/channels/troubleshooting and https://docs.openclaw.ai/channels/discord

warped karma Mar 2, 2026, 8:09 PM

#

im not having the discord application id error anymore you are calling old conversations that have already been resolved

low basinBOT Mar 2, 2026, 8:10 PM

#

Got it — thanks for the correction. If the “Failed to resolve Discord application id” error is gone, we’re past that blocker.

What do you want to do next: (a) get DMs working (pairing), (b) allow the bot to talk in a server channel, or (c) something else?

If you’re at the “now make it usable” stage, the usual next steps are:

Confirm Discord is actually up now:

openclaw channels status --probe

Pair DMs (if you haven’t yet):

DM your bot on Discord → it should send a pairing code
Then approve it:

openclaw pairing list discord

#good bot

1) Turn on debug file logs (so we can see why app-id resolution fails)

2) Test “curl works but Node fetch fails” (common culprit: IPv6 or TLS/CA)

A) Check config mismatch (super common with services/containers)

B) Sanity-check what OpenClaw has stored for the token (without revealing it)

C) Reproduce the exact fetch OpenClaw does (4s timeout)

D) If we still don’t see a cause: turn on debug file logs

1) Check what the stored token looks like (metadata only)

2) If metadata looks clean, verify Node fetch (OpenClaw uses Node fetch, not curl)

3) Optional: stop the restart spam while testing

0) Stop the restart spam while debugging

1) Get the real Node error (the “cause”)

2) What to do depending on what you see

Fast fix (recommended): make Node use the macOS system cert store

Apply it to the LaunchAgent (so the gateway gets it too)

Alternative fix: export your org’s root CA + use NODE_EXTRA_CA_CERTS

Fix path that works reliably: add the intercept/root CA to Node via NODE_EXTRA_CA_CERTS

1) Find the issuer (so you know which cert to export)

2) Export that root cert from Keychain Access

3) Convert to PEM (if you exported .cer)

4) Test Node HTTPS using that CA

5) Make it apply to the LaunchAgent gateway

1) First: check if an env var is breaking TLS for Node

2) If that still fails: force Node to use bundled CAs (bypass OpenSSL/system store)

3) Quick sanity check: does your Node even have bundled roots?

4) Pragmatic “just make it work” fix

First, pause the Discord crash loop while we fix TLS

Fix: point Node at a CA bundle that definitely works on macOS

Option A (fast): use macOS’s /etc/ssl/cert.pem

Option B (most reliable): export macOS trusted roots to a PEM file

Make it permanent for the Gateway LaunchAgent

1) Make it permanent for the LaunchAgent (recommended)

2) Re-enable Discord + verify

Quick test (Node HTTPS with the working CA bundle)

Quick “make OpenClaw work right now” (no plist edit yet)

Option 1 (easy, but resets on reboot)

Option 2 (permanent) — patch the LaunchAgent plist via CLI (no manual editing)

Next step (do this now, don’t paste the token in chat)

1) Confirm the gateway service really has the TLS env fix

2) Show which model/provider OpenClaw is using + probe auth

3) If the probe output still isn’t specific, crank logs for one repro

Known gotcha

1) From the Mac running OpenClaw, verify you can reach the model server

2) Then show what OpenClaw thinks your model/provider is

1) Configure OpenClaw to use your remote Ollama (copy/paste)

2) Point your agent at that model + restart

3) Verify

1) Point Ollama provider at the other computer

2) Fix the default model to use the ollama provider (not vllm)

3) Restart + verify

Option A) CLI commands (recommended)

Option B) Raw JSON5 snippet (if you prefer file editing)

CLI fix (recommended)

Important note

1) Confirm Mistral is models[0] (so we edit the right entry)

2) Set contextWindow to 16384 and restart

3) Verify

Next: test an actual reply

If it still fails, there are 2 common follow-ups

Quick checks (fastest way to pinpoint)

Practical fix

How to make it faster

Let’s pinpoint the 3-minute delay

1) Check if the model is constantly unloading

2) Check whether OpenClaw is queueing or retrying

Quick pragmatic improvement

Fix (recommended): let OpenClaw seed the workspace files

If the agent still complains about those exact filenames

Fix path that works reliably: add the intercept/root CA to Node via `NODE_EXTRA_CA_CERTS`

Option A (fast): use macOS’s `/etc/ssl/cert.pem`

1) Confirm Mistral is `models[0]` (so we edit the right entry)