Fix typedstream attributedBody recovery for 32-126 byte messages whose length byte is printable ASCII, and keep the regression covered across the parser edge cases.\n\nCo-authored-by: Sagar Dagdu <shags032@gmail.com>
* fix(security): clamp IPC dirs to 0700 and reject symlinked paths
Threat model: a same-UID attacker (another user process, a sandboxed peer
that can reach the home dir) can drop a file or symlink into the RPC
inbox, or supply an attachment path that points at a sensitive file via
a parent-directory symlink, and have Messages.app exfiltrate it as an
attachment to an attacker-controlled handle.
Mitigations applied at every IPC boundary:
- Mode 0700 on .imsg-rpc/, .imsg-rpc/in/, .imsg-rpc/out/ creation.
Final chmod handles dirs that already existed 0755 from prior
unsandboxed runs.
- Refuse any RPC queue path or attachment path where any component
(final or parent) is a symbolic link. Walking each component with
lstat() — done by SecurePath.hasSymlinkComponent in IMsgCore and the
pathHasSymlinkComponent twin in the dylib — catches parent-directory
links that realpath()-vs-lexical comparison misses (macOS rewrites
/tmp -> /private/tmp, breaking that approach for legitimate paths).
- Strict throws for queue dir creation and cleanup in MessagesLauncher
(was `try?` swallowing errors), and for ensureDirectory in
IMsgBridgeClient. Bridge refuses to start instead of operating on an
insecure path.
Tests cover both final-component and parent-component symlink detection
in SecurePath. Toolchain on this machine lacks swift-testing; tests
build clean and ship to be run by Xcode on the maintainer's box.
* fix: allow trusted system path aliases
---------
Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* 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🎏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🎏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>
Decode typedstream attributedBody segments that use 0x81/0x82 length prefixes so long fallback message text is preserved in history/watch output.
Also records the fix in the 0.7.0 changelog.
Co-authored-by: Sagar Dagdu <shags032@gmail.com>
Port the BlueBubbles-inspired IMCore bridge surface into imsg with rich sends, message mutation, chat management, account/nickname introspection, live bridge events, and v2 UUID-keyed IPC.
Fixes#60.
Co-authored-by: Omar Shahine <omarshahine@users.noreply.github.com>
Per-feature pages (install, quickstart, permissions, chats, history,
watch, send, groups, attachments, json, rpc, completions, advanced-imcore,
troubleshooting) plus an Apple-styled static-site builder rendering them
to dist/docs-site. GitHub Pages workflow deploys on every docs/ change to
imsg.sh.
Adds a local helper to dispatch the centralized Homebrew tap formula update during releases.
Co-authored-by: Dinakar Sarbada <dinakars777@users.noreply.github.com>
