Agent breaks gateway every time it tries to change something in config | Friends of the Crustacean 🦞🤝 | Page 1

mental fable Mar 7, 2026, 1:58 AM

#

wihtout fail, my agent breaks the gateway anytiem it tries to change something meaningful. Most recent was a simple heartbeat change. just destroys it every time.

also, it has been completely useless in terms of "intelligence" for the past 3 days. I dont know what I am doing wrong.

scenic frostBOT Mar 7, 2026, 1:58 AM

#

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

mental fable Mar 7, 2026, 1:59 AM

#

🦞 OpenClaw 2026.3.2 (85377a2) — Open source means you can see exactly how I judge your config.

│
◇ Config ───────────────────────────────────────────────────╮
│ │
│ Config invalid; doctor will run with best-effort config. │
│ │
├────────────────────────────────────────────────────────────╯
│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.imessage.groupPolicy is "allowlist" but groupAllowFrom is empty — this │
│ channel does not fall back to allowFrom, so all group messages will be silently │
│ dropped. Add sender IDs to channels.imessage.groupAllowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
Config invalid
File: ~/.openclaw/openclaw.json
Problem:

agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

Run: openclaw doctor --fix
Restarted LaunchAgent: gui/501/ai.openclaw.gateway
Timed out after 60s waiting for gateway port 18789 to become healthy.
Gateway process is running but port 18789 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=33679
Gateway port 18789 status: free.
Gateway restart timed out after 60s waiting

violet echoBOT Mar 7, 2026, 2:01 AM

#

If any “meaningful change” bricks the gateway, 90% of the time it’s one of these:

the gateway is crashing on startup because config/state became invalid (bad JSON5, wrong key, partial write), or
you’re editing one config path, but the daemon/service is running with a different config (Config (cli) vs Config (service)), so things get weird fast.

To stop guessing, can you paste the output of these (in order)?

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw doctor

And then (this is the money one) grab the error right when it “destroys it”:

#

openclaw logs --follow

If the gateway is so dead that openclaw logs can’t attach, the FAQ suggests tailing the latest file log in /tmp/openclaw/… (the “First 60 seconds if something’s broken” section):
https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken
Deep runbook: https://docs.openclaw.ai/gateway/troubleshooting

Two quick clarifiers that will help a lot:

When you say “breaks the gateway”, do you mean process exits (crash), or it stays running but RPC probe fails / UI says unauthorized / reconnect loop?
What exactly was the “heartbeat change”? (editing HEARTBEAT.md in the workspace vs changing heartbeat config via openclaw config …)

On the “intelligence has been useless for 3 days” part: that’s usually model/auth/fallback (rate limits, “all models failed”, wrong default model, provider returning 429, etc.). openclaw models status + the log snippet around a “dumb” reply will usually make the cause obvious—paste that and we can nail it down quickly.

#

That output explains exactly why the gateway “dies”:

Your config is invalid, and the gateway refuses to boot with it.
Specifically: agents.defaults.heartbeat.target is set to channel:1469389732055351451, but target is not a Discord channel id.
When the gateway can’t parse/validate config, it can end up in a crash loop / startup hang, which is why the LaunchAgent restart times out and port 18789 stays free.

Per the heartbeat docs, target must be one of:

"none" (default)
"last"
or a channel name like "discord", "telegram", etc.

And if you want a specific destination, you set to separately. Docs: https://docs.openclaw.ai/gateway/heartbeat

Quick recovery (get the gateway back up)

Run:

#

openclaw config set agents.defaults.heartbeat.target '"none"' --json
openclaw gateway restart

That should make the config valid again and let the gateway bind to 18789.

If you actually want heartbeats to post into a Discord channel

Use:

openclaw config set agents.defaults.heartbeat.target '"discord"' --json
openclaw config set agents.defaults.heartbeat.to '"channel:1469389732055351451"' --json
openclaw gateway restart

(Assuming 1469389732055351451 is the Discord channel ID you intended.)

#

Also: that iMessage warning can explain “it’s useless”

Doctor is also warning:

channels.imessage.groupPolicy is "allowlist" but groupAllowFrom is empty → all iMessage group messages get silently dropped

So if you’ve been “testing intelligence” via iMessage group chats, it may literally be ignoring everything.

If it still doesn’t bind after fixing `heartbeat.target`

Paste the first ~30 lines after restart from:

openclaw logs --follow

Glad you posted doctor output — this one’s a clean config-key mixup, and it’s totally consistent with “breaks every time it changes something meaningful”.

If the fix works, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

