feat: port BlueBubbles private-API surface as imsg bridge (fixes #60)#100
Merged
Conversation
Adds a manual port of the BlueBubbles private-API surface as a v2 bridge on top of the existing AppleScript send path. None of BlueBubbles' source or binaries are vendored — the API vocabulary (send-rich, tapback, chat-mark, etc.) is preserved so existing BB-targeting tooling can talk to imsg directly. Bridge is opt-in (SIP off + injected helper dylib) and does not affect default send/history/watch/rpc flows. The bridge runs in-process within Messages.app, so calls like setLocalUserIsTyping: use Messages.app's own entitlements and bypass imagent's private-entitlement check (the macOS 26 / Tahoe regression that breaks third-party typing-indicator clients). v2 IPC replaces v1's single-file polling with a per-request UUID-keyed queue under ~/Library/Containers/com.apple.MobileSMS/Data/.imsg-rpc/. IMSG_BRIDGE_LEGACY_IPC=1 keeps v1 callable for un-rebuilt dylibs.
Ports the technique from Nicell's BlueBubbles-Server-Helper PR openclaw#50 (BlueBubblesApp/bluebubbles-helper#50) into our dylib. Adds a `buildFormattedAttributed` helper that applies the private IMText* attribute names by NSRange: - __kIMTextBoldAttributeName - __kIMTextItalicAttributeName - __kIMTextUnderlineAttributeName - __kIMTextStrikethroughAttributeName Gated to macOS 15+ via NSProcessInfo.operatingSystemVersion since the private attribute names don't exist before Sequoia. Pre-Sequoia callers silently fall through to plain text rather than crashing. Wired through both handleSendMessage (top-level `textFormatting` param) and handleSendMultipart (per-part `textFormatting` on each parts entry). CLI: new --format and --format-file flags on `imsg send-rich` taking a JSON ranges array of {start, length, styles[]}. Also folds in linter fixes that arrived between commits — invokeAndEmit now throws an EmittedError sentinel so the CLI returns 1 without double-printing the error. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…g conflict - IMsgInjected.m: set associatedMessageType=100 when selectedMessageGuid is present so replies thread correctly (was hardcoded to 0). - IMsgInjected.m: rich-text sends now also carry __kIMBaseWritingDirectionAttributeName="-1" across the full string, matching plain sends so formatted text behaves identically. - BridgeChatCommands.swift: chat-mark now rejects conflicting --read/--unread instead of silently defaulting to --read; covered by new chatMarkRejectsConflictingFlags test. - BridgeMessagingCommands.swift: trim verbose --format help text.
omarshahine
added a commit
to omarshahine/imsg
that referenced
this pull request
May 6, 2026
…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
pushed a commit
to omarshahine/imsg
that referenced
this pull request
May 6, 2026
…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
added a commit
that referenced
this pull request
May 6, 2026
…ttachment registration (#101) * feat: file-based debug logger for in-process diagnostics 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. * fix(rpc): expose typing and read methods over JSON-RPC 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. * fix: expand --effect short names to expressive-send bundle IDs `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. * fix: register outgoing transfers properly in handleSendAttachment `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. * fix(rpc): advertise rpc_methods capability in status --json 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. * fix: build IMMessageItem first to survive macOS 26 send pipeline 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. * fix: derive thread identifier for replies + dedicated reaction constructor 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. * fix(react): route reactions through legacy initIMMessageWithSender:…: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). * fix: BlueBubblesHelper-verified macOS 26 selectors + reaction body 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. * fix(attachment): tighten ARC retention + skip IMMessageItem-first 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. * fix: BlueBubblesHelper-aligned selectors for group ops, mark-unread, 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. * fix(rpc): restore chat/group lifecycle handlers cut during PR #100 merge PR #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 #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. * docs: note macOS 26 bridge fixes --------- Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com> Co-authored-by: Peter Steinberger <steipete@gmail.com>
Collaborator
|
Thanks @omarshahine. The bridge work from this PR was landed through the maintainer branch and shipped in Closing this PR as superseded by the shipped 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.
Summary
Adds a manual rewrite/port of the BlueBubbles private-API surface as an
imsgbridge, layered on top of the existing AppleScript send path. None of BlueBubbles' source or binaries are vendored — the API vocabulary (send-rich,tapback,chat-mark, etc.) is preserved so existing BB tooling can target this. The bridge is opt-in (SIP-off + injected helper dylib) and does not affect defaultsend/history/watch/rpcflows.Fixes #60 —
imsg typingnow works on macOS 26 (Tahoe) when the bridge is active. The dylib runs in-process within Messages.app, sosetLocalUserIsTyping:uses Messages.app's own entitlements and bypasses imagent's private-entitlement check.TypingIndicator.setTypingprefers the bridge path and only falls back to the direct IMCore path (the one that fails on Tahoe per #60) when the bridge is unavailable.Provenance: manual port inspired by the BlueBubbles helper/server (Apache-2.0). The action verb vocabulary was preserved intentionally for tooling compatibility; the implementation is local and lives entirely in this repo. Upstream references:
imsgremains under MIT.What's new
Bridge command surface (require
imsg launch+ SIP off):send-rich,send-multipart,send-attachment,tapbackimsg status):edit,unsend,delete-message,notify-anywayschat-create,chat-name,chat-photo,chat-add-member,chat-remove-member,chat-leave,chat-delete,chat-markaccount,whois,nickname,searchwatch --bb-events(typing, alias-removed)Text formatting on macOS 15+:
--formatJSON ranges with bold/italic/underline/strikethrough onsend-rich. Earlier macOS silently degrades to plain text (privateIMText*attribute names don't exist before Sequoia).v2 IPC to replace the v1 single-file polling (which raced under concurrent CLI invocations):
IMSG_BRIDGE_LEGACY_IPC=1keeps the v1 path for un-rebuilt dylibs.Bug fixes (3rd commit):
associatedMessageType=100whenselectedMessageGuidis present (was hardcoded to 0 — replies didn't thread on the receiving end).__kIMBaseWritingDirectionAttributeName="-1"across the full string, matching plain sends so formatted text behaves identically.chat-marknow rejects conflicting--read --unreadinstead of silently defaulting to--read(covered by newchatMarkRejectsConflictingFlagstest).Setup (for reviewers verifying the bridge surface)
csrutil disablemake build-dylibimsg launchimsg statusshould showbridge version: v2 (v2 inbox active)plus selector-probe resultsTo revert: re-enable SIP with
csrutil enable.Verification
make test— 198 tests passed (160 pre-existing + 38 from the rebase / port additions includingchatMarkRejectsConflictingFlags).swift format lint --recursive Sources Tests— warnings only on the newBridge*.swiftfiles (line-length, trailing-comma). Non-fatal; consistent with style elsewhere inSources/imsg/Commands.swiftlint lint Sources Tests— 0 violations.Sample commands
Notes
### Bridge command surfacesection under "Advanced IMCore Features".mainafter the message-store refactors;Sources/imsg/CommandRouter.swiftadds the bridge specs alongsideCompletionsCommand.send/history/watch/rpcpaths are unchanged.imsg launchcontinues to refuse injection when SIP is enabled.🤖 Generated with Claude Code