openclaw - 💡(How to fix) Fix OpenClaw 2026.5.12 iMessage start-account blocks gateway event loop (extends #81191 to iMessage)

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On macOS, the iMessage channel plugin's start-account phase blocks the gateway Node.js event loop during startup, causing the main lane to back up and TUI prompts to be absorbed without producing a response. Same class of bug as #81191 (which hardened the equivalent issue for the Telegram channel plugin), but the fix doesn't extend to the iMessage plugin.

Steps to reproduce

1. On macOS, install OpenClaw 2026.5.12 with the iMessage channel plugin enabled (plugins.entries.imessage.enabled = true) and Full Disk Access already granted to the node binary used by the gateway LaunchAgent.

2. Restart the gateway after any config write:

   openclaw gateway restart --wait 30s

3. Within ~30 seconds of the restart completing, send a prompt in a TUI session.

4. Observe:

   • The TUI accepts the prompt but no lane task starts.
   • The log shows repeated sessions.resolve calls returning INVALID_REQUEST with message No session found: current.
   • A liveness warning is emitted attributing event-loop delay to phase=channels.imess (the iMessage plugin's start-account phase).
   • openclaw gateway status reports Connectivity probe: ok and admin-capable despite the runtime being unable to serve prompts.

Expected behavior

The iMessage plugin's start-account phase runs non-blocking, with a bounded timeout — the same hardening that was applied to the Telegram channel plugin per #81191. The gateway event loop remains responsive during plugin startup, TUI prompts route to a lane task normally, and sessions.resolve succeeds for the active session id. If iMessage start-account exceeds its timeout budget, it should fail gracefully and report a structured plugin-startup error rather than starve the event loop.

Actual behavior

The gateway event loop is saturated during iMessage plugin startup. Liveness diagnostics show reasons=event_loop_delay with eventLoopDelayMaxMs exceeding 5,000ms, attributed to phase=channels.imess. The main lane queue stalls; sessions.resolve returns INVALID_REQUEST errorMessage="No session found: current" for any session id that predates the in-progress startup. openclaw gateway status reports the gateway as healthy throughout, which makes the root cause hard to diagnose without log inspection.

User-visible recovery requires either:

• sending /new in the TUI (which claims a fresh session against the post-restart gateway, sidestepping the stale-session lookup), OR
• waiting several minutes for iMessage start-account to finish blocking, OR
• disabling the iMessage plugin entirely (plugins.entries.imessage.enabled = false) and restarting the gateway, which eliminates the blocking and restores responsiveness immediately.

None of these address the underlying event-loop starvation.

OpenClaw version

2026.5.12

Operating system

macOS (arm64)

Install method

npm global (homebrew node)

Model

n/a — gateway startup / channel plugin behavior, not model-routed

Provider / routing chain

n/a — gateway startup / channel plugin behavior, not provider-routed

Additional provider/model setup details

NOT_ENOUGH_INFO — bug is in the gateway's channel-plugin startup path, independent of provider routing. Codex OAuth on a ChatGPT Pro subscription was the active auth profile in the affected environment, but the failure mode is identical to what would be seen on any provider because no model call ever fires; the lane queue is starved upstream of provider selection.

Logs, screenshots, and evidence

# Liveness warning attributing event-loop delay to iMessage plugin startup
liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=73 eventLoopDelayMaxMs=5435.8 eventLoopUtilization=0.323 cpuCoreRatio=0.352 active=2 waiting=0 queued=1 phase=channels.imess

# TUI prompt absorbed — gateway can't resolve the session id the TUI is attached to
⇄ res ✗ sessions.resolve 6ms errorCode=INVALID_REQUEST errorMessage=No session found: current
⇄ res ✗ sessions.resolve 1ms errorCode=INVALID_REQUEST errorMessage=No session found: current

# Gateway status reports healthy throughout, masking the actual problem
Service: LaunchAgent (loaded)
CLI version: 2026.5.12
Gateway version: 2026.5.12
Runtime: running (pid <redacted>, state active)
Connectivity probe: ok
Capability: admin-capable
Listening: *:18789

Impact and severity

User-facing impact: OpenClaw 2026.5.12 is effectively unusable on macOS after any gateway restart. Single-turn TUI prompts may eventually return after minutes of unresponsiveness, but anything more complex — multi-step workflows, agent spawning, tool-using sessions — locks up and times out. The TUI accepts prompts without complaint, then nothing happens. openclaw gateway status continues to report Connectivity probe: ok and admin-capable throughout, which makes the symptom hard to attribute without log inspection.

The pain is acute because openclaw update itself triggers a gateway restart at the tail end, so every update event puts a macOS user into this state for several minutes. Any cron-scheduled agent run during that window fails silently. Any in-progress TUI session needs to be discarded with /new before the user can do anything (and that workaround isn't documented).

Affected users: any OpenClaw user on macOS who has the iMessage channel plugin enabled. iMessage is a common channel for macOS-based personal-automation setups, and Full Disk Access grants on the gateway's node binary are a frequent operational concern (separate TCC dance after every brew upgrade node), so it's likely a meaningful share of macOS users.

Symptom severity: blocking. The same dynamic affects subagent runs, scheduled jobs, and any other lane traffic. openclaw gateway status reports the gateway as healthy throughout the affected window, so the symptom is hard to attribute without log inspection (the obvious-looking signals are sessions.resolve INVALID_REQUEST errors that look like client problems, not the upstream event-loop starvation that is the actual root cause).

The equivalent class of bug was previously hardened for the Telegram channel plugin per #81191. Extending the same fix to the iMessage plugin would resolve the macOS-specific surface of this regression.

Additional information

Last known good: behavior was not observed on 2026.5.7 stable (the previous installed version on the affected host). First seen on 2026.5.12 stable today, immediately after openclaw update upgraded 2026.5.7 → 2026.5.12 and the implicit gateway restart kicked in. Versions 2026.5.8 through 2026.5.11 were not personally tested. Note that #81191 reports the same class of bug on 2026.5.12-beta.1 (Telegram, Ubuntu), suggesting the regression entered the 2026.5.12 line.

Initial misdiagnosis ruled out: at first I attributed the symptom to the openai-codex/* → openai/* config-path rewrites that 2026.5.5's doctor --fix introduced (and 2026.5.6 partially reverted). The Codex OAuth routing was restored manually via jq edit and verified working (Codex auth profile in use, OAuth route reaching the Codex API). The event-loop starvation symptom persisted unchanged after the codex paths were correct, which confirmed the iMessage start-account blocking is independent of the codex path issue. (Any residual codex routing concerns are tracked separately and not part of this report.)

Closely related (open, very detailed analysis): #81191 — same class of event-loop starvation from a blocking channel-plugin start-account phase, originally observed for the Telegram channel plugin on Ubuntu / 2026.5.12-beta.1. The reporter (@najef1979-code) wrote an excellent root-cause writeup that includes specific code locations and proposed fixes. As of this filing, #81191 has no linked PR, no assigned maintainer, and no follow-up comments.

Why this is a meaningful second data point:

• This report is macOS / iMessage / 2026.5.12 (stable) — a different OS, different channel, different release channel than #81191's Ubuntu/Telegram/beta repro.
• The bug surface is identical, and #81191's reporter explicitly identified the root cause at the framework level (channels.${channelId}.start-account) rather than per-channel. So a fix landing for Telegram should also address iMessage, and vice versa.
• Confirming the pattern across two channels and two operating systems strengthens the case that the fix needs to be in the channel-framework startup harness, not duplicated per channel.

Code locations identified by #81191 (worth re-checking for iMessage's path):

• server-channels-CrJ7hZRA.js:402 — the framework measureStartup(channels.${channelId}.start-account, ...) call that wraps channel startAccount in a Promise but does not detach from the event loop.
• fetch-timeout-BsLaC-cZ.js — the fetchWithTimeout() helper whose underlying fetch blocks for the full timeout duration even with AbortController.
• For Telegram, the blocking calls were probe-DuPRVUmp.js:571 (getMe, deleteWebhook, getWebhookInfo). The iMessage analog would be the TCC-gated SQLite read on ~/Library/Messages/chat.db plus any Bonjour/IPC handshakes the plugin does on start.

Fix directions proposed in #81191 (apply equally to iMessage):

1. Move channel startAccount into a detached microtask (setImmediate) so the gateway event loop returns to serving immediately, with channel readiness reported asynchronously.
2. Circuit-breaker pattern around blocking I/O probes, failing fast after N consecutive failures and resetting after a cooldown.
3. Worker-thread isolation of any guaranteed-blocking I/O.
4. Aggressive timeout caps on the probe path (e.g., 5s) instead of inheriting a large timeoutBudgetMs.

A framework-level fix using approach (1) would cover both Telegram and iMessage simultaneously and avoid the per-channel duplication.

Related (closed, fix already in 2026.5.12):

• #44687 — Stale session resume at gateway startup blocks lane=main indefinitely.
• #60549 — TUI sessions lost on reconnect; gateway returns 'No session found' for existing session.
• #68735 — LLM request failed: provider rejected the request schema or tool payload.
• #74404 — Gateway becomes CPU-saturated and agents stop progressing mid-work (fix landed in 2026.5.2 stable but only addressed sessions.list perf — channel start-account blocking was out of scope and is the current live regression class).

These are mentioned because their symptoms partially overlap with this report's surface (sessions.resolve INVALID_REQUEST), but those fixes are present in 2026.5.12, so the live issue isn't them.

Workarounds documented for affected users in the meantime:

1. Send /new in the TUI after any gateway restart, instead of trying to resume a pre-restart session id. This sidesteps the sessions.resolve cascade but does not fix the event-loop starvation.
2. Disable the iMessage channel plugin (plugins.entries.imessage.enabled = false) and restart the gateway. Restores responsiveness immediately at the cost of iMessage send/receive functionality.

This bug report was drafted with AI assistance.