mental fable Mar 7, 2026, 2:04 AM

#

Run: openclaw doctor --fix
Invalid config at /Users/willdoylejarvis/.openclaw/openclaw.json:\n- agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

🦞 OpenClaw 2026.3.2 (85377a2) — You had me at 'openclaw gateway start.'

│
◇ Config ───────────────────────────────────────────────────╮
│ │
│ Config invalid; doctor will run with best-effort config. │
│ │
├────────────────────────────────────────────────────────────╯
│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.imessage.groupPolicy is "allowlist" but groupAllowFrom is empty — this │
│ channel does not fall back to allowFrom, so all group messages will be silently │
│ dropped. Add sender IDs to channels.imessage.groupAllowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
Config invalid
File: ~/.openclaw/openclaw.json
Problem:

agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

Run: openclaw doctor --fix
Restarted LaunchAgent: gui/501/ai.openclaw.gateway

#

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

agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

Run: openclaw doctor --fix
Restarted LaunchAgent: gui/501/ai.openclaw.gateway
Timed out after 60s waiting for gateway port 18789 to become healthy.
Gateway process is running but port 18789 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=36813
Gateway port 18789 status: free.
Gateway restart timed out after 60s waiting for health checks.
willdoylejarvis@Wills-Mac-mini ~ %

violet echoBOT Mar 7, 2026, 2:05 AM

#

doctor --fix can’t fix this one automatically because it’s not a “repairable” state — it’s asking you to choose a valid value.

Right now your config literally contains:

agents.defaults.heartbeat.target = "channel:1469389732055351451" → invalid, so the gateway won’t start cleanly.

Fix it (pick one)

Option A (safest): disable heartbeat delivery so the gateway boots

openclaw config set agents.defaults.heartbeat.target '"none"' --strict-json
openclaw config validate
openclaw gateway restart

Option B: deliver to “whoever you last talked to”

#

openclaw config set agents.defaults.heartbeat.target '"last"' --strict-json
openclaw config validate
openclaw gateway restart

Option C: deliver to a specific Discord channel

Heartbeat target must be "discord" (the channel type), and the destination goes in to:

openclaw config set agents.defaults.heartbeat.target '"discord"' --strict-json
openclaw config set agents.defaults.heartbeat.to '"channel:1469389732055351451"' --strict-json
openclaw config validate
openclaw gateway restart

Docs for this exact split (target vs to): https://docs.openclaw.ai/gateway/heartbeat

#

If `openclaw config set ...` refuses to run

Then just open the file it printed (/Users/willdoylejarvis/.openclaw/openclaw.json) and manually change/remove the bad line (heartbeat.target: "channel:..."). After that:

openclaw config validate
openclaw gateway restart

Once the gateway is up again, we can tackle the “intelligence useless” part — but first we need it booting, and this invalid heartbeat target is the hard blocker.

#

Yep — you’re still in the exact same loop because nothing has changed in the config yet. doctor --fix is restarting the LaunchAgent, but it cannot guess a correct heartbeat target for you, so the config stays invalid and the gateway keeps failing to bind to 18789.

You need to do one of these once, then restart.

Do this now (copy/paste)

This is the fastest “get me unbricked” path:

openclaw config set agents.defaults.heartbeat.target '"none"' --strict-json
openclaw config validate
openclaw gateway restart

If that works, the gateway should come up immediately.

If that command errors (because config is too broken)

Then edit the file directly:

#

Open:

open ~/.openclaw/openclaw.json

Find the line with:

agents: { defaults: { heartbeat: { target: "channel:1469389732055351451" } } }

Change it to either:

target: "none" (safe), or
target: "last", or
target: "discord" + move the channel:... into to

Then:

#

openclaw config validate
openclaw gateway restart

One question

Did you try openclaw config set ... already? If yes, paste the output/error from that command — that’ll tell us whether it’s failing to write, or writing to a different config path than the LaunchAgent uses.

mental fable Mar 7, 2026, 2:07 AM

#

