ZSH doesn't mark OSC133 input regions the first time when using zinit

[rajayonin]

Issue Description

Similar to what happens in #10523, when loading ZSH with the zinit plugin manager, it doesn't mark the input region correctly, preventing the use of OSC133 cl=line, that is, that you can't click and move the cursor.

Surprisingly enough, it starts marking it correctly after executing the first command:

It also happens with Oh My Posh, a prompt engine. I've tested each one separately and together, and the result is the same. I've tested just sourcing a simple test.zsh file with an echo hello and it works fine, as well as with an eval 'echo hello', so it's not just source or eval.

I've also tested the same setup in kitty 0.45.0, and the issue is not present there.

Expected Behavior

Clicking on the prompt moves the cursor.

Actual Behavior

Clicking on the prompt does nothing.

Reproduction Steps

1. Open Ghostty
2. Write something on the prompt
3. Click on any of the previously written text

Ghostty Logs

Timestamp                       Thread     Type        Activity             PID    TTL  
2026-02-03 11:50:18.061118+0100 0x1b0ca    Info        0x0                  15416  0    ghostty: [com.mitchellh.ghostty:ghostty] known but unimplemented action action=40
2026-02-03 11:50:18.062615+0100 0x1b0ca    Info        0x0                  15416  0    ghostty: [com.mitchellh.ghostty:io_exec] io_exec: found Ghostty resources dir: /Applications/Ghostty.app/Contents/Resources/ghostty
2026-02-03 11:50:18.062692+0100 0x1b0ca    Info        0x0                  15416  0    ghostty: [com.mitchellh.ghostty:io_exec] io_exec: shell integration automatically injected shell=.zsh
2026-02-03 11:50:18.062781+0100 0x1b0ca    Info        0x0                  15416  0    ghostty: [com.mitchellh.ghostty:ghostty] known but unimplemented action action=22
2026-02-03 11:50:18.067453+0100 0x2da35    Info        0x0                  15416  0    ghostty: [com.mitchellh.ghostty:io_exec] io_exec: started subcommand path=/usr/bin/login pid=20808
2026-02-03 11:50:23.379083+0100 0x1b0ca    Error       0x0                  15416  0    ghostty: [com.mitchellh.ghostty:ghostty] unknown action action=57

Ghostty Version

Ghostty 1.3.0-main+51897c0cd

Version
  - version: 1.3.0-main+51897c0cd
  - 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 Tahoe 26.2 (25C56) arm64

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# default config

Additional Relevant Configuration

.zshrc (zsh 5.9) with zinit v3.14.0-33-g701657f7 / oh-my-posh v28.10.0

ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git"
[ ! -d $ZINIT_HOME ] && mkdir -p "$(dirname $ZINIT_HOME)"
[ ! -d $ZINIT_HOME/.git ] && git clone https://github.com/zdharma-continuum/zinit.git "$ZINIT_HOME"

# either of the following trigger the bug
source "${ZINIT_HOME}/zinit.zsh"

# eval "$(oh-my-posh init zsh --config $HOME/.config/ohmyposh/config.toml)"

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.

[rajayonin]

Found the same issue on Linux:

Ghostty Logs

