Ctrl+G external editor on Windows: arrow-key escape sequences not forwarded to child PTY (Helix unusable)

Summary

On Windows, pressing Ctrl+G to open $EDITOR (Helix in my case) launches the editor, but CSI escape sequences for arrow keys are not forwarded intact. After pressing Esc to enter Helix normal mode, the right arrow (which should send ESC [ C) is delivered to Helix as a bare C — arrow keys behave as if the ESC [ prefix was stripped or consumed. Left/up/down behave the same.

Helix works correctly when launched directly from the same terminal (Windows Terminal + PowerShell, or Git Bash). Only the Claude-Code-spawned instance is broken.

Steps to reproduce

1. On Windows, install Helix and set EDITOR=C:\path\to\hx.exe
2. Launch Claude Code in Windows Terminal (tried both PowerShell and Git Bash)
3. Press Ctrl+G in the chat input
4. In Helix: type some text (insert mode works fine), press Esc → press right arrow
5. Observe: C command triggered (change selection) instead of cursor-right

Expected

Helix receives full escape sequences (ESC [ A/B/C/D) for arrow keys, same as when launched directly.

Actual

Only the final character of the escape sequence reaches Helix. Esc appears to be consumed or split from its trailing [ X.

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Terminal: Windows Terminal (default settings)
• Shells tried: PowerShell 5.1, Git Bash (bash 5.x)
• Claude Code: 2.1.116
• Node: v22.22.2
• Editor: Helix 25.07.1
• TERM=xterm-256color

Workaround

Wrap the editor in a .cmd that uses start "Helix" /wait hx.exe %*. This spawns a new console window with a fresh TTY and blocks until the editor exits. Suggests the issue is specifically with how Claude Code's embedded PTY forwards escape sequences to the spawned child — not a PATH/env issue, since the fresh console works fine.

Note

Presumably affects any terminal-mode editor (vim, nvim, nano, micro) on Windows, not just Helix.