Describe the bug
Describe the bug
When launching Copilot CLI inside a native-Windows zellij session, the input box is pre-filled on startup with a raw terminal escape sequence:
[?61;6;7;22;23;24;28;32;42c
This is a Primary Device Attributes (DA1) reply — the response to a ESC [ c capability query. It's meant to be consumed silently, but instead the raw bytes land in the prompt as if typed. I have to clear the box (Ctrl+U) before every session.
This looks like the same class of bug as the already-fixed #36 ("Input box always filled with escape sequence ]11;rgb:… on start"), which niik traced to Copilot querying the host terminal at startup (there: OSC 11 background color). That fix (0.0.355) evidently didn't cover the DA1 ( ESC[c ) query path.
Affected version
Copilot CLI 1.0.75 (win32-x64)
Steps to reproduce
- On Windows 11, open Windows Terminal.
- Start a native-Windows zellij session ( zellij ).
- Inside a zellij pane, launch copilot .
- Observe the input box pre-filled with
[?61;6;7;22;23;24;28;32;42c .
Expected behavior
The DA1 reply is consumed by Copilot CLI; the input box starts empty.
Environment
• Copilot CLI: 1.0.75 (win32-x64)
• OS: Windows 11 Enterprise, build 26200
• Terminal emulator: Windows Terminal 1.18.10301.0
• Multiplexer: zellij 0.44.3 (native Windows — no WSL), which added a "host query forwarding" system in 0.44.x that relays capability queries between the inner app and the host terminal. The DA1 reply appears to arrive after Copilot has stopped reading, so it leaks into the input buffer.
• TERM : (unset on native Windows)
• Process chain: zellij → pwsh → copilot
Additional context
• Does not occur when running copilot directly in Windows Terminal (no zellij) — pointing to a timing/consume issue on the query-response path when a multiplexer sits in between.
• Decoded sequence: ESC [ ? 61 ; 6 ; 7 ; 22 ; 23 ; 24 ; 28 ; 32 ; 42 c = DA1 reply, VT conformance level 61 + advertised feature codes.
• Related prior fix: #36 (OSC 11 reply on start, fixed in 0.0.355).
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response
Describe the bug
Describe the bug
When launching Copilot CLI inside a native-Windows zellij session, the input box is pre-filled on startup with a raw terminal escape sequence:
[?61;6;7;22;23;24;28;32;42c
This is a Primary Device Attributes (DA1) reply — the response to a ESC [ c capability query. It's meant to be consumed silently, but instead the raw bytes land in the prompt as if typed. I have to clear the box (Ctrl+U) before every session.
This looks like the same class of bug as the already-fixed #36 ("Input box always filled with escape sequence ]11;rgb:… on start"), which niik traced to Copilot querying the host terminal at startup (there: OSC 11 background color). That fix (0.0.355) evidently didn't cover the DA1 ( ESC[c ) query path.
Affected version
Copilot CLI 1.0.75 (win32-x64)
Steps to reproduce
[?61;6;7;22;23;24;28;32;42c.Expected behavior
The DA1 reply is consumed by Copilot CLI; the input box starts empty.
Environment
• Copilot CLI: 1.0.75 (win32-x64)
• OS: Windows 11 Enterprise, build 26200
• Terminal emulator: Windows Terminal 1.18.10301.0
• Multiplexer: zellij 0.44.3 (native Windows — no WSL), which added a "host query forwarding" system in 0.44.x that relays capability queries between the inner app and the host terminal. The DA1 reply appears to arrive after Copilot has stopped reading, so it leaks into the input buffer.
• TERM : (unset on native Windows)
• Process chain: zellij → pwsh → copilot
Additional context
• Does not occur when running copilot directly in Windows Terminal (no zellij) — pointing to a timing/consume issue on the query-response path when a multiplexer sits in between.
• Decoded sequence:
ESC [ ? 61 ; 6 ; 7 ; 22 ; 23 ; 24 ; 28 ; 32 ; 42 c = DA1reply, VT conformance level 61 + advertised feature codes.• Related prior fix: #36 (OSC 11 reply on start, fixed in 0.0.355).
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response