openclaw
diff --git a/‎CHANGELOG.md‎
Lines changed: 1 addition & 0 deletions b/‎CHANGELOG.md‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎docs/channels/imessage.md‎
Lines changed: 18 additions & 0 deletions b/‎docs/channels/imessage.md‎
Lines changed: 18 additions & 0 deletions
diff --git a/‎extensions/imessage/src/approval-auth.test.ts‎
Lines changed: 146 additions & 0 deletions b/‎extensions/imessage/src/approval-auth.test.ts‎
Lines changed: 146 additions & 0 deletions
diff --git a/‎extensions/imessage/src/approval-auth.ts‎
Lines changed: 78 additions & 0 deletions b/‎extensions/imessage/src/approval-auth.ts‎
Lines changed: 78 additions & 0 deletions
@@ -38,6 +38,7 @@ Docs: https://docs.openclaw.ai
 
 ### Changes
 
+- iMessage: support thumb-approval reactions — `👍` (Like tapback) resolves an approval as `allow-once` and `👎` resolves as `deny`, with the explicit-approver allowlist read from `channels.imessage.allowFrom`; `allow-always` stays on the manual `/approve <id> allow-always` text fallback. Mirrors the WhatsApp behavior from #85477.
 - Gateway/perf: reuse process-stable channel catalog reads, avoid repeated bundled-channel boundary checks, and rotate gateway watch CPU profiles so benchmark runs do not accumulate unbounded artifacts.
 - Gateway/perf: cache stable install-record, channel-catalog, bundled-channel, and Telegram session-store metadata during process-local hot paths to reduce repeated JSON and manifest reads.
 - Gateway/perf: reuse immutable plugin metadata snapshots across startup, config, model, channel, setup, and secret metadata readers so hot paths avoid repeated plugin file stats and manifest registry reloads.
 
