Copy/paste produces incorrect line breaks on macOS (Ghostty 1.3.1)

[No-22-Github]

Issue Description

Text copied from Ghostty via Cmd+C (or Edit → Copy) has corrupted line breaks. Hard newlines (\n) in command output are stripped (multiple lines merge into one). In fish shell, the prompt additionally gets spurious newlines inserted within a single line. The same text copied via pbcopy pipe is correct, and Terminal.app copies identical content correctly.

Tested with ghostty --config-file=/dev/null (empty config) — same issue. Edit → Copy menu item also behaves the same as Cmd+C. This affects all copied content, not just prompts.

This does not appear to be the soft-wrap issue discussed in #11215 / #6815. Content is not soft-wrapping (window is wide enough), and pbcopy from the same terminal session produces correct output, isolating the problem to Ghostty's selection/clipboard path. Related: #2709.

Expected Behavior

Copying the output of echo -e "line1\nline2\nline3\nline4\nline5" and pasting into a text editor should produce:

line1
line2
line3
line4
line5

This is what Terminal.app produces, and what pbcopy produces from the same Ghostty session.

Actual Behavior

fish shell: Output newlines are stripped (five lines become one). The prompt above is broken into fragments with spurious newlines:

no22
@No22-MacBook-Air
~
> echo -e "line1\nline2\nline3\nline4\nline5"
 line1 line2 line3 line4 line5

zsh: All newlines stripped — everything merges into a single continuous line:

no22@No22-MacBook-Air ~ % echo -e "line1\nline2\nline3\nline4\nline5" line1 line2 line3 line4 line5 no22@No22-MacBook-Air ~ %

Reproduction Steps

1. Open Ghostty on macOS (fish or zsh, does not matter)
2. Run: echo -e "line1\nline2\nline3\nline4\nline5"
3. Select all output with mouse, press Cmd+C
4. Paste into any text editor (Notes, TextEdit, etc.)
5. Observe that newlines in the output are missing
6. Control test A: run echo -e "line1\nline2\nline3\nline4\nline5" | pbcopy, then paste — newlines are correct
7. Control test B: run the same echo command in Terminal.app, select and Cmd+C — newlines are correct

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.05 (25F71)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

N/A — issue reproduces with ghostty --config-file=/dev/null (empty config)

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[No-22-Github]

Closing this — after further testing, the issue only occurs when pasting into the Claude.ai chat input box. Pasting into Notes, VS Code, TextEdit, and other apps all works correctly. This is not a Ghostty issue. Apologies for the noise.

[RicardoEreto]

good thing you posted it tho, now I know why my text is breaking, thank you

[tylers-username]

cmd+shift+v / ctrl+shift+v for macos and linux takes care of this in these stupid input fields

[jdorn-eu]

This happens to me when running tmux through Ghostty and I haven't been able to identify the underlying reason. If anybody has an idea what to try, feel free to share.

[No-22-Github]

@salixh5 Try adding keybind = cmd+c=copy_to_clipboard:plain to your config and reload. Root cause is the default mixed format putting HTML (no <br>) on the clipboard. Does forcing plain fix it in your tmux setup too?

[jdorn-eu]

Thank you, it seems like the issue I'm having is actually closer to #12717 which is similar but different. Whily copying works without issues, Ghostty is inserting escape sequences when pasting text, and in applications like Nano this triggers side effects that also produce incorrect line breaks in the end.

[No-22-Github]

Update: tracked this down. It's the mixed clipboard format (default since 1.3.0) — Ghostty puts both text/plain and text/html on the clipboard, but the HTML has no <br>, so newlines collapse. Apps that read plain text (VS Code, pbcopy, Terminal) are fine; apps that prefer the HTML flavor (the Claude.ai chat input, Claude Code per #2709) merge the lines. Same root cause as #2709.

Workaround:

keybind = cmd+c=copy_to_clipboard:plain

This forces plain-text-only copy and fixes pasting into Claude.ai.

[stephang]

Confirming the issue: Text copied from Ghostty into non plain-text apps (Obsidian, MS Teams, rich text html input fields, ...) swallows line breaks. But also adds other line breaks.

Text in Ghostty / zsh …

❯ echo -e "line1\nline2\nline3\nline4\nline5"
line1
line2
line3
line4
line5

becomes when pasted:

❯

echo

-e

"line1\nline2\nline3\nline4\nline5"

line1 line2 line3 line4 line5

The proposed workaround fixes the problem.

You may reconsider re-opening this issue.

ghostty 1.3.2, oh-my-zsh & powerlevel10k, mac OS 15.7.7

[stephang]

When using bash, extra linebreaks disappear.

Text in Ghostty / bash:

bash-3.2$ echo -e "line1\nline2\nline3\nline4\nline5"
line1
line2
line3
line4
line5

When pasted:

bash-3.2$ echo -e "line1\nline2\nline3\nline4\nline5" line1 line2 line3 line4 line5