Skip to content

iMessage chat participants returned as raw phone numbers / opaque hashes instead of contact names #37

Description

@crimsonsunset

Summary

When retrieving iMessage chats or messages via the MCP server, all participant identifiers are returned as raw phone numbers or opaque hashed IDs rather than resolved contact names. Beeper Desktop resolves these names correctly in the UI, but the resolution does not carry through to the API/MCP layer.

Steps to Reproduce

  1. Open Beeper Desktop on macOS with iMessage connected and macOS Contacts access granted
  2. Confirm that iMessage threads in the Beeper UI display contact names correctly
  3. Call search_chats via the MCP server
  4. Inspect the chat titles and participants fields in the response

Expected Behavior

Chat titles and participant fields return resolved contact names consistent with what Beeper Desktop displays in the UI.

Actual Behavior

Chat titles are raw E.164 phone numbers. Participant fields are opaque hashed identifiers (e.g. imsg##participant:3785981af946f55a5eac4d66232e6d7d...) with no display name attached.

Example response:

{
  "title": "+1 555-000-0000",
  "participants": [
    "imsg##participant:3785981af946f55a5eac4d66232e6d7dab9c4c77ed48e9e3",
    "imsg##participant:c2b9fd373d2ab35269c0ff856171bafc281dccdde4de496d"
  ]
}

Expected:

{
  "title": "Jane Smith",
  "participants": ["Jane Smith", "Me"]
}

Impact

  • AI assistants cannot identify who a conversation is with by name
  • Searching for chats by contact name returns no useful results
  • Any agent workflow involving a person's name requires a separate out-of-band contact lookup step
  • The hashed participant IDs are not human-readable or cross-referenceable

Workaround

A separate macOS Contacts MCP server can be used to perform client-side phone → name resolution at query time, but this requires an additional MCP dependency and adds latency.

Environment

  • Beeper Desktop v4.2.x
  • macOS Sequoia
  • MCP endpoint: localhost:23373/v0/mcp
  • Contacts permission: Granted to Beeper Desktop
  • iMessage status in UI: Connected, names display correctly

Notes

The Beeper UI clearly has access to the resolved display name — it would be ideal if the API exposed the same displayName field the UI consumes. This may also affect other platforms that use phone numbers as identifiers (WhatsApp, Signal) but is most apparent with iMessage since Apple IDs and phone numbers are the only available identifiers.

Activity

  1. b-pm commented on Oct 4, 2026

    @b-pm

    beeper/cli#42 now reports unresolved raw-phone iMessage titles in beeper doctor --network imessage, so agent operators can distinguish a contact-resolution gap from a missing account. It does not attempt to create a competing Contacts database; native API/UI contact names should remain authoritative. The PR also makes direct iMessage sends possible via an explicit account + phone/email while this issue remains open.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions