OpenClaw closes two recovery loops and documents a silent third

openclaw/openclaw PR #116504 is the inspected primary source: “fix(ios): finish Calendar and Reminders grants without relaunch.” The two related records below were inspected as supporting context, not treated as independent confirmation.

The facts

- openclaw/openclaw PR #116504 was created 2026-07-30T18:01:59Z and was closed at inspection; its title is “fix(ios): finish Calendar and Reminders grants without relaunch.” - openclaw/openclaw PR #118311 was created 2026-08-03T00:02:34Z and was closed at inspection; its title is “fix(gateway): recover channel autostart after crash loops.” - openclaw/openclaw issue #112259 was created 2026-07-21T11:02:18Z and was open at inspection; its title is “Visible inbound channel turn can be silently dropped: zero-payload dispatch has no retry, dead-letter, or user-visible failure.” - The repository reported 384956 stars, 5545 open issues, default branch main, and last push 2026-08-03T01:01:42Z. - The latest tagged-release baseline checked was v2026.7.2-beta.7 published 2026-08-02T08:11:31Z.

What changed

openclaw/openclaw PR #116504 reports: Closes #116503 What Problem This Solves Fixes an issue where iOS users granting Calendar or Reminders access could see the permission flow remain unfinished until relaunch, even though iOS persisted the grant. Why This Change Was Made Both onboarding and Settings now share a retained EventKit permission requester that owns one long-lived EKEventStore across the asynchronous system permission sheet and callback. The requester covers calendar add-only/full access and reminders full access without changing permission semantics or copy. Apple's EventKit contract recommends keeping an event store long-lived. The previous request paths created temporary stores immediately before starting asynchronous authorization. User Impact Calendar and Reminders permission rows can complete and reconcile immediately after the system choice instead

openclaw/openclaw PR #118311 reports: Closes #115326 AI-assisted: yes What Problem This Solves Fixes an issue where a managed Gateway that survived a restart storm would remain healthy but leave configured messaging channels suppressed forever in that process, even after the five-minute crash-loop window had fully drained. Why This Change Was Made The existing channel health-monitor cadence now asks the Gateway lifecycle owner to re-prove recovery only after the persisted window contains zero unclean boots. Before releasing suppression, the lifecycle is atomically split and a fresh open recovery row is recorded, so a process death during resumed channel startup still counts toward the next breaker decision. Recovery resumes the deferred bulk autostart path while preserving explicit manual stops and separate

openclaw/openclaw issue #112259 reports: Summary A visible inbound channel message (iMessage DM, but the path is channel-generic) can be accepted by the channel turn kernel and then silently discarded: the turn dispatches with zero reply payloads, no agent run is ever created, nothing is persisted to the session transcript, and the sender receives no reply and no error. The only trace is a single log.warn: There is no retry, no dead-letter, and no user-visible acknowledgement. For an assistant whose primary inbound channel is a messaging app, a silently dropped message is indistinguishable from being ignored — the user only finds out when they follow up angrily, and the agent then has no record the message ever existed (worse: the

Why it matters

The project now has evidence for two repairs and a sharply instrumented report for the unresolved path. The useful pattern is not “more retries”; it is preserving enough identity and lifecycle state to distinguish suppression, duplication, cancellation and genuine loss. The operational test is whether persisted state, execution authority and visible user outcome describe the same event. Broad retries, hidden suppression or permission expansion can hide the symptom while making the boundary less trustworthy.

Current

The primary record was closed when captured on 2026-08-03. The release baseline was v2026.7.2-beta.7 published 2026-08-02T08:11:31Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts HTML row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/openclaw/openclaw/pull/116504. Supporting records are https://github.com/openclaw/openclaw/pull/118311 and https://github.com/openclaw/openclaw/issues/112259. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Keep channel recovery separate from manual stops, attribute zero-payload dispatches to their exact branch, and require a receipt or dead-letter for every visible user turn. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.