openclaw - 💡(How to fix) Fix [Bug] Gateway killed by SIGTERM ~13s after self-triggered config hot-reload of agents.defaults.model.primary; launchd does not re-register (Discord trigger) [3 comments, 3 participants]

[Bug] Gateway killed by SIGTERM ~13s after a self-triggered config hot-reload of agents.defaults.model.primary; launchd does not re-register the service. Issue is reliably reproduced with Discord channel enabled and disappears entirely when Discord is disabled.

Environment

• OpenClaw: 2026.5.7 (commit eeef486)
• Install method: npm (/opt/homebrew/lib/node_modules/openclaw/) installed via curl -fsSL https://openclaw.ai/install.sh | bash
• Node: v25.9.0 (/opt/homebrew/opt/node/bin/node)
• OS: macOS 15+ (LSMinimumSystemVersion = 15.0)
• Plugins enabled: discord, memory-core
• Channels: Discord (@TomOpenCLaw in guild "Tom personal assistant")
• gateway.controlUi.allowInsecureAuth: true (loopback only)
• messages.groupChat.visibleReplies: "message_tool" (with the doctor warning that the message tool is unavailable for agent "main", agent "sonnet-worker", and 5 more)

Summary

Within minutes of a clean gateway start, something inside OpenClaw modifies agents.defaults.model.primary in ~/.openclaw/openclaw.json. The gateway hot-reloads the config successfully, then receives SIGTERM ~13 seconds later and shuts down cleanly. Launchd does not re-register the LaunchAgent afterwards (launchctl print gui/$(id -u)/ai.openclaw.gateway returns "Could not find service"), leaving the bot offline until openclaw gateway install --force is run manually.

The behavior is reliably reproducible with the Discord channel enabled and disappears entirely when Discord is disabled — gateway has stayed up cleanly for >10 minutes with channels.discord.enabled = false.

Reproduction

1. Fresh install OpenClaw 2026.5.7 via the official install.sh.
2. Configure a Discord channel (channels.discord.enabled = true) with a bot connected to a guild.
3. Start the gateway.
4. Within a few minutes, the gateway logs:

   [reload] config change detected; evaluating reload (agents.defaults.model.primary, meta.lastTouchedAt)
   [reload] config hot reload applied (agents.defaults.model.primary)
   [gateway] signal SIGTERM received
   [gateway] received SIGTERM; shutting down
   [shutdown] completed cleanly in 157ms

5. Gateway dies. lsof -iTCP:18789 -P returns nothing.
6. launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway fails with Could not find service "ai.openclaw.gateway" in domain for user gui: 501.
7. Only openclaw gateway install --force brings the service back.

Expected behavior

• Either: the self-triggered config change should not result in a SIGTERM, OR
• The LaunchAgent should automatically re-register and restart the gateway after a clean shutdown, OR
• A clean shutdown initiated by hot-reload should be a true graceful restart that brings the service back without operator intervention.

Actual behavior

The gateway shuts down cleanly but launchd considers the service unloaded and does not restart it. The user has to manually run openclaw gateway install --force every time.

Pre-shutdown symptoms (with Discord enabled)

For ~10 minutes leading up to the SIGTERM, the gateway repeatedly logs:

[diagnostic] liveness warning: reasons=event_loop_delay interval=30s
  eventLoopDelayP99Ms=216-230 eventLoopDelayMaxMs=1900-3810
  eventLoopUtilization=0.24-0.39 cpuCoreRatio=0.27-0.46
  active=1 waiting=0 queued=1 phase=channels.discord.start-account
  work=[active=agent:main:discord:channel:<id>(processing/model_call,
        q=1, age=N, last=model_call:started)]

[diagnostic] long-running session: sessionKey=agent:main:discord:channel:<id>
  state=processing age=135s queueDepth=1 reason=queued_behind_active_work
  classification=long_running activeWorkKind=model_call
  lastProgress=model_call:started lastProgressAge=4s recovery=none

[fetch-timeout] fetch timeout after 2500ms (elapsed 2622ms)
  operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me

Multiple Config overwrite: lines appear during the same window, suggesting OpenClaw is rewriting its own config repeatedly. The model also auto-switches between providers (anthropic/claude-sonnet-4-6 ↔ deepseek/deepseek-v4-flash) without user input.

Confirmation that Discord is the trigger

After running:

openclaw config set channels.discord.enabled false
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

The gateway has been continuously up for >10 minutes with no liveness warnings, no SIGTERM, no start-account hangs, no event-loop delays, and no model-fallback churn. Only memory-core is loaded.

Workaround currently in use

Disable Discord (channels.discord.enabled = false). Gateway stays stable but the bot is unreachable on Discord.

When the gateway dies, recovery requires:

openclaw gateway install --force

launchctl kickstart fails because the service is not registered. openclaw gateway restart is also unreliable (matches #40905).

Likely related issues

• #40905 — openclaw gateway restart fails to re-bootstrap LaunchAgent on macOS
• #46012 — macOS gateway LaunchAgent not loaded after openclaw update
• #40550 — openclaw gateway stop/start fails to recover on macOS 26 — service removed but never re-registered
• #60885 — LaunchAgent ThrottleInterval=1 causes unrecoverable gateway downtime after auto-update

Two distinct problems combined

Worth separating these in any fix:

1. What inside OpenClaw is modifying agents.defaults.model.primary and triggering a SIGTERM? This appears to be self-inflicted by the bot's own automation. Whatever is doing it should either not require a SIGTERM (graceful in-process reload only) or should issue a launchctl-aware restart that survives.
2. Why doesn't launchd restart the service after a clean shutdown? This affects multiple existing issues (#40905, #46012, #40550, #60885) and is the reason "the gateway died and didn't come back" instead of "the gateway restarted cleanly."

Either fix alone would be a meaningful improvement; fixing both would make the system self-healing.

Logs

Happy to attach the full ~/.openclaw/logs/gateway.log and gateway.err.log covering the crash window if useful — they contain the SIGTERM sequence above plus the preceding ~10 minutes of liveness warnings and config rewrites.