Best possible solution:

Land this narrow send-boundary fix after maintainer handling, then let it close #92142 when merged.

Do we have a high-confidence way to reproduce the issue?

Yes for source-level reproduction: current main forwards final-delivery replyToId into the iMessage sender, and the sender serializes it as reply_to without checking actions.reply. I did not run live SIP-enabled macOS/iMessage proof in this read-only review.

Is this the best way to solve the issue?

Yes. Gating at sendMessageIMessage is the narrow shared choke point for text, media, attached-result, and monitor final-delivery callers, and it reuses the existing actions.reply contract instead of adding a new config mode.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 50c82b302006.

Label changes:

• add P2: The PR fixes a concrete iMessage message-delivery failure with channel-specific blast radius rather than a core-wide outage.
• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The live PR is labeled maintainer, so the external contributor proof gate is not applied; the PR body still records focused test, formatter, and diff-check verification.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦞 diamond lobster, so this older rating label is no longer current.
• remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P2: The PR fixes a concrete iMessage message-delivery failure with channel-specific blast radius rather than a core-wide outage.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The live PR is labeled maintainer, so the external contributor proof gate is not applied; the PR body still records focused test, formatter, and diff-check verification.

PR surface:

Source +2, Tests +53. Total +55 across 2 files.

What I checked:

• Repository policy read and applied: Root AGENTS.md and scoped extensions/AGENTS.md were read fully; the extension boundary, whole-path review, protected maintainer label, and proof/compatibility rules shaped this review. (AGENTS.md:1, 50c82b302006)
• Live PR diff is narrow after force-push: Live GitHub diff for head eddf034548553c6fd97ed25cca61a4e15234375e changes only extensions/imessage/src/send.ts and extensions/imessage/src/send.test.ts; the earlier coalescing config/doctor teardown noted by the old ClawSweeper comment is not present in the current patch. (extensions/imessage/src/send.ts:952, eddf03454855)
• Current main has the source-reproducible bug: Current main sends payload.replyToId into sendMessageIMessage for text and media final replies, and sendMessageIMessage unconditionally sanitizes it before later writing params.reply_to. (extensions/imessage/src/monitor/deliver.ts:48, 50c82b302006)
• Existing config contract supports the gate: The iMessage config type and zod schema already include actions.reply, account resolution merges channel/account config, and createActionGate treats an explicit false as disabled while defaulting undefined to enabled. (src/config/types.imessage.ts:20, 50c82b302006)
• PR head gates at the shared send boundary: At PR head, sendMessageIMessage calls createActionGate(account.config.actions)("reply") before preserving reply metadata, so text RPC sends, attachment sends, receipts, and the recursive caption path all see the same resolved value. (extensions/imessage/src/send.ts:952, eddf03454855)
• PR tests cover the disabled-action boundary: The added tests assert that actions.reply: false removes RPC reply_to, attachment --reply-to, and receipt reply metadata for text and media sends. (extensions/imessage/src/send.test.ts:124, eddf03454855)

Likely related people:

• steipete: Git history shows the largest share of recent iMessage sender/channel touches, plus media-send work and iMessage private-API documentation near this boundary. (role: feature introducer and adjacent owner; confidence: high; commits: 3bb02d333865, d85b2a0e8148, 63cbc097b5ca; files: extensions/imessage/src/send.ts, extensions/imessage/src/channel.ts, docs/channels/imessage.md)
• mvanhorn: git log identifies commit e0972db7a292 as prior iMessage outbound reply-tag work in the same sender module. (role: reply metadata contributor; confidence: medium; commits: e0972db7a292; files: extensions/imessage/src/send.ts)
• scoootscooob: Commit 0ce23dc62d37 moved the iMessage channel into extensions/imessage, carrying the current plugin-owned send and final-delivery paths. (role: delivery path refactor contributor; confidence: medium; commits: 0ce23dc62d37; files: extensions/imessage/src/send.ts, extensions/imessage/src/monitor/deliver.ts)
• vincentkoc: Commit 049bb37c6296 lazy-loaded iMessage channel runtime paths adjacent to the outbound send boundary, and current release snapshots also carry the active files. (role: recent runtime routing contributor; confidence: medium; commits: 049bb37c6296, 8c802aa68351; files: extensions/imessage/src/channel.runtime.ts, extensions/imessage/src/send.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.