Add native iMessage poll support

[veteranbv]

I use imsg as the iMessage bridge for Wit/OpenClaw. Text messages already cover a lot of the workflow, but native Apple Messages polls are a better fit for the moments where the agent needs a quick decision from me.

The main use case is approval. Wit often needs to ask before it creates inferred tasks, sends something externally, handles a draft, recommends X bookmarks, prioritizes work, or takes an operational step that should not happen silently. Text commands work, but they are clunky on mobile and easier to misread. A native poll gives me a clear list of options, a one-tap response, and an auditable event that OpenClaw can route into Linear or the right approval queue.

What I would like imsg to support:

• decode native poll creation messages from Apple Messages extension balloon rows
• decode vote updates and tie them back to the original poll
• expose structured poll events through history and watch without breaking existing message fields
• send native polls through CLI/RPC when the injected bridge is available

This would make polls a first-class approval layer for safer autonomy while keeping imsg useful as a clean, stable bridge for downstream clients.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Latest ClawSweeper review: 2026-05-24 06:08 UTC / May 24, 2026, 2:08 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• 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.

Summary
Keep open because current main does not provide native iMessage poll decoding, vote correlation, structured poll events, or poll sending, and an open linked PR explicitly owns the proposed implementation path. This needs maintainer/API review of the linked implementation rather than closing the issue early.

Reproducibility: not applicable. this is a feature request rather than a bug report. Source inspection of current main shows the requested poll event and send surfaces are absent, and an open linked PR is the current implementation candidate.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Next step
An open linked PR already owns the implementation, and the remaining decision is maintainer review of the new poll API/schema and private Messages payload compatibility.

Review details

Best possible solution:

Review and either land or revise the linked poll-support PR with an additive event schema, real poll fixtures, bridge capability gating, and compatibility tests for existing history/watch/send behavior.

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

Not applicable; this is a feature request rather than a bug report. Source inspection of current main shows the requested poll event and send surfaces are absent, and an open linked PR is the current implementation candidate.

Is this the best way to solve the issue?

Unclear; native poll support is a plausible fit for the bridge, but the best implementation requires maintainer API and compatibility review of the linked PR before this issue can close.

Label changes:

• remove clawsweeper:linked-pr-open: Current issue advisory state no longer selects this label.

Label justifications:

• P3: This is an optional new capability for approval workflows, with no current regression or broken documented behavior on main.

Acceptance criteria:

• Review linked PR fixtures for native poll creation and vote update rows.
• Verify existing history/watch/send JSON remains backward-compatible for non-poll messages.
• Validate bridge poll send behavior on a SIP-disabled macOS setup with redacted live output.

What I checked:

• Issue asks for first-class poll read/write support: The issue body requests decoding native poll creation rows, decoding vote updates, exposing structured poll events through history/watch, and sending native polls through CLI/RPC.
• Open linked implementation PR: The GitHub context shows Add native iMessage poll support #125 is open, authored by the reporter, and its body uses closing syntax for this issue while proposing decode/send/RPC/docs/tests support for polls.
• Current JSON model has no poll fields: Current main's output message models expose message routing/text/attachments/replies/reactions but no poll/options/vote event shape. (Sources/imsg/OutputModels.swift:56, fbae9cd746ad)
• Current message query only treats balloon rows as URL previews: The message read path selects balloon_bundle_id and only uses com.apple.messages.URLBalloonProvider to suppress duplicate URL preview rows, not to decode poll extension payloads. (Sources/IMsgCore/MessageStore+Messages.swift:198, fbae9cd746ad)
• Current RPC method list has no poll send method: RPC methods include history, watch, send, send.rich, send.attachment, tapback, edit, unsend, and others, but no poll.send or messages.poll.send method on main. (Sources/imsg/RPCServer.swift:29, fbae9cd746ad)
• Bridge protocol has no poll action: BridgeAction cases cover message send, multipart, attachments, reactions, replies, edits, unsend, chats, and contacts, but no poll action. (Sources/IMsgCore/IMsgBridgeProtocol.swift:32, fbae9cd746ad)

Likely related people:

• veteranbv: The reporter opened the linked implementation PR that explicitly closes this issue and describes the proposed poll decode/send/RPC/docs/test work. (role: proposer and linked implementation author; confidence: high; commits: c99830584cea; files: Sources/imsg/OutputModels.swift, Sources/IMsgCore/MessageStore+Messages.swift, Sources/imsg/RPCServer.swift)
• Codex: Recent main history and blame in the message output/read/RPC surfaces are dominated by Codex-authored commits, including current model and bridge protocol work adjacent to the requested poll support. (role: recent area contributor; confidence: medium; commits: fbae9cd746ad, b85e701f2b0b; files: Sources/imsg/OutputModels.swift, Sources/IMsgCore/MessageStore+Messages.swift, Sources/imsg/RPCServer.swift)

Remaining risk / open question:

• Native Messages poll support depends on private Apple Messages extension payload behavior and an injected bridge send path, so schema and delivery compatibility need maintainer review before merge.
• The open linked PR may solve the issue, but it is not merged; closing the issue before that PR lands would lose the canonical tracking thread.

Codex review notes: model gpt-5.5, reasoning high; reviewed against fbae9cd746ad.