ChatGPT Desktop Messages should document and surface Apple sender-identity/RCS attachment constraints

Open 💬 0 comments Opened Aug 26, 2026 by omarpinarecords

Report type

Documentation gap / integration UX / model grounding

Environment

  • ChatGPT Desktop: 26.820.60940 (build 7119)
  • Built-in Messages plugin: 1.0.1000816
  • macOS: 26.6.2, Apple Silicon
  • Destination transport in the reproduced case: RCS to a non-Apple recipient

Summary

ChatGPT Desktop can send messages and files through the built-in Messages plugin, but the current OpenAI documentation and model-visible guidance do not explain that Apple Messages sender identity and the destination transport can materially affect an attachment send.

In the reproduced case, a PDF did not reach the RCS recipient while Apple Messages was configured to start conversations from an email identity. After changing Start new conversations from to the phone number and retrying, the PDF was recorded in the exact RCS conversation as an application/pdf attachment, and the recipient confirmed receipt.

This report does not claim that every email-originated Apple Messages conversation universally rejects every PDF. It reports a controlled A/B result on one current environment, supported by Apple’s documented identity and RCS architecture. Even if the Apple behavior is working as designed, it directly affects ChatGPT users and should be documented and surfaced by the AI instead of being guessed after a failure.

Reproduction

  1. On a Mac signed in to Messages, allow both a phone number and email address as reachable identities.
  2. Select an email address under Start new conversations from.
  3. In ChatGPT Desktop, authorize the built-in Messages plugin to send a PDF to an existing non-Apple/RCS recipient.
  4. Observe that the recipient does not receive the PDF.
  5. Change Start new conversations from to the phone number.
  6. Retry the authorized PDF send to the same recipient.
  7. Read the Messages conversation back and confirm that the outgoing item contains the PDF attachment.
  8. Confirm receipt with the recipient.

Verified result in this case

  • Email selected as sender identity: the PDF was not received.
  • Phone number selected as sender identity: the PDF attachment was recorded in the RCS conversation and the recipient confirmed receipt.
  • The successful attachment was a 588,042-byte application/pdf.
  • Recipient identity, phone numbers, email addresses, message text, local paths, screenshots, and the PDF itself are intentionally omitted.

Official source basis

Apple documents that:

  • Messages conversations can start from either a phone number or an email address, and switching an existing email-originated conversation to the phone number can require a new conversation:

https://support.apple.com/en-mide/101744

  • On macOS, Start new conversations from controls which email address or phone number recipients see:

https://support.apple.com/en-am/guide/messages/icht39422/mac

  • RCS is a carrier-provided service:

https://support.apple.com/en-us/122195

  • RCS file transfer uses a carrier content upload followed by a file-transfer message to a phone-number handle using a cellular service:

https://developer.apple.com/documentation/telephonymessagingkit/rcsservice/upload(_:)

OpenAI’s current documentation explains that connected systems—not plugin availability alone—control which messages and actions are available:
https://learn.chatgpt.com/docs/enterprise/roles-and-workspace-permissions#understand-the-control-boundaries

However, a search of current official OpenAI documentation found no Messages-specific page describing sender identity, iMessage versus RCS/SMS/MMS routing, file-attachment prerequisites, or diagnostic guidance for this failure mode.

User impact

Without this documentation or model grounding:

  • ChatGPT may misdiagnose the failure as a permission or generic PDF limitation.
  • The assistant may present an unsupported conclusion and appear to hallucinate.
  • Users may repeatedly retry sends, change unrelated permissions, or believe an attachment was delivered when only the tool invocation succeeded.
  • A limitation belonging to the connected Apple messaging system becomes an unexplained ChatGPT failure because the integration does not surface it.

Expected behavior

  1. Publish a Messages integration page that documents:
  • sender identity considerations;
  • iMessage, RCS, SMS, and MMS distinctions;
  • file-attachment prerequisites and carrier dependence;
  • the difference between tool acceptance, a Messages attachment record, and recipient delivery.
  1. Ground the built-in Messages tool/model guidance in official Apple documentation.
  2. When an attachment to an RCS recipient fails, have the assistant:
  • identify the exact verified evidence;
  • suggest checking Start new conversations from;
  • explain that a phone-number sender identity may be required in the observed configuration;
  • avoid turning an account-specific A/B result into a universal rule.
  1. Return an actionable error or limitation instead of a generic failure or an unsupported diagnosis.

Related but not duplicate

  • #40727 tracks the separate Full Access/approval-path problem for built-in Messages sends. This report concerns undocumented connected-service behavior and model grounding after the send path is available.

Privacy

No recipient information, phone number, email address, message content, attachment content, local path, screenshot, or private log is included.

Feedback receipt

In-product feedback was uploaded successfully for this report.

Feedback ID: 01a033a3-b7d4-7b23-9ac3-900cc0e55665

View original on GitHub ↗