OSC 10 color query reply typed into /config search input under tmux

What's Wrong?

Running Claude Code inside tmux, the string ]10;rgb:8f8f/f5f5/8686 gets typed into the /config settings search box. Pressing Esc in the dialog is what seems to trigger it here.

That string is my terminal's reply to an OSC 10 "what is your foreground color?" query, minus the leading ESC byte. The full reply on this machine is exactly:

\x1b]10;rgb:8f8f/f5f5/8686\x07

Verified by sending printf '\033]10;?\007' from a raw-mode pane in the same tmux session and reading the reply back.

So the color query reply is landing in the input buffer as keystrokes: the ESC byte gets consumed (or read as the Esc key), and the rest is inserted as literal text.

Two details that might help locate it:

• The 2.1.201 binary contains the reply parser (rgb:([0-9a-f]{1,4})\/...), so the response is normally consumed correctly. This looks like a race between the reply and real keyboard input, in this case my Esc press.
• Under tmux the reply round-trips through the outer terminal asynchronously (a detached tmux session returns no reply at all), so it can arrive well after the query, interleaved with keystrokes.

#12910 reported the same symptom on 2.0.56 (replies leaking into the main input box). It was closed by the stale bot and locked, so filing fresh per the bot's instruction.

What Should Happen?

Color query replies should never reach text inputs, regardless of how they interleave with keypresses.

Steps to Reproduce

1. Run claude inside tmux 3.6a on Ghostty
2. /config, move to the Config tab (search input focused)
3. Press Esc
4. ]10;rgb:... appears in the search input ("No settings match ...")

Timing dependent, so step 4 doesn't fire every time.

Environment

• Claude Code 2.1.201 (native install, arm64)
• macOS 15.7.4
• tmux 3.6a
• Ghostty 1.3.2
• zsh

Is this a regression?

First noticed on 2.1.201. Possibly related to the 2.1.200 change "Fixed rendering flicker under tmux 3.4+ by enabling synchronized terminal output", not verified.