Double path printed when using Pure prompt.

[alec-bike]

Issue Description

This is cross-posted from the Discord Help thread...

I updated tip yesterday (to commit 51897c0) and now see a double printing of the path. I'm using zsh with the Pure prompt on macOS, and have been running Ghostty tip for a while now.

> cd ~/Developer

~/Developer
~/Developer
>

This happens after every command. And if I press enter it keeps increasing the number of extra path lines printed.

If I create a new split or tab I don't see the double path printed.

This doesn't happen with the Pure prompt on macOS Terminal, nor in the Zed integrated terminal (alacritty I believe).

Commit 51897c0 has the issue.

@danielwe suggested the regression may be from #10455 and recommended installing #10509 (earlier commit 8d1d17e) which "fixes" the issue.

Installing #10455 (commit 4abbce2) brings back the issue.

Expected Behavior

Single path printed after command.

Actual Behavior

Multiple path lines printed after command.

Reproduction Steps

See details above.

Ghostty Logs

None.

Ghostty Version

Note: this is running commit 8d1d17e which works fine. The bug occurs for commits 4abbce2 and 51897c0.

Ghostty 1.3.0-main+8d1d17e00

Version
  - version: 1.3.0-main+8d1d17e00
  - channel: tip
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.3

(Linux only) Display Server

None.

(Linux only) Desktop Environment/Window Manager

N/A

Minimal Ghostty Configuration

I cleared the config and this made no difference. For reference I'm including my standard config:

theme = Material Darker
macos-titlebar-style = tabs
macos-window-buttons = hidden
mouse-hide-while-typing = true
auto-update-channel = tip
auto-update = off
keybind = super+p=toggle_command_palette
keybind = super+j=toggle_quick_terminal
font-family = Iosevka Term
font-size = 13.5
font-style = Extended

Additional Relevant Configuration

The following lines are added to ~/.zshrc for the Pure prompt:

# pure prompt
fpath+=$HOME/.pure
autoload -U promptinit; promptinit
prompt pure

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.

[danielwe]

Confirming that I can reproduce this with shell integration enabled. If it's not (e.g., if I launch zsh from within another shell) the problem does not appear.

(Btw., pure prompt is this: https://github.com/sindresorhus/pure. Just clone into $HOME/.pure and use OP's .zshrc.)

[mafredri]

@danielwe Feel free to try out sindresorhus/pure#706, it fixes the issue and should hopefully not introduce any regressions 🤞🏻. For context, the PR also describes why this happened.

[alec-bike]

I tested this branch and it fixes my issue with double printed path with Pure prompt on Ghostty tip (6c0e02d).

[danielwe]

@mafredi Do you think the fix on the pure prompt side is sufficient to close this, or is Ghostty really doing something it ought not to here? I'm asking since this presumably hasn't been an issue with pure prompt in other OSC 133-supporting terminals (kitty, iTerm2, WezTerm, and so on---if it were, I'm sure you'd have heard about it a long time ago)

[mafredri]

@danielwe Hard to say, I'd say anytime you're modifying the prompt you could be breaking any number of use-cases. iTerm2 isn't affected because they only wrap the prompt {begin}PROMPT{end} (and also restore the PROMPT in a preexec hook, I think). Can't remember if that worked well with multi-line prompts or not, though.

Considering Ghostty now modifies the output of $prompt_newline (set by promptinit), I'd say the risk of breakage is somewhat increased.

How often do prompts rely on constantly modifying the PROMPT variable, though? Not sure. Most users/themes set it once and are done.