OpenClaw merged PR #102465, "fix(mac): keep launch-at-login app running", a small but practical macOS reliability fix for people who expect OpenClaw to be available immediately after signing in.
The bug was easy to miss but painful when it happened. When the macOS app launched through its login item, startup state hydration could cause the app to rewrite its launch-agent plist, boot itself out of launchd, exit, and leave no loaded job behind.
In other words: launch at login could successfully start OpenClaw, then the app could immediately unload the mechanism that was supposed to keep it running.
What Changed
The fix changes how the app refreshes its persisted launch-agent plist. It now treats an already-loaded launchd job as active state and avoids the destructive bootout/bootstrap cycle during startup hydration.
The loaded-state check also queries launchd independently from plist presence. That keeps the normal toggle behavior intact:
- If the user turns launch at login off, OpenClaw can still unload the job.
- If the user turns it on, OpenClaw can still write and load the job.
- If the app is already running because launchd started it, startup hydration no longer tears it down.
That last point is the one users will notice.
Why It Matters
The macOS app has become a bigger part of OpenClaw's first-run and daily-use path. Recent releases added automatic local Gateway setup, improved onboarding, and more native control surfaces. Launch-at-login reliability is part of that same story.
A local assistant is only useful if it is actually present when the user expects it. If the app disappears during login, downstream pieces like the local Gateway, dashboard, voice flows, and node connectivity can all feel unreliable even when the deeper runtime is healthy.
PR #102465 narrows the failure to the launch-agent lifecycle and fixes it without changing the user-facing toggle model.
User Impact
For Mac users with launch at login enabled, OpenClaw should remain running after startup instead of briefly appearing and then disappearing.
The PR's before-and-after evidence is concrete. Before the fix, bootstrapping ai.openclaw.mac launched the app, but startup hydration rewrote the plist, booted itself out, exited, and left no loaded job. After the fix, a signed release app launched from the same agent stayed in state = running with one OpenClaw process and the plist still present.
There is no new setup step. The change is about preserving the intended state during app startup.
Validation
The PR reports seven passing LaunchAgentManagerTests through:
swift test --package-path apps/macos --filter LaunchAgentManagerTests
It also reports a clean local autoreview with no accepted or actionable findings.
Bottom Line
This is a narrow macOS fix, but it lands in an important place. OpenClaw's native app experience depends on predictable background availability, and launch-at-login should never be a self-canceling path. PR #102465 makes that path behave like users expect.