@@ -564,6 +564,24 @@ When `imsg launch` is running and `openclaw channels status --probe` reports `pr
     Per-account overrides use `channels.imessage.accounts.<id>.reactionNotifications`.
 
   </Accordion>
+
+  <Accordion title="Approval reactions (👍 / 👎)">
+    When `approvals.exec.enabled` or `approvals.plugin.enabled` is true and the request routes to iMessage, the gateway delivers an approval prompt natively and accepts a tapback to resolve it:
+
+    - `👍` (Like tapback) → `allow-once`
+    - `👎` (Dislike tapback) → `deny`
+    - `allow-always` remains a manual fallback: send `/approve <id> allow-always` as a regular reply.
+
+    Reaction handling requires the reacting user's handle to be an explicit approver. The approver list is read from `channels.imessage.allowFrom` (or `channels.imessage.accounts.<id>.allowFrom`); add the user's phone number in E.164 form or their Apple ID email. The wildcard entry `"*"` is honored but allows any sender to approve. The reaction shortcut intentionally bypasses `reactionNotifications`, `dmPolicy`, and `groupAllowFrom` because the explicit-approver allowlist is the only gate that matters for approval resolution.
+
+    **Behavior change with this release:** When `channels.imessage.allowFrom` is non-empty, the `/approve <id> <decision>` text command is now authorized against that approver list (not the broader DM allowlist). Senders permitted on the DM allowlist but not in `allowFrom` will receive an explicit denial. Add every operator who should be able to approve via `/approve` (and via reactions) to `allowFrom` to preserve the previous behavior. When `allowFrom` is empty the legacy "same-chat fallback" stays in effect and `/approve` continues to authorize anyone the DM allowlist permits.
+
+    Operator notes:
+    - The reaction binding is stored both in memory (with TTL matched to the approval expiry) and in the gateway's persistent keyed store, so a tapback that lands shortly after a gateway restart still resolves the approval.
+    - Cross-device `is_from_me=true` tapbacks (the operator's own reaction on a paired Apple device) are intentionally ignored so the bot cannot self-approve.
+    - Legacy text-style tapbacks (`Liked "…"` plain text from very old Apple clients) cannot resolve approvals because they carry no message GUID; reaction resolution requires the structured tapback metadata that current macOS / iOS clients emit.
+
+  </Accordion>
 </AccordionGroup>
 
 ## Config writes
 
@@ -0,0 +1,146 @@
+import { describe, expect, it } from "vitest";
+import { getIMessageApprovalApprovers, imessageApprovalAuth } from "./approval-auth.js";
+
+describe("imessageApprovalAuth", () => {
+  it("authorizes individual handles and ignores group/chat target entries", () => {
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["+1 (555) 123-0000"] } } },
+        senderId: "+15551230000",
+        action: "approve",
+        approvalKind: "exec",
+      }),
+    ).toEqual({ authorized: true });
+
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: {
+          channels: {
+            imessage: {
+              allowFrom: ["chat_guid:iMessage;+;chat123", "chat_id:42"],
+            },
+          },
+        },
+      }),
+    ).toEqual([]);
+
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["+15551230000"] } } },
+        senderId: "+15551239999",
+        action: "approve",
+        approvalKind: "exec",
+      }),
+    ).toEqual({
+      authorized: false,
+      reason: "❌ You are not authorized to approve exec requests on iMessage.",
+    });
+  });
+
+  it("authorizes lowercase-normalized email senders against canonical allowFrom", () => {
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["Owner@Example.com"] } } },
+        senderId: "owner@example.com",
+        action: "approve",
+        approvalKind: "plugin",
+      }),
+    ).toEqual({ authorized: true });
+  });
+
+  it("falls back to implicit same-chat authorization when no allowFrom is configured", () => {
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: { channels: { imessage: { allowFrom: [] } } },
+      }),
+    ).toEqual([]);
+
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: [] } } },
+        senderId: "+15551230000",
+        action: "approve",
+        approvalKind: "exec",
+      }),
+    ).toEqual({ authorized: true });
+  });
+
+  it("supports explicit wildcard approval approvers", () => {
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["*"] } } },
+        senderId: "+15551230000",
+        action: "approve",
+        approvalKind: "plugin",
+      }),
+    ).toEqual({ authorized: true });
+  });
+
+  it("strips imessage:/sms:/auto: service prefixes when normalizing approver entries", () => {
+    // The resolved approver list itself must contain the bare normalized
+    // handle — a previous bug rejected service-prefixed entries entirely,
+    // which silently fell back to the empty-approvers implicit-same-chat
+    // authorization and masked the regression. Assert the explicit list here
+    // so reaction resolution (which requires a non-empty approver list) works
+    // for service-prefixed allowFrom values too.
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: { channels: { imessage: { allowFrom: ["imessage:+15551230000"] } } },
+      }),
+    ).toEqual(["+15551230000"]);
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: { channels: { imessage: { allowFrom: ["sms:+15551230001"] } } },
+      }),
+    ).toEqual(["+15551230001"]);
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: { channels: { imessage: { allowFrom: ["auto:Owner@Example.com"] } } },
+      }),
+    ).toEqual(["owner@example.com"]);
+
+    // A sender that matches the normalized handle is explicitly authorized
+    // (not via the implicit same-chat fallback).
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["imessage:+15551230000"] } } },
+        senderId: "+15551230000",
+        action: "approve",
+        approvalKind: "exec",
+      }),
+    ).toEqual({ authorized: true });
+
+    // And a NON-matching sender is rejected — proving the entry was added
+    // to the approver list rather than collapsing to empty.
+    expect(
+      imessageApprovalAuth.authorizeActorAction({
+        cfg: { channels: { imessage: { allowFrom: ["imessage:+15551230000"] } } },
+        senderId: "+15559999999",
+        action: "approve",
+        approvalKind: "exec",
+      }),
+    ).toEqual({
+      authorized: false,
+      reason: "❌ You are not authorized to approve exec requests on iMessage.",
+    });
+  });
+
+  it("rejects chat_id / chat_guid / chat_identifier as approver entries even with service prefixes", () => {
+    expect(
+      getIMessageApprovalApprovers({
+        cfg: {
+          channels: {
+            imessage: {
+              allowFrom: [
+                "chat_id:42",
+                "chat_guid:iMessage;+;chat42",
+                "chat_identifier:chat42@example.com",
+                "imessage:chat_id:43",
+              ],
+            },
+          },
+        },
+      }),
+    ).toEqual([]);
+  });
+});
@@ -0,0 +1,78 @@
+import {
+  createResolvedApproverActionAuthAdapter,
+  resolveApprovalApprovers,
+} from "openclaw/plugin-sdk/approval-auth-runtime";
+import { resolveIMessageAccount } from "./accounts.js";
+import { normalizeIMessageHandle } from "./targets.js";
+
+type ApprovalKind = "exec" | "plugin";
+
+export function normalizeIMessageApproverId(value: string | number): string | undefined {
+  const raw = String(value).trim();
+  if (!raw) {
+    return undefined;
+  }
+  // Normalize first so service-prefixed direct handles (`imessage:+...`,
+  // `sms:+...`, `auto:+...`) are stripped to their bare identifier before we
+  // decide whether to reject the entry. After normalization only the
+  // conversation-target prefixes (chat_id / chat_guid / chat_identifier) remain
+  // as illegal approver shapes — service-prefixed direct handles are valid
+  // approver values that map to a specific phone/email.
+  const normalized = normalizeIMessageHandle(raw);
+  if (
+    !normalized ||
+    normalized.startsWith("chat_id:") ||
+    normalized.startsWith("chat_guid:") ||
+    normalized.startsWith("chat_identifier:")
+  ) {
+    return undefined;
+  }
+  return normalized;
+}
+
+function normalizeIMessageApproverEntry(value: string | number): string | undefined {
+  return String(value).trim() === "*" ? "*" : normalizeIMessageApproverId(value);
+}
+
+export function getIMessageApprovalApprovers(params: {
+  cfg: Parameters<typeof resolveIMessageAccount>[0]["cfg"];
+  accountId?: string | null;
+}): string[] {
+  const account = resolveIMessageAccount({ cfg: params.cfg, accountId: params.accountId });
+  return resolveApprovalApprovers({
+    allowFrom: account.config.allowFrom,
+    normalizeApprover: normalizeIMessageApproverEntry,
+  });
+}
+
+const imessageResolvedApproverAuth = createResolvedApproverActionAuthAdapter({
+  channelLabel: "iMessage",
+  resolveApprovers: ({ cfg, accountId }) => getIMessageApprovalApprovers({ cfg, accountId }),
+  normalizeSenderId: (value) => normalizeIMessageApproverId(value),
+});
+
+export const imessageApprovalAuth = {
+  authorizeActorAction({
+    cfg,
+    accountId,
+    senderId,
+    approvalKind,
+  }: {
+    cfg: Parameters<typeof resolveIMessageAccount>[0]["cfg"];
+    accountId?: string | null;
+    senderId?: string | null;
+    action: "approve";
+    approvalKind: ApprovalKind;
+  }) {
+    if (getIMessageApprovalApprovers({ cfg, accountId }).includes("*")) {
+      return { authorized: true } as const;
+    }
+    return imessageResolvedApproverAuth.authorizeActorAction({
+      cfg,
+      accountId,
+      senderId,
+      action: "approve",
+      approvalKind,
+    });
+  },
+};