[Bug]: Mac App overwrites openclaw.json and strips gateway.auth, causing bind=lan gateway crash loop

[doomsday616]

Summary

When gateway.bind is set to lan, the Mac App periodically overwrites openclaw.json and removes the gateway.auth section. This causes the gateway to enter a crash loop because newer versions refuse to bind to LAN without auth.

Steps to reproduce

1. Set gateway.bind: "lan" and gateway.auth.token: "some-token" in ~/.openclaw/openclaw.json
2. Start the gateway via LaunchAgent — it starts fine
3. Open the Mac App (or wait for it to sync config)
4. Mac App overwrites openclaw.json — the gateway.auth key is gone
5. Gateway detects config change, restarts, and immediately fails with Refusing to bind gateway to lan without auth
6. KeepAlive: true in the plist causes launchd to restart it endlessly — crash loop

Expected behavior

Mac App should preserve unknown/user-added keys in openclaw.json when it writes config back to disk — or at minimum preserve gateway.auth.

Actual behavior

Mac App drops gateway.auth entirely on every config write. The gateway then enters an infinite crash loop:

2026-02-19T22:20:06.944+08:00 Refusing to bind gateway to lan without auth.
Set gateway.auth.token/password (or OPENCLAW_GATEWAY_TOKEN/OPENCLAW_GATEWAY_PASSWORD) or pass --token/--password.

This repeats every ~10 seconds indefinitely. The feishu channel also goes down as a result.

Setting OPENCLAW_GATEWAY_TOKEN in the plist's EnvironmentVariables does work as a workaround for the initial startup, but the Mac App's config overwrite still triggers a gateway restart (it detects gateway.auth changed), causing brief outages each time.

Version

2026.2.17

Operating system

macOS 26.3 (Apple Silicon)

Install method

npm global + Mac App (both running simultaneously)

Logs, screenshots, and evidence

gateway.err.log after Mac App overwrites config — this pattern repeats hundreds of times:

2026-02-19T22:20:06.944+08:00 Refusing to bind gateway to lan without auth.
2026-02-19T22:20:17.822+08:00 Refusing to bind gateway to lan without auth.
2026-02-19T22:20:37.233+08:00 Refusing to bind gateway to lan without auth.
...

From /tmp/openclaw/openclaw-2026-02-19.log, the Mac App overwrite is visible:

Config overwrite: /Users/doomsday616/.openclaw/openclaw.json
config change detected; evaluating reload (gateway.auth)
config change requires gateway restart (gateway.auth)

Also: openclaw doctor reports feishu channel as failed (unknown) - Request failed with status code 400 after the crash loop.

Impact and severity

• Affected: Anyone using bind=lan with both the Mac App and CLI gateway running
• Severity: High — gateway is completely down until manually fixed
• Frequency: 100% repro, happens every time Mac App writes config
• Consequence: All channels (feishu, etc.) go offline. The crash loop also generates a 3GB+ gateway.log from repeated startup attempts.

Additional information

Workaround: switch gateway.bind to loopback so auth is not required. This avoids the crash but means LAN devices can't connect to the gateway.

openclaw doctor --fix partially helps — it regenerates a token — but the Mac App will overwrite it again on next config sync.

The root issue seems to be that the Mac App maintains its own in-memory copy of openclaw.json and does full overwrites without merging user-added keys.

[nikolasdehor]

I commented on #20344 about the same class of problem — companion app overwriting openclaw.json and disrupting gateway operation. This issue is a clear escalation: in #20344 the Mac App was overwriting gateway.auth with a different value, but here it's stripping gateway.auth entirely, which is far worse because it triggers an immediate crash loop on bind=lan gateways.

I'm affected by this exact setup: macOS, LaunchAgent (ai.openclaw.gateway), bind=lan. The KeepAlive: true in the plist makes it especially painful — launchd restarts the gateway every ~10 seconds, each attempt fails instantly because auth is gone, and you end up with a multi-GB log file before you even notice.

The env var workaround (OPENCLAW_GATEWAY_TOKEN in the plist) helps avoid the crash, but as the reporter notes, the Mac App still triggers a config-change restart each time it overwrites, causing brief channel outages. That's not a real fix.

A few thoughts on what the proper fix should look like:

1. The Mac App should never write to openclaw.json if the gateway is already running. Before writing, it should check for a running gateway process (PID file, socket, or even just lsof on the config file). If the gateway holds the config, the Mac App should treat it as read-only.

2. If it must write, it should merge, not overwrite. The current behavior of maintaining an in-memory copy and doing a full overwrite is fundamentally broken for any key the Mac App doesn't know about. At minimum, unknown keys should be preserved on write-back.