info: ghostty version=1.2.0-r2146.g6c0e02d-1-arch
info: ghostty build optimize=ReleaseFast
info: runtime=.gtk
info: font_backend=.fontconfig_freetype
info: dependency harfbuzz=12.3.2
info: dependency fontconfig=21701
info: renderer=renderer.generic.Renderer(renderer.OpenGL)
info: libxev default backend=io_uring
info(os_locale): setlocale from env result=LC_CTYPE=en_US.UTF-8;LC_NUMERIC=es_ES.UTF-8;LC_TIME=es_ES.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=es_ES.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=es_ES.UTF-8;LC_NAME=es_ES.UTF-8;LC_ADDRESS=es_ES.UTF-8;LC_TELEPHONE=es_ES.UTF-8;LC_MEASUREMENT=es_ES.UTF-8;LC_IDENTIFICATION=es_ES.UTF-8
info(gtk): GTK version build=4.20.3 runtime=4.20.3
info(gtk): libadwaita version build=1.8.4 runtime=1.8.4
info: reading configuration file path=/home/ldcas/.config/ghostty/config
info(config): default shell source=env value=/usr/bin/zsh
warning(gtk_ghostty_application): setting GDK_DEBUG=
warning(gtk_ghostty_application): setting GDK_DISABLE=gles-api,vulkan
info(gtk_ghostty_application): cgroup isolation disabled via config=.single-instance
info(opengl): loaded OpenGL 4.6
info(io_exec): found Ghostty resources dir: /usr/share/ghostty
info(io_exec): shell integration automatically injected shell=.zsh
warning(gtk_ghostty_application): unimplemented action=.cell_size
info(io_exec): started subcommand path=/bin/sh pid=140886
info(io_exec): subcommand cgroup=-

Ghostty Version

Ghostty 1.2.0-r2146.g6c0e02d-1-arch

Version
  - version: 1.2.0-r2146.g6c0e02d-1-arch
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.18.7-2-cachyos
  - desktop env   : gnome
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.3
  - libadwaita    : enabled
    build         : 1.8.4
    runtime       : 1.8.4
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

CachyOS (Linux 6.18.7-2-cachyos)

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 49.3

[jparise]

I haven't been able to reproduce this (on tip) using zinit or Oh My Post. I have a guess what might be happening though. Could you try this patch to zsh/ghostty-integration?

diff --git a/src/shell-integration/zsh/ghostty-integration b/src/shell-integration/zsh/ghostty-integration
index 8cd3dde7a..f505dd9d4 100644
--- a/src/shell-integration/zsh/ghostty-integration
+++ b/src/shell-integration/zsh/ghostty-integration
@@ -239,6 +237,19 @@ _ghostty_deferred_init() {
 	  builtin print -rnu $_ghostty_fd \$'\\e[0 q'"
     fi
 
+    functions[_ghostty_zle_line_init]+="
+        if (( _ghostty_state == 0 )); then
+            builtin local mark=\$'%{\\e]133;A;cl=line\\a%}'
+            builtin print -rnu $_ghostty_fd -- \$mark[3,-3]
+        fi"
+
     # Add Ghostty binary to PATH if the path feature is enabled
     if [[ "$GHOSTTY_SHELL_FEATURES" == *"path"* ]] && [[ -n "$GHOSTTY_BIN_DIR" ]]; then
       if [[ ":$PATH:" != *":$GHOSTTY_BIN_DIR:"* ]]; then

[rajayonin]

Didn't seem to solve it

[jparise]

#11165 should be the complete fix.

[jparise]

And #11367 further improves precmd_functions order, although there's still one first-line case we don't handle.

[mitchellh]

cc @jparise I don't have time to look right now but this is intriguing.

[jparise]

I have a sense I know what's going on here. I'll work on fixing it, but it will take me a little bit to set up an Oh My Posh environment to make sure it addresses what's being reported.

[diego898]

Hello - I also have a similar (I tihnk?) problem - Im on Ghostty 1.3.1 with shell integration enabled (as verified in the logs) using powerline 10k.

Here, it is correctly detecting prompt and input, but I cannot click to different positions in the input text, until I press enter and "get past" the first input on a new ghostty window.

@rajayonin - was this solved for you?

@jparise - Im not quite sure if this is the exact same issue as the original poster. If so, I can make a new discussion.

Thanks!

EDIT: I'm also not sure that last "elbow" on the right is supposed to be marked input ?

─╯

[jparise]

Could you share more details about your specific configuration? As noted in my last commit in this series (#11367), there's still one type of precmd_functions interaction that we don't support for the very first prompt.