Filed by @omarshahine — couldn't auto-assign due to repo permissions.

What's missing

imsg today exposes two non-overlapping send paths:

• imsg send-rich --reply-to <guid> --text <text> — replies threaded to a target message, but does not accept --file.
• imsg send --file <path> (with --chat-guid/--to/--chat-id/--chat-identifier) — sends an attachment, but does not accept --reply-to.

There is no way to send a single message that is both attached to a file and threaded as a reply to an existing iMessage.

Why it matters

This becomes a real footgun for any orchestrator that exposes a generic "reply with media" surface. Concretely, on OpenClaw's iMessage extension we just shipped a bugfix (openclaw/openclaw#79822) because the high-level message tool was accepting { action: "reply", media: "<path>" } — a shape that genuinely makes sense for iMessage end-users — and silently dropping the media because there's no underlying imsg call that does both. Today the only correct path is two messages: a threaded text reply via send-rich, plus a separate send --file that is not threaded. Users see two bubbles, the attachment hangs in space, and most agents won't reconstruct the linkage.

Suggested fix

Either:

1. Add --reply-to <guid> to imsg send (preferred — the AppleScript path that handles --file is the one most callers use), or
2. Add --file <path> to imsg send-rich (so the IMCore bridge writes the attachment and the reply pointer in one round-trip).

Option 1 is probably easier to land — Messages.app's AppleScript bridge can target a reply via set targetService / set theMessage patterns; option 2 needs the IMCore reply payload to carry an attachment GUID, which is more invasive.

Repro

```
imsg send --chat-guid 'iMessage;-;+15555555555' --file /tmp/foo.png --reply-to AAAAAAAA-...

error: unknown option '--reply-to'

imsg send-rich --chat 'iMessage;-;+15555555555' --reply-to AAAAAAAA-... --text 'here it is' --file /tmp/foo.png

error: unknown option '--file'

```

Tested on imsg 0.8.0 on macOS 26.4.0 (Tahoe), IMCore v2 bridge, SIP disabled.

Current OpenClaw workaround

After openclaw/openclaw#79822, OpenClaw's reply action explicitly rejects media/mediaUrl/filePath/buffer and tells callers to use upload-file (untreaded) for the attachment. That keeps the silent failure from happening, but it means agent-driven "reply with image" still produces a non-threaded attachment — which is a subset of what users intuitively expect. A single-call imsg primitive would let us close that gap.

Happy to test a candidate flag locally if useful — I'm running this against a live OpenClaw + Lobster agent setup that hits the path daily.