3. File-lock mechanism: Is there an appetite for the gateway to hold an flock or .lock file on openclaw.json while running? The Mac App could check for this lock before attempting writes. This would be a clean, cross-platform-ish solution.

4. Config schema versioning: If openclaw.json had a schema version field, the Mac App could detect that the on-disk config has keys it doesn't understand and refuse to overwrite rather than silently dropping them.

The combination of "silent key stripping + crash loop + KeepAlive respawn + multi-GB log growth" makes this a high-severity issue for anyone running bind=lan alongside the Mac App. Would appreciate a fix or at least a documented workaround beyond "don't use the Mac App."

[doomsday616]

Heads up: the bind=loopback workaround mentioned here doesn't fully help — there's a separate issue where the Mac App retries role: node auth endlessly with no backoff, causing a CPU spike on both the gateway and the app even in loopback mode. Filed as #21137.

Current safe workaround is to not run the Mac App at all and use CLI + web dashboard instead.

[zachyzissou]

I can confirm this from local repro on macOS + npm Gateway/launchd setup too.

I’ve now seen multiple overlapping issues that look tightly related:

• [Bug]: macOS companion app repeatedly overwrites gateway.auth on launch, causing restart loops #20344: app rewrites gateway.auth on launch, causing reload/restart loops
• [Bug]: macOS app retries node auth endlessly after rejection, causing CPU spike #21137: endless auth-retry storm after Mac app open (unauthorized role: node), high CPU + large logs
• CRITICAL BUG - Edge Case - Mac app reinstall triggers breaking log bomb — no retry backoff, no log rotation, health check role mismatch #21080: reinstall flow causes stale token/role auth mismatch + immediate retry storm and log growth
• [Bug]: Gateway WebSocket connection fails persistently after reboot — health check stuck or timeout #20958: related gateway connectivity instability from app side after lifecycle events/reboot

My local evidence:

• When I opened the Mac app, gateway logs started showing restart/activity conflicts until I stopped the Mac app.
• gateway.auth/config churn appears to be a key trigger.
• This is not fully solved by staying on loopback only.
• Main failure mode I see is process-level disruption and repeated unauthorized/role auth churn, even when auth exists in config.

Current workaround I’m using:

1. Keep single gateway source and avoid running both app + CLI gateway in conflicting mode.
2. Prefer loopback mode only + avoid app launch while debugging.
3. Manually stop duplicate gateway instances to clear Port already in use states.

It feels like this is a broader Mac App ↔ Gateway contract bug:

• app-side config overwrite behavior,
• role/auth expectations mismatch (role: node vs operator side),
• and missing backoff in retry loop causing a storm.

A combined fix around non-destructive config merge + stable auth/role handshake + retry backoff / circuit breaker seems needed.

[openclaw-barnacle]

This issue has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

[newcodebook]

This is a nasty failure mode because bind=lan + missing gateway.auth is intentionally fail-closed, and launchd KeepAlive turns it into a tight crash loop.

Workarounds (until the Mac app preserves config fields):

1. Don’t run the Mac app against this gateway (use openclaw dashboard / web UI instead). This avoids the app’s config rewrite path.
2. If you must keep bind=lan, move the auth source out of openclaw.json so the gateway can still start even if the app drops fields:
   • set OPENCLAW_GATEWAY_TOKEN / OPENCLAW_GATEWAY_PASSWORD in the LaunchAgent plist

After applying either workaround, restart:

openclaw gateway restart

Related CoClaw pages:

• https://coclaw.com/guides/new-user-checklist/
• https://coclaw.com/guides/updating-and-migration/

[akmacks]

Also reproduces on v2026.2.22 (Intel Mac)

Adding a data point: I hit this exact crash+restart loop today on macOS 26.4 / Intel MacBook Pro i9 (x86_64) with app v2026.2.22 and CLI v2026.2.26.

The gateway crashed 5+ times across ~3 hours. Every cycle followed the same pattern:

1. App opens → writes gateway.auth: {} to openclaw.json
2. Gateway detects change → logs [reload] config change requires gateway restart (gateway.auth)
3. Gateway regenerates token and restarts
4. Repeat

Worth noting for Intel users: v2026.2.22 is the last Intel-compatible build (v2026.2.23+ are arm64-only per #28877), so Intel Mac users are stuck with a version that has this bug and cannot upgrade the app to get a fix.

The only reliable workaround is to keep the macOS app closed entirely and use CLI + web dashboard only.