Independent OpenClaw reporting, releases, guides, and community coverage
OpenClaw News

OpenClaw Fixes macOS Cookie Sync Crash Loop

OpenClaw merged a P0 macOS fix so remote-mode Cookie Sync can stay enabled without triggering a startup watchdog crash loop.

Filed under Posts 3 min read Updated Sep 16, 2026
OpenClaw Fixes macOS Cookie Sync Crash Loop

OpenClaw merged a P0 macOS stability fix today for users who run the desktop app in remote mode with Cookie Sync enabled. The change landed in PR #137052, titled "fix: prevent macOS crashes when cookie sync is enabled."

The failure mode was sharp: with Cookie Sync enabled, the macOS app could trip a Swift MainActor isolation trap a few seconds after the cookie-sync watcher started. In practice, that meant the app could enter a crash loop instead of keeping the remote session alive.

What Changed

The bug centered on the startup watchdog for Cookie Sync. According to the PR, the watchdog was created on a private dispatch queue inside a @MainActor manager. Its event handler inherited main-actor isolation, which could cause Swift to trap before the nested main-actor task had a chance to execute.

The fix moves that watchdog directly onto the main queue and removes the redundant actor hop. The surrounding reader callbacks and termination handling stay unchanged because the focused runtime probes already showed those paths delivering correctly.

That makes this a narrow fix, which is a good sign for a P0 desktop crash. It repairs the owner of the failing timer without broadening cookie policy, changing retry behavior, or altering CLI arguments.

User Impact

For macOS users, the important line is simple: Cookie Sync can remain enabled in remote mode without the app crashing when the five-second startup watchdog fires.

That matters because Cookie Sync is one of the pieces that makes remote browser and web workflows feel continuous. A crash loop at startup is not just a rough edge; it can block an otherwise working remote setup from being usable.

The PR explicitly says there is no configuration, schema, protocol, credential, retry-policy, or cookie-sync CLI argument change. Existing setups should get the fix as a stability improvement rather than a migration event.

Why This Was Treated As P0

The labels on the merged PR include P0, app: macos, and proof: sufficient. That combination tells the story: this was a severe app-level failure with enough native proof to justify landing.

The proof trail includes current-toolchain Swift 6.4 typechecking with strict concurrency enabled, focused lifecycle evidence, and successful exact-head CI that included macOS Swift tests. The PR also links the maintainer proof comment and notes that the refreshed ClawSweeper review accepted the native proof with no actionable findings.

The contributor evidence was intentionally kept separate from current-head CI. That distinction is useful: the PR does not pretend old local proof was rerun under a newer commit. Instead, the maintainer continuation explains what was retained, what was freshly checked, and where the boundary sits.

What To Watch

If you rely on remote-mode Cookie Sync, this is the kind of fix worth taking promptly once it appears in a release. It does not advertise a new feature, but it removes a startup crash path in a high-friction workflow.

The change also continues a pattern in OpenClaw's native app work: small platform-specific fixes backed by focused proof rather than broad rewrites. For a crash loop inside a Swift concurrency boundary, that is exactly the shape users should want.

Source: OpenClaw PR #137052.

Daily Briefing

Get the Open-Source Briefing

The stories that matter, delivered to your inbox every morning. Free, no spam, unsubscribe anytime.

Join 45,000+ developers. No spam. Unsubscribe anytime.