Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix iMessage plugin: reply fails on macOS with 'any;-;' chat GUID format [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46747•Fetched 2026-04-12 13:34:07
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
nobonnenobonne
Participants
nobonnenobonne
Timeline (top)
labeled ×4

The iMessage plugin's reply tool fails to send messages on newer macOS versions where chat.db stores DM chat GUIDs with the any;-; prefix instead of the traditional iMessage;-; or SMS;-; prefixes.

Error Message

  • Using any;-;+81XXXXXXXXXX (as provided in the inbound message): passes the allowlist check, but Messages.app AppleScript rejects the GUID with error -1728 ("chat id を取り出すことはできません")

Root Cause

In server.ts, the sendText() function passes the chat GUID directly to AppleScript:

tell application "Messages" to send (item 1 of argv) to chat id (item 2 of argv)

The allowedChatGuids() function correctly queries chat.db and returns any;-; GUIDs, so the allowlist check passes. However, Messages.app's AppleScript API does not recognize the any;-; prefix.

Fix Action

Workaround

Sending via participant instead of chat id works:

tell application "Messages"
  set theService to 1st account whose service type = iMessage
  set theBuddy to participant "+81XXXXXXXXXX" of theService
  send "message" to theBuddy
end tell

Code Example

tell application "Messages" to send (item 1 of argv) to chat id (item 2 of argv)

---

tell application "Messages"
  set theService to 1st account whose service type = iMessage
  set theBuddy to participant "+81XXXXXXXXXX" of theService
  send "message" to theBuddy
end tell
RAW_BUFFERClick to expand / collapse

Summary

The iMessage plugin's reply tool fails to send messages on newer macOS versions where chat.db stores DM chat GUIDs with the any;-; prefix instead of the traditional iMessage;-; or SMS;-; prefixes.

Environment

  • macOS Tahoe (Darwin 25.4.0)
  • iMessage plugin v0.1.0

Steps to Reproduce

  1. Receive a DM via the iMessage plugin channel
  2. The inbound message arrives with chat_id="any;-;+81XXXXXXXXXX"
  3. Attempt to reply using the reply tool with this chat_id

Observed Behavior

  • Using any;-;+81XXXXXXXXXX (as provided in the inbound message): passes the allowlist check, but Messages.app AppleScript rejects the GUID with error -1728 ("chat id を取り出すことはできません")
  • Using iMessage;-;+81XXXXXXXXXX: fails the allowlist check because this GUID doesn't exist in chat.db
  • Using SMS;-;+81XXXXXXXXXX: same allowlist failure

Root Cause

In server.ts, the sendText() function passes the chat GUID directly to AppleScript:

tell application "Messages" to send (item 1 of argv) to chat id (item 2 of argv)

The allowedChatGuids() function correctly queries chat.db and returns any;-; GUIDs, so the allowlist check passes. However, Messages.app's AppleScript API does not recognize the any;-; prefix.

Workaround

Sending via participant instead of chat id works:

tell application "Messages"
  set theService to 1st account whose service type = iMessage
  set theBuddy to participant "+81XXXXXXXXXX" of theService
  send "message" to theBuddy
end tell

Suggested Fix

Either:

  1. Normalize any;-; GUIDs to the appropriate service prefix (iMessage;-; or SMS;-;) before passing to AppleScript, or
  2. Fall back to sending via participant of a service when chat id based sending fails

extent analysis

TL;DR

Modify the sendText() function in server.ts to either normalize any;-; GUIDs or fall back to sending via participant when chat id based sending fails.

Guidance

  • Identify the any;-; prefix in the chat GUID and normalize it to the appropriate service prefix (iMessage;-; or SMS;-;) before passing it to AppleScript.
  • Implement a fallback mechanism to send messages via participant when the chat id based sending fails with error -1728.
  • Update the allowedChatGuids() function to handle the normalized GUIDs correctly.
  • Test the modified sendText() function with different chat GUID prefixes to ensure compatibility.

Example

tell application "Messages"
  if (send (item 1 of argv) to chat id (item 2 of argv)) = error "-1728" then
    set theService to 1st account whose service type = iMessage
    set theBuddy to participant (item 3 of argv) of theService
    send (item 1 of argv) to theBuddy
  end if
end tell

Notes

The suggested fix assumes that the any;-; prefix is the primary cause of the issue. However, additional testing may be required to ensure that the modified sendText() function works correctly with different macOS versions and iMessage plugin configurations.

Recommendation

Apply workaround by falling back to sending via participant when chat id based sending fails, as this approach does not require modifying the underlying chat GUIDs or the allowedChatGuids() function.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#memory management#API rate limit#retriever error#indexing error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix iMessage plugin: reply fails on macOS with 'any;-;' chat GUID format [1 participants]