opentui icon indicating copy to clipboard operation
opentui copied to clipboard

Kitty Graphics Protocol query leaks Gi=31337 response into tmux pane title

Open festeh opened this issue 2 weeks ago • 5 comments

Describe the bug

When running an application using @opentui/core (opencode) inside tmux, a cryptic string resembling Gi=31337,s=1,v=1,a=q,t=d,f=24;AAAA appears in the tmux pane title or leaks into the shell output immediately after startup.

Root Cause

The issue stems from the queryTerminalSend function in packages/core/src/zig/terminal.zig, which sends the kittyGraphicsQuery escape sequence unconditionally during initialization. https://github.com/sst/opentui/blob/main/packages/core/src/zig/terminal.zig#L176 // packages/core/src/zig/terminal.zig ansi.ANSI.kittyGraphicsQuery ++ This sends \x1b_Gi=31337... to probe for Kitty graphics support. When running inside tmux, the terminal's response to this query is often not trapped correctly by the application.

To Reproduce

  1. Start tmux.
  2. Run an opentui-based application (e.g., opencode).
  3. Observe that the pane title changes to the graphics query response

Proposed Solution

  1. Conditionality: The graphics probe should not be sent unconditionally. It should check if the environment supports it or if a specific environment variable is set to disable it.
  2. Tmux Support: If the intention is to support graphics inside tmux, the query should be wrapped in the correct passthrough escape sequence when TERM=screen or TERM=tmux.
  3. Escape Hatch: Add an environment variable (e.g., OPENTUI_NO_GRAPHICS) that allows users to disable this specific probe entirely.

festeh avatar Nov 21 '25 21:11 festeh

Yeah, that is annoying. Problem is that this is how the docs/specs suggest to detect if it is supported. I think the passthrough wrapping could work when it's local, but for remote it would have to wait and hope for xtversion and in many cases tmux rewrites to tell it's the underlying terminal and not tmux, so remote it wouldn't know. Confusing.

I'd try the passthrough wrapping if it is detected as tmux for now.

kommander avatar Nov 22 '25 00:11 kommander

I tried to work on it and eventually decided to abandon tmux entirely, so I'm no longer looking for a fix. I still have some working code that checks if we're in tmux and not sends kitty query in this case. It's more complicated than #343, no not sure if I should open a PR.

festeh avatar Nov 26 '25 12:11 festeh

Yeah, I hate tmux by now. There is still zellij, but has other issues. Not solving this is probably not an option as too many people are still using it.

So either:

  • there is another way to detect kitty graphics support
  • we find the root cause for tmux treating it as title replacement and work around it
  • or tmux fixes it (doubt)

kommander avatar Nov 26 '25 13:11 kommander

It turned out kitty already has what I need - project-based sessions (with session files), switching between them can be done with hyprland workspaces and ssh persistence is possible with systemd daemons. So I'm living happily without tmux now.

Now, I tinkered with opencode on this issue and we came to conclusion that we don't know how to fix it when the kitty graphics query is sent, regardless of allowing passthrough or adding some weird char sequences that AI did for tmux-specific query. I think it requires some deeper tmux expertise to go with option 2.

festeh avatar Nov 26 '25 16:11 festeh

Thanks for looking into it, I am currently out of ideas, will get back to it.

kommander avatar Nov 26 '25 18:11 kommander