macOS: drag and drop no longer uses bracketed paste since #13817

[gmoneyn]

Description

Since #13817, file paths delivered by drag and drop on macOS are no longer wrapped in bracketed paste. They now arrive as simulated typing, so programs that distinguish pasted input from typed input treat a dropped file as ordinary keystrokes.

The concrete symptom: dropping an image onto Claude Code used to produce an image attachment ([Image #1]). It now inserts the raw escaped path as text and the image is never attached.

Cause

#13817 ("macos: send all insertText commits as key events", ecbeb60 / 9009122) changed insertText to route through the key event path:

-        surfaceModel.sendText(chars)
+        _ = committedTextAction(GHOSTTY_ACTION_PRESS, text: chars)

The commit message states the rationale and the assumption behind it:

Previously, insertText commits without marked text were delivered via sendText, which applies paste semantics and wraps the text in bracketed paste when the program enables it. macOS dictation and other input methods often commit without marked text, so programs treated dictated text as a paste.

insertText is only invoked by input methods (IME, dictation, emoji picker, character viewer); real paste operations use a separate path.

That last assumption does not hold. performDragOperation in macos/Sources/Ghostty/Surface View/SurfaceView_AppKit.swift calls insertText directly:

override func performDragOperation(_ sender: any NSDraggingInfo) -> Bool {
    let pb = sender.draggingPasteboard
    let content = pb.getOpinionatedStringContents()

    if let content {
        DispatchQueue.main.async {
            self.insertText(
                content,
                replacementRange: NSRange(location: 0, length: 0)
            )
        }
        return true
    }

    return false
}

So file drops share the code path that was intentionally converted from paste semantics to typed input. Dictation was the target; drag and drop was affected as collateral.

Reproduction

1. Run a program that treats pasted text differently from typed text. Claude Code is one, but anything reading bracketed paste markers will do.
2. Drag a file from Finder onto the Ghostty window.
3. Observe that the path arrives as typed characters with no ESC[200~ / ESC[201~ framing.

Expected: the dropped path is delivered as a bracketed paste, as it was before #13817.

Version

Ghostty 1.3.2-main-+9f0e1719d
channel: tip

macOS 26.6.2 (build 25G83, Darwin 25.6.0), Apple Silicon (arm64).

Confirmed by git tag --contains 90091229, which lists only tip. v1.3.0 and v1.3.1 do not contain the change, so this affects tip builds only and has not shipped in a stable release.

Suggested fix

Keep the key event path for genuine input method commits, but let performDragOperation deliver dropped content through sendText so drops retain paste semantics. Distinguishing the two callers rather than the two kinds of text seems closer to the intent of #13817, since the goal there was specifically to stop dictation being seen as a paste.

Happy to test a patch on tip.

[mitchellh]

Thanks, fixed here #13999