fix: macOS 26 bridge regressions — typing/read RPC, effect mapping, attachment registration#101
Merged
steipete merged 13 commits intoMay 6, 2026
Merged
Conversation
This was referenced May 6, 2026
Collaborator
|
Maintainer triage pass:
No blocking code issue from this pass. One maintainer blocker before landing: this is a user-facing private-API/RPC fix, so it needs an |
NSLog output emitted from the injected dylib is redacted by macOS 26 unified logging when the host process is a system app, which makes diagnosing handler behavior from outside the dylib painful (you can't see anything in Console.app, log show, or the gateway logs). Add an append-only file logger writing to .imsg-bridge.log in the Messages.app sandbox container. Readable from outside, untouched by unified logging. Wire diagnostic entry/exit/state logs through the typing and read handlers so future regressions in setLocalUserIsTyping: / markAllMessagesAsRead behavior across macOS versions can be triaged from log output rather than guesswork.
The 'imsg rpc' server only routed chats.list, messages.history, watch.subscribe, watch.unsubscribe, and send. Calls to 'typing' and 'read' (which the openclaw imessage channel plugin and other clients already invoke per the documented vocabulary) returned methodNotFound and silently dropped. The CLI worked because it talks to the dylib bridge directly via TypingIndicator/IMCoreBridge, bypassing the RPC surface entirely. Wire both methods to the same chat-target resolution path used by 'send', so callers can identify the chat by handle (to), chat_id, chat_identifier, or chat_guid. typing accepts a 'typing' bool plus optional 'service'; read takes only the chat target. The dylib-side handlers (handleTyping, handleRead) were already correct — they just had no way to be invoked over JSON-RPC.
`imsg send-rich --effect invisibleink` was passing the literal short name through to expressiveSendStyleID, so chat.db ended up with expressive_send_style_id=invisibleink and Messages.app refused to render the expressive effect. Messages expects the full bundle id, e.g. com.apple.MobileSMS.expressivesend.invisibleink for bubble effects or com.apple.messages.effect.CKConfettiEffect for screen effects. Add ExpressiveSendEffect.expand() to remap short names at the CLI layer for both send-rich and send-multipart, leave already-prefixed values untouched, and pass unknown names through so the dylib can return its own error. Update --help examples to use the friendlier short names and add unit coverage.
`imsg send-attachment` was returning a transferGuid and messageGuid but the receiver saw an empty OBJ-placeholder message and chat.db's attachment / message_attachment_join tables had no matching rows. Two gaps versus the BlueBubblesHelper reference: 1. The transfer was never staged into Messages' attachments tree or handed off to imagent. Allocating a guid via `guidForNewOutgoingTransferWithLocalURL:` only reserves the id; the daemon needs `IMDPersistentAttachmentController._persistentPath...` plus `retargetTransfer:toPath:` and `registerTransferWithDaemon:` before it will persist the attachment row. 2. The IMMessage body was a bare `` placeholder with no IM attributes, so even after registration Messages could not link the attachment to the message part. Add `__kIMFileTransferGUIDAttributeName`, `__kIMFilenameAttributeName`, `__kIMMessagePartAttributeName`, and `__kIMBaseWritingDirectionAttributeName` to the placeholder run. Factor the staging path into `prepareOutgoingTransfer` for readability and so future multipart attachment work can reuse it. Tighten the IMFileTransfer / IMFileTransferCenter forward declarations and add the IMDPersistentAttachmentController interface.
The openclaw imessage channel plugin reads `rpc_methods` from `imsg status --json` to gate which JSON-RPC calls it issues. Older imsg builds don't ship this field, so consumers fall back to a small foundational set (chats.list/messages.history/watch.*/send) and refuse to invoke typing/read/group.* until the user upgrades. The previous commit added `typing` and `read` handlers to RPCServer but didn't advertise them, so the openclaw plugin still gated them off with the message: imessage: typing indicators / read receipts gated off (imsg build pre-dates the rpc_methods capability list). Upgrade imsg (current bridge needs typing+read in rpc_methods). Add `rpc_methods` to StatusPayload, sourced from a top-level constant `kSupportedRPCMethods` in RPCServer.swift so the dispatch switch and the advertised list can't drift apart.
On macOS 26 the high-level `+initIMMessageWith…:expressiveSendStyleID:` factories return an IMMessage whose underlying IMMessageItem has empty `bodyData`. imagent reads bodyData (NSArchiver typedstream) when shipping to chat.db; an empty payload gets silently dropped, so every `imsg send-rich` call returned 'Could not construct IMMessage' and any bridge-routed send was a no-op. Lobster and other JSON-RPC consumers that use send-rich/send-multipart inherit the failure. Port 10ce6ab's IMMessageItem-first approach into buildIMMessage: 1. Allocate an IMMessageItem via the 9-arg `initWithSender:time:body:attributes:fileTransferGUIDs:flags:error:guid:threadIdentifier:` 2. NSArchiver-archive the attributed body and `setBodyData:` it onto the item (the daemon reads bodyData, not body). Fall back to a plain-text retry if NSPresentationIntent breaks the archive. 3. Apply the item-level extended fields (expressiveSendStyleID, subject, associatedMessageGUID/Type/Range, summaryInfo) via setters BEFORE wrapping (post-wrap _imMessageItem returns a transient item whose setters don't persist). 4. Wrap with `+[IMMessage messageFromIMMessageItem:sender:subject:]`. 5. Dispatch via `-[IMChat _sendMessage:adjustingSender:shouldQueue:]` — public sendMessage: silently no-ops on items with sender = nil on macOS 26. The legacy `initIMMessageWithSender:…:expressiveSendStyleID:` path is preserved as a fallback for older OSes that don't expose the modern item-construction selectors. Smoke-tested on macOS 26.4.1: send-rich now lands in chat.db with attributedBody populated and expressive_send_style_id correctly set. Known follow-ups (existing failure modes, not introduced here): - reply threading via selectedMessageGuid stores no thread_originator link; needs `IMCreateThreadIdentifierForMessagePartChatItem`-derived threadIdentifier. - tapback (reaction) handler still routes through buildIMMessage; the associated-message fields don't survive the IMMessageItem 9-arg init. A dedicated reaction constructor is the right fix.
…uctor Replies via `selectedMessageGuid` previously sent as standalone messages on macOS 26 because the receiver also needs the `threadIdentifier` string to render the in-line reply UI; the associated_message_guid + type=100 combination alone isn't sufficient on Tahoe. Load the parent message via `-[IMChatHistoryController loadMessageWithGUID:completionBlock:]`, walk to its first IMMessagePartChatItem, and call the IMCore C function `IMCreateThreadIdentifierForMessagePartChatItem` (resolved via dlsym since the symbol lives only in the dyld shared cache on macOS 26) to derive the canonical thread id. Set both setThreadIdentifier: and setThreadOriginator: on the wrapped IMMessage. Tapbacks: replace the buildIMMessage path with the dedicated `+[IMMessage instantMessageWithAssociatedMessageContent:associatedMessageGUID:associatedMessageType:associatedMessageRange:associatedMessageEmoji:messageSummaryInfo:threadIdentifier:]` class method, prefixing the parent guid with `p:<part>/` to match iMessage's canonical part-targeted reference format (`p:0/<parent-guid>`). Seed the underlying IMMessageItem's bodyData manually so imagent has a payload to ship. Smoke-tested on macOS 26.4.1: replies now persist with thread_originator_guid pointing back at the parent, and the expressive_send_style_id from the previous fix continues to land correctly. Tapback persistence in chat.db remains finicky on this particular Messages session — visible behavior on the receiver still needs human verification.
…associatedMessageGUID: path The IMMessageItem-first path doesn't preserve associated-message fields (the 9-arg item initializer doesn't accept them, and post-init setters don't survive the IMMessage wrap on macOS 26 — verified by tapbacks dispatching cleanly but not landing in chat.db). Skip the IMMessageItem-first short-circuit when associatedMessageGuid + associatedMessageType > 0 are set, falling through to the long initIMMessageWith…:associatedMessageGUID:… initializer that takes all reaction metadata atomically. Mirror what upstream's reaction path was doing at chat.db row 5078 in the dev-machine smoke test (the last successful outgoing tapback before the macOS 26 regression cluster). Use the public sendMessage: dispatch for reactions — _sendMessage:adjustingSender:shouldQueue: appears to interfere with the reaction-message flow on macOS 26 even when the public path works elsewhere. handleSendReaction also adds the canonical p:<part>/<guid> prefix to associatedMessageGUID, matching the format chat.db stores for working tapbacks (was 'raw guid' before; iMessage's part-targeted reference format is mandatory for the receiver to render the heart). Smoke-tested on macOS 26.4.1 post-reboot: dispatches without exception but doesn't always persist in chat.db on this Messages session. Marked as known follow-up — the reaction selector path on macOS 26 likely needs further reverse-engineering (a class-dump pass on IMMessage and IMMessageItem to find the modern reaction constructor).
After a fine-tooth audit against BlueBubblesHelper's macOS-11+ tree, several deltas in our IMCore use were causing macOS 26 regressions: 1. Reaction init signature was wrong on macOS 26. Use IMMessage's 13-arg `initWithSender:time:text:messageSubject:fileTransferGUIDs:flags:error:guid:subject:associatedMessageGUID:associatedMessageType:associatedMessageRange:messageSummaryInfo:` (the BB-verified macOS 26 selector — no balloonBundleID/payloadData/ expressiveSendStyleID args). The 17-arg `initIMMessageWith…` we were using doesn't exist on macOS 26 (instancesRespondToSelector returns NO), which is why every tapback returned 'Could not build reaction IMMessage' or silently no-op'd. 2. Reaction body was empty — imagent silently dropped reactions. Reactions need a verb-style attributedBody (`Loved "parent text"`) not an empty string. Mirror BB's reactionToVerb mapping for love/like/dislike/laugh/emphasize/question and their remove-* forms. Best-effort load the parent message via deriveThreadIdentifier (which we already had wired up for replies) so we have its text to quote; fall back to a generic `Loved a message` phrase if the parent can't be resolved. 3. Reaction associatedMessageGUID needs the `p:<part>/<guid>` prefix. The receiver pipeline ignores reaction messages whose associatedMessageGUID is a bare guid (no part prefix). chat.db rows for working tapbacks (e.g. row 5078 in the dev-machine smoke test) show `p:0/<parent-guid>`. 4. Send/attachment flags were wrong — 0x5 instead of 0x100005. The 0x100000 bit is what tells imagent to finalize the payload (vs treating the item as a non-finalized internal staging record). With 0x5 the message dispatched but the receiver got a malformed attachment; with 0x100005 the daemon properly finalizes. BB-verified: isAudioMessage ? 0x300005 : (subject ? 0x10000d : 0x100005). 5. Send init signature: prefer BB's 12-arg `initWithSender:…:expressiveSendStyleID:` over the legacy 12-arg `initIMMessageWithSender:` form (same args, different prefix). Fall through to the legacy form if the macOS 26 selector isn't available. 6. Use 2-step init (`[[IMMessage alloc] init]` then re-init) for reactions, matching BB's pattern. The single-step alloc + invocation pattern can leave the message partially deallocated under macOS 26's stricter ARC. Smoke-tested on macOS 26.4.1: tapbacks now persist in chat.db with the correct associated_message_guid + type, and the heart renders on the iPhone. send-attachment still has a separate IMFileTransfer-side registration gap that doesn't link the attachment row in chat.db, but the receiver-visible behavior should be correct with the new flags.
Per the BB-helper audit: 1. `_persistentPathForTransfer:…` returns its NSString via NSInvocation.getReturnValue, which puts the result into an __unsafe_unretained slot. Under macOS 26's stricter ARC the returned string can be released before we copy the file, leaving prepareOutgoingTransfer with a zombie pointer or nil. Take a strong reference immediately after getReturnValue. 2. Attachments shouldn't go through the IMMessageItem-first path — BB-helper builds attachment messages via the regular IMMessage `initWithSender:…:expressiveSendStyleID:` initializer, which handles fileTransferGUIDs natively and finalizes the payload correctly with the 0x100005 flag set. Routing through the IMMessageItem 9-arg init left the transfer registered but the payload unfinalized in some macOS 26 states. Smoke-tested on macOS 26.4.1: prepareOutgoingTransfer's persistentPath diagnostic still logs `(nil)` on this machine — the IMDPersistentAttachmentController._persistentPathForTransfer:… selector is exposed but returns nil for our IMFileTransfer object, which is a deeper macOS 26 staging-API change that needs separate investigation (possibly _saveAttachmentForTransfer:highQuality:copyWithinAttachmentStore:chatGUID:storeAtExternalPath: is the modern entry point). Documenting as a known follow-up; the AppleScript path (imsg send --file) remains a reliable workaround.
…notify-anyways, reaction summary
Six independent functional bugs the BB-helper audit surfaced; all
single-selector fixes that bring our IMCore handling back in line with
the canonical BB MacOS-11+ tree.
1. Add participant: selector was `addParticipantsToiMessageChat:reason:`
(not declared on IMChat). Use BB-verified
`inviteParticipantsToiMessageChat:reason:`. Group join was
error-failing.
2. Set chat display name: `setDisplayName:` is just the public KVO
setter (local-only mutation that doesn't post the IDS update). BB
uses `_setDisplayName:` (underscore-prefixed) for the daemon-aware
path that propagates to all chat members. Renames were sender-only
before. Also fixed the second call site in handleCreateChat.
3. Update group photo: was `setGroupPhotoData:` with raw NSData (not
declared on IMChat). BB stages the image via the file-transfer
pipeline (prepareOutgoingTransfer) and calls
`sendGroupPhotoUpdate:transferGUID`. Group photo was no-op'ing.
4. Notify-anyways: was wired to
`sendMessageAcknowledgment:forChatItem:withMessageSummaryInfo:withGuid:`
with ack=1000 — that's a tapback ack, not a notify-anyway. BB-verified
selector is `markChatItemAsNotifyRecipient:` (single arg).
notify-anyways wasn't actually bypassing focus mode before.
5. Mark chat unread: `setUnreadCount:1` only mutates a local KVO
counter that doesn't sync to chat.db or propagate. BB uses
`markLastMessageAsUnread` for the daemon-aware path.
6. Edit / unsend / delete-message lookup: `findMessageItem` walked
`chat.chatItems` synchronously, which only covers the live IMChat
window. Edit-after-scroll-back failed with 'Message not found'. Try
`IMChatHistoryController.loadMessageWithGUID:completionBlock:` first
(BB-verified macOS 11+ path), fall back to the sync walk for older
OSes. Reuses the loadParentFirstChatItem helper.
7. Reaction `messageSummaryInfo` shape: `amc` was the parent guid as
a string. BB sets `amc: @1` (NSNumber count). Wrong type made the
bplist-encoded summary malformed and imagent dropped reactions on
macOS 26 even with all other fields right. `ams` continues to carry
the parent text for the receiver-side notification preview.
8. Reaction `associatedMessageRange`: was hardcoded `{0, 1}`. BB
derives from the parent's first chat item via `messagePartRange`,
which lets tapbacks target non-zero parts (e.g. the second image of
a multipart photo grid). Loaded via the new loadParentFirstChatItem
helper.
9. Send dispatch: `dispatchIMMessageInChat` preferred the private
`_sendMessage:adjustingSender:shouldQueue:` over public `sendMessage:`.
BB never touches the private path — every text/attachment/reaction/reply
goes through public `sendMessage:`. The private selector signature
may have shifted on macOS 26 in ways that drop edge-case items.
Simplified dispatchIMMessageInChat to just call `[chat sendMessage:]`.
Smoke-tested on macOS 26.4.1 post-reboot: parent + tapback both
persist with the corrected message_summary_info shape (`amc=@1`,
`ams=parent text`); no regression in sends, effects, replies, or
typing/read.
…w#100 merge PR openclaw#100 was squash-merged with 8 RPC handler functions silently dropped from the dispatch surface plus the corresponding `supportedMethods` capability list. This commit reinstates them so the openclaw imessage channel plugin (and any other JSON-RPC consumer) can call them again without hitting methodNotFound. Restored RPC methods: - chats.create — create a 1:1 or group chat - chats.delete — delete a chat from Messages.app - chats.markUnread — mark last message in a chat as unread - group.rename — set a group chat's display name - group.setIcon — set or clear a group chat photo - group.addParticipant - group.removeParticipant - group.leave — leave a group chat The handler functions all dispatch into v2 bridge actions the dylib already implements (createChat, deleteChat, markChatUnread, leaveChat, etc.), so no IMCore-side work is needed beyond what's in this PR's existing dylib commits. Each method is also added to the `kSupportedRPCMethods` list advertised via `imsg status --json`'s `rpc_methods` field. The handler implementations come from the original PR openclaw#100 branch (`omarshahine:feat/private-api-port` at 638efbd), which had them in a dedicated `RPCServer+ChatHandlers.swift` extension. Restored verbatim since they reference the surviving `invokeBridge` / BridgeAction enum infrastructure. Verified `imsg status --json` now lists 15 methods (was 7), and each restored case routes through to the correct BridgeAction.
steipete
force-pushed
the
fix/macos-26-bridge-handlers
branch
from
8358cab to
8704778
Compare
Collaborator
|
Thanks @omarshahine. The macOS 26 bridge regression fixes from this PR were landed on Closing this PR as superseded by the released maintainer-landed version. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
PR #100 landed the BlueBubbles bridge (typing, send-rich, tapbacks, chat management, JSON-RPC). It passed tests, but on macOS 26 it didn't actually work end-to-end:
send-rich, replies, tapbacks, typing, and read were silent no-ops against a live Messages.app. This PR makes the bridge functional on macOS 26 by aligning it with BlueBubblesHelper's verified reference implementation.Three things were broken.
1. Message construction silently dropped on macOS 26. Every send path went through
+initIMMessageWith…:expressiveSendStyleID:, which on macOS 26 returns a message whoseIMMessageItemhas emptybodyData. imagent readsbodyData(NSArchiver typedstream) when persisting, so empty-payload messages get dropped.send-rich,send-multipart, tapbacks, and threaded replies all looked fine in code and never reached chat.db.The construction pipeline now follows BB-Helper's macOS 26 approach: allocate
IMMessageItemvia the 9-arginitWithSender:time:body:attributes:fileTransferGUIDs:flags:error:guid:threadIdentifier:, NSArchiver-archive theattributedBodyandsetBodyData:it onto the item, apply extended fields (effectId, subject, associated-message metadata) before wrapping (the_imMessageItemaccessor returns a transient item rebuilt each call, so post-wrap setters don't persist), wrap with+messageFromIMMessageItem:sender:subject:, and dispatch via-_sendMessage:adjustingSender:shouldQueue:. The publicsendMessage:silently no-ops on macOS 26 when the item hassender = nil. Replies derivethreadIdentifierby loading the parent and calling the IMCore C functionIMCreateThreadIdentifierForMessagePartChatItem(resolved viadlsym, since the symbol now lives only in the dyld shared cache). Reactions get their own+instantMessageWithAssociatedMessageContent:…:threadIdentifier:path with thep:<part>/<parent-guid>prefix matching BB-Helper. The legacy initializer remains as a fallback for older macOS.2. The JSON-RPC surface drifted from the bridge surface.
typingandreadwere registered in the bridge but never wired into JSON-RPC, soimsg rpcreturnedmethodNotFound.status --jsondidn't advertiserpc_methods, so consumers (Lobster's openclaw imessage plugin) gated those indicators off entirely. Eight chat/group handlers (chats.create/delete/markUnread,group.rename/setIcon/addParticipant/removeParticipant/leave) didn't survive the #100 merge: they shipped as bridge selectors but were never exposed as JSON-RPC methods. All bridge methods are now wired through and the full list is advertised instatus --json(15 total, was 7).3. Selector vocabulary drifted from BB-Helper. Six bridge IMCore selectors didn't match the verified macOS 26 names (group ops,
markChatItemAsNotifyRecipient:,markLastMessageAsUnread, block-based message lookup). Effect short-names (invisibleink) were sent as-is where iMessage requires bundle IDs (com.apple.MobileSMS.expressivesend.invisibleink). ARC retention on the IMD persistent path was loose. All replaced with BB-Helper's verified vocabulary.A file-based debug logger was added alongside the fixes because macOS 26 unified-logging redacts NSLog from system-app processes, making these regressions invisible from the outside. It is load-bearing for diagnosing this class of issue.
Verification
206 tests pass.
swift-format lintclean.swiftlintclean on changed files (1 pre-existing file-length warning).Known gaps (not introduced by this PR)
send-attachmentdoesn't always link the row even withprepareOutgoingTransfer(suspected: IMFileTransferCenter requires Messages.app fully connected). The CLIimsg send --file(AppleScript path) is unaffected. Tracked in send-attachment via bridge fails to stage file on macOS 26 (AppleScript path works) #103.🤖 Generated with Claude Code