#LaunchAgent instability

9 messages · Page 1 of 1 (latest)

somber yoke
#

macOS LaunchAgent instability on OpenClaw 2026.4.14

I am seeing repeated gateway outages on macOS that look like a LaunchAgent / service lifecycle issue, not a normal gateway crash.

Environment

• OpenClaw: 2026.4.14
• macOS: 26.3.1
• Host: Mac mini
• Gateway mode: local
• LaunchAgent label: ai.openclaw.gateway
• Node path: /opt/homebrew/opt/node@24/bin/node
• Entry point: /opt/homebrew/lib/node_modules/openclaw/dist/index.js

Symptom

The gateway repeatedly disappears and openclaw gateway restart reports:
Gateway LaunchAgent was installed but not loaded; re-bootstrapped launchd service.
openclaw doctor also sometimes reports:
• Gateway not running
• Gateway service not installed

even though the plist exists and the service had been running before.

Why this does not look like a normal gateway crash

In gateway.log, the shutdown is consistently:

• signal SIGTERM received
• received SIGTERM; shutting down

This looks like the process is being terminated externally, not crashing internally.

In macOS system logs, I repeatedly see launchd removing the service:

• service inactive: ai.openclaw.gateway
• removing service: ai.openclaw.gateway

Relevant observations

• launchctl print gui/<uid>/ai.openclaw.gateway shows the service as valid and running when up
• later, launchd logs show the same service being removed
• doctor --fix appears to reinstall / rewrite the LaunchAgent, which may be related
• plist mtime changes during these recovery attempts
• this can happen multiple times in a short window

Example sequence observed

• gateway starts normally
• channels initialize successfully
• later gateway receives SIGTERM
• launchd logs service inactive / removing service
• openclaw gateway restart then says the LaunchAgent was installed but not loaded and re-bootstraps it

supple brambleBOT
#

Yeah, this really does look more like launchd/service lifecycle churn than a normal gateway crash.

A few source-backed reasons:

  • In 2026.4.14, the macOS LaunchAgent plist is written with RunAtLoad=true + KeepAlive=true.
  • The message
    “Gateway LaunchAgent was installed but not loaded; re-bootstrapped launchd service.”
    comes from a specific recovery path that only runs when the plist still exists but launchd no longer has the job loaded.
  • openclaw doctor --fix is allowed to rewrite/repair supervisor config.
  • The macOS app in Local mode also owns LaunchAgent install/update.

So this sequence:

  • gateway gets SIGTERM
  • launchd logs service inactive / removing service
  • restart says “installed but not loaded” and re-bootstraps
#

...fits external unload/reinstall/removal much better than an internal gateway fault.

Most likely buckets I’d check:

  1. Another OpenClaw manager is touching the same LaunchAgent

    • OpenClaw.app in Local mode
    • doctor --fix
    • install/update flow

  2. Duplicate/stale services

    • old com.openclaw.* or parallel profile installs
    • docs specifically recommend gateway status --deep for this

  3. GUI session churn

    • this is a LaunchAgent under gui/$UID, not a LaunchDaemon
    • if the user session logs out/resets, launchd can unload it
#
  1. Service drift causing repair loops
    • plist rewrite/mtime changes line up with that

Also, your Node path does not look like the classic nvm/fnm/volta/asdf problem. /opt/homebrew/opt/node@24/bin/node is not the obvious smoking gun here.

What I’d collect next, read-only first:

openclaw --version
openclaw status --all
openclaw gateway status --deep --json
launchctl print gui/$UID/ai.openclaw.gateway
plutil -p ~/Library/LaunchAgents/ai.openclaw.gateway.plist
log show --last 30m --style compact --predicate 'process == "launchd" AND eventMessage CONTAINS "ai.openclaw.gateway"'

Two important notes:

#
  • While investigating, I’d avoid openclaw doctor --fix unless you specifically want it to repair/rewrite the service. Use plain openclaw doctor / status first.
  • If OpenClaw.app is also running on that Mac in Local mode, that’s a very important clue, because the docs say it manages the same LaunchAgent.

Relevant docs:

If you paste the outputs, plus whether OpenClaw.app is running in Local mode, I can help narrow down which actor is unloading it. This also smells GitHub-issue-worthy if it’s reproducible: https://github.com/openclaw/openclaw/issues

somber yoke
#

I checked whether OpenClaw.app was actively running in Local mode and could be managing the same LaunchAgent in parallel. At the time of inspection, OpenClaw.app was installed but not running. I also did not see a second obvious OpenClaw LaunchAgent label besides ai.openclaw.gateway.

supple brambleBOT
#

That helps, it lowers the odds that OpenClaw.app is the one actively unloading it.

At that point I’d narrow it to these two buckets:

  1. An OpenClaw CLI flow is doing it

    • doctor --fix
    • gateway install --force
    • gateway restart
    • update/install paths

    In 2026.4.14 those paths really do bootout / unload / bootstrap, so plist mtime changes during repair are expected.

  2. macOS is unloading the user LaunchAgent

    • ai.openclaw.gateway lives under gui/$UID
    • if that GUI session churns, launchd can remove the job
    • that would also fit SIGTERM + service inactive / removing service
#

One useful clarification: the “service not installed” style output is about launchd state, not just “does a plist file exist on disk”, so plist-present and “not loaded/not installed” can coexist.

The big discriminator now is:

Does it disappear when you are doing absolutely nothing with OpenClaw, or only around doctor/restart/install activity?

If you want, I’d test it like this:

openclaw gateway restart
log stream --style compact --predicate '(process == "launchd" OR process == "loginwindow") AND eventMessage CONTAINS[c] "ai.openclaw.gateway"'

Then leave it alone for a while. If it vanishes without any OpenClaw command being run, I’d start suspecting GUI session / launchd churn much more strongly.

A few targeted checks I’d still want: