[BUG] Malformed tmux passthrough at startup: Claude emits ESC t m u x ; (missing the P), printing "mux;" on the prompt line (Windows/Cygwin, tmux)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

At startup under tmux, the text mux; lands on the prompt line as visible garbage. It comes from a malformed tmux passthrough sequence in Claude Code's own output.

Claude emits ESC t m u x ; (1b 74 6d 75 78 3b). The correct tmux passthrough DCS introducer is ESC P tmux; (1b 50 74 6d 75 78 3b). Claude's version is missing the P (0x50) right after the ESC. The proper introducer with the P never appears in the capture, only this P-less form, and it appears once. The terminal swallows the leading ESC t as a bogus two-byte escape and prints the remaining mux; as literal text.

This is display-only garbage on the prompt line. It is cosmetic, but it is Claude writing a malformed control sequence, not the terminal misbehaving.

What Should Happen?

Either a well-formed tmux passthrough (ESC P tmux; ... ESC \) or nothing. The literal string mux; should never appear on the prompt line.

Steps to Reproduce

1. From a Cygwin shell inside tmux (mintty as the outer terminal), start Claude Code.
2. Watch the prompt line as the UI first paints.

Expected: a clean prompt.
Actual: mux; appears as visible text on the prompt line.

With $TMUX unset (Claude started outside a tmux session), the sequence is not emitted at all and the prompt is clean, which confirms the emission is gated on the tmux environment.

Claude Code Version

v2.1.212, run via npx --yes @anthropic-ai/claude-code@latest

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other: Cygwin mintty with tmux 3.2. Not emitted when $TMUX is unset.

Is this a regression?

I don't know

Additional Information

Environment

• Claude Code v2.1.212, run via npx --yes @anthropic-ai/claude-code@latest
• Windows 10 Pro
• Cygwin 3.6.x, Windows node v24.x (process.platform reports win32)
• tmux 3.2, mintty as the outer terminal
• Gated on the tmux environment: with $TMUX unset the sequence is not emitted

Byte-level detail

Raw output was captured with tmux pipe-pane, which records the exact bytes the program writes.

| What | Bytes | Note |
|---|---|---|
| What Claude emits | 1b 74 6d 75 78 3b | ESC t m u x ;, no P |
| Correct introducer | 1b 50 74 6d 75 78 3b | ESC P t m u x ; |

The 0x50 (P) is the only missing byte. The terminal reads ESC t as a bogus escape, discards it, and renders mux; as text.

Not fixed by the fullscreen repaint workaround

CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 does not remove the malformed sequence. The sequence is still emitted; the full repaint just paints over the visible mux; afterward. Unsetting $TMUX is what stops the emission.

| Intervention | mux; leak |
|---|---|
| none | present |
| CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 | still emitted, painted over |
| $TMUX unset | gone |

Related

This was found alongside a separate main-screen input-renderer bug on the same Cygwin path (a stray backspace before the first keystroke after an idle gap), filed as #78737. The two are independent: each of the two known fixes removes exactly one symptom, and they live in different code paths. This report is the tmux-passthrough half, split out per the "file separate reports for different bugs" guidance.

Search caveat

We cannot prove exhaustiveness. The repo has a very large issue count and our queries were English and symptom-based, so a differently-worded report could exist.