send-attachment via bridge fails to stage file on macOS 26 (AppleScript path works)

[omarshahine]

Symptom

imsg send-attachment (the IMCore-bridge attachment path) registers an IMFileTransfer, dispatches a placeholder IMMessage, and reports success — but the receiver sees an empty  placeholder message with no file attached, and on the sender chat.db there's no row in attachment or message_attachment_join linking the transfer to the message. Same machine, same iMessage account, the AppleScript path works perfectly.

$ imsg send --file ~/photo.jpg --to "+15551234567"          # works ✓
$ imsg send-attachment --chat 'iMessage;-;+15551234567' \
                       --file ~/photo.jpg                    # broken ✗

Messages.app UI sending also works fine — receiver gets the file. So the issue is local to our IMFileTransferCenter handling on macOS 26.4.1.

What we know

• Reproducible across small PNGs (1×1) and real-world JPEGs (178 KB) on macOS 26.4.1.
• The bridge returns {transferGuid, messageGuid} without exception.
• chat.db has the message row (attributedBody length ~270 B, OBJ placeholder + IM attributes), but no joined attachment row.
• Receiver sees the empty placeholder; user-attached file via Messages.app UI in the same chat is delivered correctly side-by-side.

Root-cause investigation

The relevant code is prepareOutgoingTransfer in Sources/IMsgHelper/IMsgInjected.m, modeled on BlueBubblesHelper's prepareFileTransferForAttachment:

1. [IMFileTransferCenter guidForNewOutgoingTransferWithLocalURL:] — returns a guid ✓
2. [IMFileTransferCenter transferForGUID:] — returns a non-nil IMFileTransfer ✓
3. [IMDPersistentAttachmentController _persistentPathForTransfer:filename:highQuality:chatGUID:storeAtExternalPath:] — returns nil on macOS 26.4.1 ✗
4. (Skipped because path is nil) Copy file to persistent path
5. [IMFileTransferCenter retargetTransfer:toPath:] (skipped)
6. [IMFileTransfer setLocalURL:] (skipped)
7. [IMFileTransferCenter registerTransferWithDaemon:] — called with the original /tmp/... path because we never retargeted

The daemon then has a transfer guid pointing at a path Messages.app can read but apparently can't ship through to imagent properly. Receiver gets the empty placeholder.

What's been ruled out

• Path-prefix attribute issues: __kIMFileTransferGUIDAttributeName, __kIMFilenameAttributeName, __kIMMessagePartAttributeName, __kIMBaseWritingDirectionAttributeName are all set on the OBJ placeholder, matching BlueBubblesHelper's attachmentStr exactly.
• Send flags: previously 0x5; now 0x100005 (BB-verified, the 0x100000 finalization bit). Doesn't change attachment behavior.
• Init signature: switched to BB's 12-arg initWithSender:…:expressiveSendStyleID: (not the legacy initIMMessageWithSender:). Doesn't change attachment behavior.
• IMMessageItem-first construction: bypassed for attachments — they go through BB's IMMessage init directly. No effect on the staging gap.
• ARC zombie: getReturnValue into __unsafe_unretained for the persistentPath was tightened to a strong reference. The path was returning nil already, before the retention change — so this wasn't the cause.

What's likely the fix

Runtime probe of IMDPersistentAttachmentController on macOS 26.4.1 reveals the modern staging selectors:

-[IMDPersistentAttachmentController saveAttachmentsForTransfer:chatGUID:storeAtExternalLocation:completion:]
-[IMDPersistentAttachmentController _saveAttachmentForTransfer:highQuality:copyWithinAttachmentStore:chatGUID:storeAtExternalPath:]
-[IMDPersistentAttachmentController _persistentPathForTransfer:filename:highQuality:chatGUID:storeAtExternalPath:]

The _persistentPath… selector is still in the class but returns nil for our IMFileTransfer. The likely modern path:

1. Allocate the transfer guid (as we do today).
2. Resolve IMFileTransfer (as we do today).
3. Use saveAttachmentsForTransfer:chatGUID:storeAtExternalLocation:completion: (block-based) instead of _persistentPathForTransfer: to let the controller stage the file itself.
4. Wait for the completion to fire (run-loop pump similar to deriveThreadIdentifier).
5. registerTransferWithDaemon:.

Or possibly _saveAttachmentForTransfer:highQuality:copyWithinAttachmentStore:chatGUID:storeAtExternalPath: — synchronous variant. Worth class-dumping IMDPersistentAttachmentController.h from a fresh dyld_shared_cache extract on macOS 26.4.1 to get the exact signatures.

Reference

BlueBubblesHelper's prepareFileTransferForAttachment is what prepareOutgoingTransfer is modeled on. BB's most recent test target may pre-date macOS 26.

Workaround

Use the AppleScript path until the staging fix lands:

imsg send --file ~/photo.jpg --to "+15551234567"

imsg send --file does not require SIP-disabled bridge injection and is unaffected by this regression. It's the path Lobster's gateway should prefer for attachments.

Related

• PR fix: macOS 26 bridge regressions — typing/read RPC, effect mapping, attachment registration #101 ships the broader macOS 26 bridge-handler fixes (tapbacks, replies with threading, effect bundle IDs, RPC typing/read, send flags). Attachment staging is the single remaining gap from that PR's scope.

cc @omarshahine

🤖 Filed via Claude Code after a multi-hour debugging session

[steipete]

Fix landed on main in 3695bfb and is queued for 0.7.3.

What changed: send-attachment and group-photo staging now pass the target chat GUID into IMDPersistentAttachmentController _persistentPathForTransfer:filename:highQuality:chatGUID:storeAtExternalPath:. Runtime probing showed this is the missing bit: with chatGUID:nil the selector returns nil, but with the real chat GUID it returns a Messages attachment-store path. The bridge also has a fallback for saveAttachmentsForTransfer:chatGUID:storeAtExternalLocation:completion: for the newer block-based staging path.

Proof so far:

• Hopper MCP via mcporter confirmed the IMDPersistence selectors on the current dyld shared cache.
• Local ObjC runtime probe confirmed selector encodings and the chat-GUID-dependent return behavior.
• Added regression coverage for the source-level bridge invariant.
• make lint, make test, make build, and GitHub CI are green on 3695bfb.

Remaining caveat: I could not run the final live imsg send-attachment smoke here because this machine, Mac Studio, and MacBook all report SIP enabled, so Messages injection is unavailable. Leaving this open for the final SIP-disabled live-send verification; code is otherwise ready for the 0.7.3 release.

[steipete]

Released in 0.7.3: https://github.com/openclaw/imsg/releases/tag/v0.7.3

The fix is in 3695bfb and shipped in the signed/notarized imsg-macos.zip; Homebrew tap update for v0.7.3 is also green. Closing this as fixed in the release. The only thing I could not do locally was a SIP-disabled live-send smoke, because all available machines had SIP enabled, but the Hopper/runtime probe and regression coverage point at the chat-GUID staging bug fixed here.