[BUG] Backspace ↔ Ctrl+Backspace inverted in input after Ctrl+G → external editor → quit (Windows Terminal)

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?

After spawning $EDITOR via Ctrl+G and quitting it, the Claude Code input box's Backspace and Ctrl+Backspace bindings are swapped:

• Backspace deletes the previous word (should delete one character).
• Ctrl+Backspace deletes one character (should delete a word).

The behaviour is correct on a fresh CC session and only flips after the editor round-trip. The inversion persists for the rest of the session. Crucially, /quit followed by claude in the same terminal tab restores correct behaviour — so CC's startup is sending the right input-mode init; it just isn't re-sent when control returns from $EDITOR.

This looks like the same mechanism as #51250 (closed, macOS, /memory trigger) and #38761 (closed, macOS), and is plausibly the root cause of the symptom reported in #51841 (open, Windows, no reproducer).

What Should Happen?

Plain Backspace should delete a single character; Ctrl+Backspace should delete the previous word — both consistently throughout the CC session, regardless of whether the user has used Ctrl+G to open $EDITOR and returned.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code in Windows Terminal (Git Bash shell here; PowerShell also reported in #51841).
2. In the input box, type a few words. Press Backspace. Expected: one character removed. Actual: one character removed. ✓
3. Press Ctrl+G to open $EDITOR (nvim) on the buffer.
4. In nvim, type :q and press Enter to return to CC.
5. In the CC input, type a few words. Press Backspace. Expected: one character removed. Actual: the whole previous word is removed.
6. Press Ctrl+Backspace. Expected: the previous word removed. Actual: one character removed. The bindings are swapped.

Two ways to recover, both consistent with the diagnosis below:

• /quit then claude in the same tab → normal behaviour is back. (CC's startup init clears the leaked state.)
• In a separate shell, run printf '\e[>4;0m' (just disables xterm modifyOtherKeys) or reset (heavier).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Diagnosis (best guess)

$EDITOR (nvim, in this case) enables xterm modifyOtherKeys (or the CSI-u / kitty keyboard protocol) on startup to get richer modifier reporting. On exit it should send the de-init sequence to restore the prior encoding, but doesn't always — depends on nvim version, plugins, terminal, and how the editor was launched.

After nvim exits, modified keys like Ctrl+Backspace are encoded differently on the wire (e.g. as \e[127;5u instead of a plain control byte). Claude Code's input handler is still using its pre-editor keymap, so it interprets the new sequences as if they were the old ones — hence the swap.

The fact that /quit && claude in the same tab restores correct behaviour proves CC has the right input-mode init sequence; it just isn't re-sent after spawning $EDITOR. A robust fix would be to re-send CC's own input-mode init when control returns from a child $EDITOR process, so CC is not at the mercy of whatever state the editor left behind. The same fix would address the closed reports #51250 and #38761 (different triggers, same leakage class) and likely the Windows symptom in #51841.

$EDITOR details

• nvim v0.12.2 (LuaJIT 2.1.1774638290)

Workarounds for users (until fixed)

• /quit then claude in the same tab.
• Or, in a separate shell: printf '\e[>4;0m'.
• Or fix the editor side — for nvim, add to init.lua:

vim.api.nvim_create_autocmd("VimLeave", {
  callback = function()
    local ESC = string.char(27)
    io.write(ESC .. "[>4;0m")  -- disable xterm modifyOtherKeys
    io.write(ESC .. "[<u")      -- disable kitty keyboard protocol if enabled
    io.flush()
  end,
})

Environment beyond the dropdowns

• Windows 11 Pro (build 10.0.26200.0)
• Windows Terminal 1.24.10921.0
• Shell: Git Bash (MSYS2 MINGW64)

Related issues

• #51841 — same symptom, Windows, PowerShell, no reproducer. This report likely identifies its root cause.
• #51250 — same mechanism, macOS, /memory trigger (closed). Worth checking whether the fix can be extended to the Ctrl+G editor path on Windows.
• #38761 — same mechanism, macOS, "terminal left in enhanced keyboard mode after exit" (closed).
• #39870 — Ctrl+G external editor on Linux, different symptom (job control).
• #51363 — Ctrl+G external editor on Windows, different symptom (arrow keys not forwarded to child PTY in Helix). The Ctrl+G editor flow has accumulated several Windows-specific edge cases.