[BUG] Ctrl+G external editor receives no keyboard input inside ConPTY-based terminal multiplexers on Windows (refiling #73301)

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?

Refiling #73301, which the stale bot closed on 2026-08-31 with "Please open a new issue if this is still relevant". It is still relevant, and I have narrowed it down considerably since.

When Claude Code runs inside a ConPTY-based terminal multiplexer on Windows, pressing Ctrl+G opens the external terminal editor and it renders correctly, but no keystroke ever reaches it — i, Esc and Ctrl+C are all dead. The session has to be killed with stop-process. #73301 reported the identical symptom under WezTerm; I hit it under psmux and wtmux, so it is not specific to one terminal.

The key new finding: this reproduces with no Claude Code code involved. A 13-line Node script that only puts stdin in raw mode, waits for one key, leaves raw mode and spawns an editor with stdio: 'inherit' fails exactly the same way in the same pane (script under Steps to Reproduce). That points at Node/libuv console-input handling on Windows rather than at Claude Code's own logic — but Claude Code is where users hit it, and a client-side mitigation looks possible.

It is non-deterministic. On one attempt, pressing Enter immediately after the editor opened unblocked everything and editing then worked normally. On the very next attempt the same Enter did nothing, and repeated Enters dropped back into Claude Code and hung it. That intermittency is consistent with a race between an uncancelled parent console read and the child's read. Corroborating detail: during one failure, an i keystroke intended for the editor was later delivered into Claude Code's own prompt as a submitted message — the parent was still consuming input meant for the child.

What Should Happen?

The external editor should receive keyboard input, as it does in every other environment I tested (see the control matrix below).

Error Messages/Logs

(none - no error is printed. The editor draws correctly and simply
never receives a keystroke. The terminal window itself survives;
only input is lost.)

Steps to Reproduce

1. Windows 11, Windows Terminal, Claude Code launched under Git Bash (MSYSTEM=MINGW64, TERM=xterm-256color), running inside a psmux or wtmux pane.
2. Set env.EDITOR in ~/.claude/settings.json to a terminal editor, e.g. "C:/PROGRA~1/Vim/vim92/vim.exe".
3. Restart Claude Code, type anything at the prompt, press Ctrl+G.
4. vim opens and shows the prompt text. Press i, then Esc, then Ctrl+C — none of them do anything.

Minimal reproduction without Claude Code. Save as repro.js and run node repro.js in such a pane, press any key, then try i and Esc in the editor that opens:

// Parent holds stdin in raw mode, then hands the terminal to a child editor.
const { spawnSync } = require('child_process');
process.stdin.setRawMode(true);
process.stdin.resume();
console.log('raw mode on - press any key to launch the editor');
process.stdin.once('data', () => {
  process.stdin.setRawMode(false);
  process.stdin.pause();
  spawnSync(process.env.EDITOR || 'vim', ['--clean'], { stdio: 'inherit' });
  console.log('editor exited');
  process.exit(0);
});

Control matrix. These rule out the explanations one would reach for first:

| Parent | Environment | Editor gets input? |
|---|---|---|
| vim alone | Windows Terminal, direct | yes |
| vim alone | psmux pane | yes |
| git commit spawning the same vim.exe | psmux pane | yes |
| less (a raw-mode TUI), v to open the same vim.exe | psmux pane | yes |
| Claude Code | Windows Terminal, direct | yes |
| Claude Code | real tmux on WSL (my daily setup) | yes |
| Claude Code | psmux / wtmux pane | no |
| repro.js above | psmux pane | no |

So neither the multiplexer nor Claude Code is broken on its own: less proves a raw-mode TUI can hand over the terminal correctly in that same pane, and real tmux proves Claude Code's handover works in a multiplexer. The failure is the intersection, and repro.js shows the intersection does not require Claude Code at all.

Also ruled out, all failing identically: Windows vim.exe (term=win32) and MSYS2 /usr/bin/vim (term=xterm-256color); vim --clean with no vimrc at all; tui set to "default" and to "fullscreen".

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.263

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal + Git Bash (MINGW64), inside psmux / wtmux

Additional Information

• Access: Claude Code Max subscription (not Bedrock or Vertex; "Anthropic API" chosen above as the closest dropdown option)
• OS: Windows 11 Pro, 10.0.26200.9168
• Node: v24.19.0
• vim: 9.2 (Windows build) and the MSYS2 build shipped with Git for Windows
• psmux: 3.3.8 (66cf613 2026-08-18) — https://github.com/psmux/psmux
• wtmux — https://github.com/fukuyori/wtmux (same symptom, independent implementation)

Possible mitigation: fully tear down the stdin reader before spawning the external editor on Windows, rather than relying on setRawMode(false). A pending ReadConsoleInput cannot reliably be cancelled, which would explain both the swallowed keys and the intermittency. I have not verified that mechanism directly — it is inferred from the behavior above.

Workaround in use: set EDITOR to a GUI editor (gvim -f), which never touches the terminal's input path and works in every environment above.

Upstream: I searched nodejs/node and libuv/libuv and found no existing report of this specific symptom. nodejs/node#63852 (Windows console input when stdin is a pipe, closed 2026-08-18) is adjacent but a different scenario. I have not filed upstream myself, since whether this is an upstream defect or something to work around client-side seems better judged by the Claude Code team.

Related issues:

• #73301 (closed as stale) — identical symptom under WezTerm. This report supersedes it.
• #84264 (open) — Ctrl+G with a terminal $EDITOR on Windows, but there the Windows Terminal window is destroyed outright; here the terminal survives and only input is lost.
• #58664 (closed, not planned) — Ctrl+G spawn on Windows + Cygwin/MSYS2, TUI hangs instead of launching vim.

Note: I also submitted this through /feedback before filing here — receipt 26f7a929-e69c-4f25-9354-042ffa20e4df. Filing publicly as well so the issue is trackable and other people hitting it can find it.