violet echo 1) Open: ```bash open ~/.openclaw/openclaw.json ``` 2) Find the line with: ```j...

this did nothing

violet echoBOT Mar 7, 2026, 2:08 AM

#

“open ~/.openclaw/openclaw.json” is the likely culprit here.

On macOS, open just asks LaunchServices to open the file in a GUI app. If you’re SSH’d into the Mac mini (or there’s no GUI session), it can literally do nothing.

Let’s make this deterministic and verify what the config actually says.

1) Confirm which config file OpenClaw is using

openclaw config file

2) See the current bad value (no guessing)

openclaw config get agents.defaults.heartbeat.target

If it still prints channel:1469389732055351451, fix it via CLI (this works even when the gateway is down):

#

3) Force it to a valid value

openclaw config set agents.defaults.heartbeat.target '"none"' --strict-json
openclaw config get agents.defaults.heartbeat.target
openclaw config validate
openclaw gateway restart

If `openclaw config set` errors, paste that error

Then we’ll do a direct file edit with a terminal editor:

nano ~/.openclaw/openclaw.json

(And yes: you must save in nano: Ctrl+O, Enter, Ctrl+X.)

#

Paste outputs from steps (1) + (2) + (3) if it still won’t come up. That will tell us immediately whether you edited the wrong file, the write isn’t sticking, or something else is re-introducing the bad value.

mental fable Mar 7, 2026, 2:08 AM

#

willdoylejarvis@Wills-Mac-mini ~ % openclaw config file
Invalid config at /Users/willdoylejarvis/.openclaw/openclaw.json:\n- agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

🦞 OpenClaw 2026.3.2 (85377a2) — No $999 stand required.

│
◇ Config ───────────────────────────────────────────────────╮
│ │
│ Config invalid; doctor will run with best-effort config. │
│ │
├────────────────────────────────────────────────────────────╯
│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.imessage.groupPolicy is "allowlist" but groupAllowFrom is empty — this │
│ channel does not fall back to allowFrom, so all group messages will be silently │
│ dropped. Add sender IDs to channels.imessage.groupAllowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
Config invalid
File: ~/.openclaw/openclaw.json
Problem:

agents.defaults.heartbeat.target: unknown heartbeat target: channel:1469389732055351451

Run: openclaw doctor --fix

violet echoBOT Mar 7, 2026, 2:09 AM

#

Got it — that output tells us something important:

openclaw config … is refusing to run while the config is invalid (it validates up front, then bails and tells you to run Doctor). So we can’t use openclaw config set to repair this one until the file is manually fixed.

So the fix path is: edit the JSON5 file directly once, then the CLI tools work again.

Fix it via terminal editor (works over SSH)

Run:

nano /Users/willdoylejarvis/.openclaw/openclaw.json

In nano:

Press Ctrl+W (search)
Type channel:1469389732055351451 (or just heartbeat.target) and press Enter
Change the value from:

#

target: "channel:1469389732055351451"

to either:

target: "none"

(or "last" if you want deliveries to your last chat)

Save: Ctrl+O then Enter
Exit: Ctrl+X

Then validate + restart:

openclaw config validate

#

openclaw gateway restart

If you want heartbeat to go to a specific Discord channel

Do not put the channel id in target. After you get the gateway booting again, set:

heartbeat: {
  target: "discord",
  to: "channel:1469389732055351451",
}

Docs: https://docs.openclaw.ai/gateway/heartbeat

If you paste just the agents.defaults.heartbeat { ... } block from your openclaw.json after editing, I can sanity-check it before you restart.

mental fable Mar 7, 2026, 2:13 AM

#

how to i get my agent to stop doing shit that breaks the gateway?

#

is there a best practice doc i can give it or sometihng/

violet echoBOT Mar 7, 2026, 2:15 AM

#

Stop giving it the loaded gun.

What broke you here is: the agent had a path to write config / restart the gateway, and it wrote an invalid value. OpenClaw is strict about config validity, so one bad write = gateway won’t boot.

You fix this by restricting tools, not by “asking it nicely”.

1) Hard-block gateway/config mutations from the model

In ~/.openclaw/openclaw.json, add a tools deny:

{
  tools: {
    deny: ["gateway"], // blocks gateway restart + config apply/patch/update from the agent
  },
}

#

Restart the gateway after.

Docs: https://docs.openclaw.ai/tools (see “Disabling tools” + tool inventory for gateway)

2) (Optional but recommended) Block shell exec too

If your agent can run shell commands, it can also trash config that way. Deny runtime tools:

{
  tools: {
    deny: ["gateway", "group:runtime"], // exec/bash/process
  },
}

If you do want exec sometimes, don’t fully deny it—use approvals instead:

#

Set exec approvals to security: "allowlist" + ask: "always" (or at least on-miss)
Docs: https://docs.openclaw.ai/tools/exec-approvals

3) Operational pattern that doesn’t brick you

Tell your agent: “Propose config changes as a JSON5 snippet; do not apply them.”
Then you paste/apply.

If you paste your current tools: block (and your agents.list ids) I can tell you the smallest denylist that will stop gateway-bricking while keeping the tools you actually want.

#

Yep — two docs are basically “best practices” for exactly this:

Tools policy (how to prevent the model from having the ability to mutate config / restart gateway):
https://docs.openclaw.ai/tools
(see: tools.allow / tools.deny, tool profiles, and the fact that the gateway tool includes config apply/patch + restart)
Security / hardening baseline (why you should keep control-plane tools away from normal chats):
https://docs.openclaw.ai/gateway/security
(see: “Hardened baseline in 60 seconds”)

And for the specific heartbeat footgun you hit:
https://docs.openclaw.ai/gateway/heartbeat (target vs to)

What to “give your agent” (practical snippet for AGENTS.md / your system instructions)

You can paste something like this into your agent’s AGENTS.md:

Ops safety rule: Never edit ~/.openclaw/openclaw.json or call any gateway/config-update/restart tool.

#

If asked to change config, only propose the exact JSON5 snippet (or a minimal diff) and ask for explicit human approval before any change.

But the real best practice is: don’t rely on the doc/prompt alone — enforce it with tools.deny: ["gateway"] (and optionally group:runtime) so it can’t do the breaking thing even if it tries.

If you want, paste your current tools: config block and I’ll suggest a “safe but still useful” tool policy.

mental fable Mar 7, 2026, 1:36 PM

#

now i keep getting htis: LLM request rejected: messages.53.content.2: thinking or redacted_thinking blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

violet echoBOT Mar 7, 2026, 1:38 PM

#

That error is an Anthropic API invariants thing (it’s not you “prompting wrong”):

thinking / redacted_thinking blocks in the latest assistant message must be sent back byte-for-byte identical on the next request.
If anything in your stack “rewrites” that last assistant message (compaction, redaction, message edit, etc.), Anthropic rejects the next call with exactly what you’re seeing.

Fastest unblock

Start a fresh session (so the corrupted last-message isn’t in history anymore).
- In chat: send /new
- Or switch to a different Discord channel/thread (new session key)
After that, I’d also temporarily disable thinking for the session to reduce the chance of re-hitting it:
- Send: /think off
- (Optional) also: /reasoning off (separate from thinking, but keeps things simpler while debugging)

Docs on thinking directives: https://docs.openclaw.ai/tools/thinking

#Agent breaks gateway every time it tries to change something in config

Quick recovery (get the gateway back up)

If you actually want heartbeats to post into a Discord channel

Also: that iMessage warning can explain “it’s useless”

If it still doesn’t bind after fixing `heartbeat.target`

Fix it (pick one)

Option A (safest): disable heartbeat delivery so the gateway boots

Option B: deliver to “whoever you last talked to”

Option C: deliver to a specific Discord channel

If `openclaw config set ...` refuses to run

Do this now (copy/paste)

If that command errors (because config is too broken)

One question

1) Confirm which config file OpenClaw is using

2) See the current bad value (no guessing)

3) Force it to a valid value

If `openclaw config set` errors, paste that error

Fix it via terminal editor (works over SSH)

If you want heartbeat to go to a specific Discord channel

1) Hard-block gateway/config mutations from the model

2) (Optional but recommended) Block shell exec too

3) Operational pattern that doesn’t brick you

What to “give your agent” (practical snippet for AGENTS.md / your system instructions)

Fastest unblock

If it keeps happening even after `/new`

#Agent breaks gateway every time it tries to change something in config

Quick recovery (get the gateway back up)

If you actually want heartbeats to post into a Discord channel

Also: that iMessage warning can explain “it’s useless”

If it still doesn’t bind after fixing heartbeat.target

Fix it (pick one)

Option A (safest): disable heartbeat delivery so the gateway boots

Option B: deliver to “whoever you last talked to”

Option C: deliver to a specific Discord channel

If openclaw config set ... refuses to run

Do this now (copy/paste)

If that command errors (because config is too broken)

One question

1) Confirm which config file OpenClaw is using

2) See the current bad value (no guessing)

3) Force it to a valid value

If openclaw config set errors, paste that error

Fix it via terminal editor (works over SSH)

If you want heartbeat to go to a specific Discord channel

1) Hard-block gateway/config mutations from the model

2) (Optional but recommended) Block shell exec too

3) Operational pattern that doesn’t brick you

What to “give your agent” (practical snippet for AGENTS.md / your system instructions)

Fastest unblock

If it keeps happening even after /new

If it still doesn’t bind after fixing `heartbeat.target`

If `openclaw config set ...` refuses to run

If `openclaw config set` errors, paste that error

If it keeps happening even after `/new`