[macOS 27] Dragging a file into ChatGPT freezes the app: main thread blocks reading drag-pasteboard data promised by Apple Mail #51944

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT 26.1002.52244 (13536)

What subscription do you have?

Pro

What platform is your computer?

macOS 27.0 (26A428), arm64 (Apple M4, Mac16,1)

What issue are you seeing?

Dragging any file (e.g. from ~/Downloads in Finder) into the ChatGPT app makes the whole app unresponsive as soon as the drag enters the window, before dropping. Cmd-Q does nothing, and in-flight Codex / Computer Use tasks in the app stop. The app recovers on its own after roughly 60–95 s. Copy-paste of the same file works.

Google Chrome 154.0.8037.98 on the same machine freezes the same way (entire browser), so this looks like a Chromium drop-target behaviour combined with a macOS 27 bug rather than something unique to ChatGPT.

This looks similar to #39548 but appears to be a different cause: that report is macOS 26.6.2 with 100% CPU spinning in _mouseHysteresisCheck; here the main thread is blocked at ~0% CPU waiting on the pasteboard daemon.

Main thread — identical in a live sample of ChatGPT and in two system .hang reports (ChatGPT 63 s, Chrome 95 s):

CoreDragMessageHandler
 NSCoreDragTrackingProc
  -[NSDragDestination _draggingEntered]
   <Chromium drag-enter handler>
    -[NSPasteboardItem stringForType:]
     -[NSPasteboard _dataWithoutConversionForTypeIdentifier:index:securityScoped:]
      CFPasteboardCopyData
       ___onqueue_CFPasteboardRequestDataFromDaemon_block_invoke
        mach_msg2_trap        <- 100% of samples, ~0% CPU

Drag pasteboard contents right after a freeze (type names only, read via NSPasteboard(name: "Apple CFPasteboard drag")). The drag itself was started from ~/Downloads in Finder; I never dragged anything from Mail into ChatGPT:

com.apple.mail.PasteboardTypeMessageTransfer
com.apple.mail.PasteboardTypeAutomator
public.url, public.url-name, public.utf8-plain-text
com.apple.pasteboard.promised-file-url
+ a second item with NSFilePromise metadata

In other words: lazily promised data owned by Apple Mail, which was running in the background.

What steps can reproduce the bug?

1. macOS 27.0 with Apple Mail running in the background (in my case the system drag pasteboard still contained Mail data — see the types above).
2. In Finder, drag any file from ~/Downloads over the ChatGPT window (e.g. onto the Codex composer).
3. As soon as the drag enters the window, ChatGPT stops responding (~0% CPU) for 60–95 s; Codex tasks running in the app stall.
4. Fully quit Mail (Cmd-Q) and repeat step 2 → drag-and-drop works normally.

What is the expected behavior?

Dragging a file into the app should never block the main thread. If the drag pasteboard contains promised data whose provider does not respond, the app should time out or skip that type instead of freezing the whole app (and any running Codex tasks).

Additional information

• The root cause appears to be a known macOS 27 regression in drag-and-drop from Apple Mail, where reading a URL/text from the pasteboard waits forever (FB24803817; see https://mjtsai.com/blog/2026/10/01/eaglefiler-1-9-22/).
• Workaround for others on macOS 27: if ChatGPT/Codex freezes when you drag a file in, quit Mail (Cmd-Q) and try again.
• Suggestion: the drop target reads public.utf8-plain-text synchronously on the main thread in draggingEntered. Deferring that read until drop, or making it asynchronous and time-bounded, would avoid the hang even while Apple's bug exists.
• Related (similar symptom, different cause): [macOS] ChatGPT hangs at 100% CPU during Finder file drag #39548