Skip to content

feat: expose destination_caller_id in message output#29

Merged
steipete merged 1 commit intosteipete:mainfrom
commander-alexander:feature/expose-destination-caller-id
Feb 16, 2026
Merged

feat: expose destination_caller_id in message output#29
steipete merged 1 commit intosteipete:mainfrom
commander-alexander:feature/expose-destination-caller-id

Conversation

@commander-alexander
Copy link
Contributor

@commander-alexander commander-alexander commented Jan 31, 2026

Summary

Exposes the destination_caller_id field in message output. This field indicates which phone number/Apple ID received the message, which is essential for multi-SIM setups where a single Mac receives messages for multiple numbers.

Use Case

When a Mac is linked to an iPhone with dual-SIM (or multiple Apple IDs), all messages arrive in the same Messages database. Without destination_caller_id, there's no way to know which number/account a message was sent to.

Example: User has personal number (+1555-111-1111) and a second number (+1555-222-2222). An automation tool needs to only respond to messages sent to the second number.

Changes

  • src/messages/mod.rs: Added destination_caller_id field to Message struct
  • Query extracts destination_caller_id from the message table

Output Example

{
  "id": 12345,
  "sender": "+15551234567",
  "destination_caller_id": "+15559876543",
  "text": "Hello!",
  ...
}

Testing

Tested with dual-SIM setup. Messages correctly show the destination number they were sent to.


This PR was developed with AI assistance.

commander-alexander added a commit to commander-alexander/openclaw that referenced this pull request Jan 31, 2026
…umber

When the Mac has multiple iMessage numbers (e.g., dual-SIM setup), messages
to ALL numbers are received. This adds a myNumbers config option that filters
messages by destination_caller_id, so the bot only responds to messages sent
to the configured number(s).

Config example:
{
  channels: {
    imessage: {
      myNumbers: ["+16466128299"]
    }
  }
}

Requires imsg to expose destination_caller_id (see steipete/imsg#29).
commander-alexander added a commit to commander-alexander/openclaw that referenced this pull request Jan 31, 2026
…umber

When the Mac has multiple iMessage numbers (e.g., dual-SIM setup), messages
to ALL numbers are received. This adds a myNumbers config option that filters
messages by destination_caller_id, so the bot only responds to messages sent
to the configured number(s).

Config example:
{
  channels: {
    imessage: {
      myNumbers: ["+16466128299"]
    }
  }
}

Requires imsg to expose destination_caller_id (see steipete/imsg#29).
commander-alexander added a commit to commander-alexander/openclaw that referenced this pull request Jan 31, 2026
…umber

When the Mac has multiple iMessage numbers (e.g., dual-SIM setup), messages
to ALL numbers are received. This adds a myNumbers config option that filters
messages by destination_caller_id, so the bot only responds to messages sent
to the configured number(s).

Config example:
{
  channels: {
    imessage: {
      myNumbers: ["+16466128299"]
    }
  }
}

Requires imsg to expose destination_caller_id (see steipete/imsg#29).
This field helps distinguish between messages actually sent by the local
user vs messages received on a secondary phone number registered with
the same Apple ID.

When is_from_me is true but destination_caller_id differs from the
user's own numbers, the message was actually received from another
device/person messaging that secondary number.

This enables tools like Clawdbot to properly detect inbound messages
on secondary iMessage phone numbers.
@steipete steipete force-pushed the feature/expose-destination-caller-id branch from d396cb2 to 2262e16 Compare February 16, 2026 04:33
@steipete steipete merged commit ba9a1ff into steipete:main Feb 16, 2026
1 check passed
@steipete
Copy link
Owner

Landed via temp rebase onto main.

  • Gate: make lint && make test && make build
  • Land commit: 2262e16
  • Merge commit: ba9a1ff

Thanks @commander-alexander!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants