Ctrl+H (delete previous character) is misinterpreted as Ctrl+Backspace (delete word) under WSL2 due to WT_SESSION leaking from Windows Terminal

Start in the bundled app.js at fSt() and its reader initialization, then verify how WT_SESSION and process.platform affect ctrlHIsCtrlBackspace before checking ZDe(). Reproduce under WSL2 with WT_SESSION set and unset; done when Ctrl+H deletes one character while native Windows behavior remains unchanged.

Description

/help documents ctrl+h as "delete previous character", but under WSL2 it instead deletes the whole previous word (i.e. behaves like ctrl+w/Ctrl+Backspace).

Environment

• Copilot CLI version: 1.0.78-2
• Platform: WSL2 (Linux ... 6.18.33.2-microsoft-standard-WSL2), Windows Terminal as host, plain xterm-256color inside (issue reproduces both inside and outside tmux)
• WSLENV=WT_SESSION:WT_PROFILE_ID: (default WSL/Windows Terminal integration), so WT_SESSION is present in the WSL shell environment even though the CLI is not running as a native Windows process

Root cause

In the bundled app.js, the raw-byte key decoder special-cases byte 0x08 (\b) — which is exactly what Ctrl+H sends — as Ctrl+Backspace when a ctrlHIsCtrlBackspace flag is set:

function ZDe(t, e=!1) {
  return t.length!==1 ? null
    : t==="\r" ? {code:"return"}
    : ...
    : t==="\b" && e ? {code:"backspace", ctrl:!0}   // <-- Ctrl+H reinterpreted as Ctrl+Backspace
    : t==="\b" || t==="\x7F" ? {code:"backspace"}
    : ...
}

The flag is computed once at startup:

reader = new ope({ ctrlHIsCtrlBackspace: fSt() })

function Nk() { return !RA() && !process.env.TMUX && !process.env.STY }
function fSt() { return process.platform==="win32" && Nk() || !!process.env.WT_SESSION }

The intent is reasonable on native Windows (Windows Console/Windows Terminal apps can't distinguish a literal Ctrl+H keypress from Ctrl+Backspace, since both produce byte 0x08), so trading away the Ctrl+H binding there makes sense. However, the || !!process.env.WT_SESSION clause has no accompanying process.platform==="win32" check, so it also fires under WSL2, where WT_SESSION is forwarded into the Linux environment by WSLENV for terminal-integration purposes, but the CLI is actually running in a normal Linux pty where Ctrl+H and Ctrl+Backspace are distinguishable. This causes a false positive: the workaround for a Windows-only ambiguity ends up breaking a real, distinguishable keybinding on WSL.

This also affects users in the reverse scenario, if WT_SESSION is otherwise present in the environment (e.g. propagated through SSH or subshells) on non-Windows platforms.

Steps to reproduce

1. Launch Copilot CLI inside WSL2 under Windows Terminal (default WSLENV integration).
2. Type some text, then press Ctrl+H.
3. Expected: deletes one character before the cursor (per /help).
4. Actual: deletes the entire previous word.

Suggested fix

Gate the WT_SESSION check on process.platform === "win32" as well, e.g.:

function fSt() {
  return process.platform === "win32" && (Nk() || !!process.env.WT_SESSION);
}

or otherwise detect WSL (e.g. via /proc/version containing "microsoft" or process.platform !== "win32") and skip the ctrlHIsCtrlBackspace heuristic in that case.

Workaround

unset WT_SESSION before launching copilot restores the documented Ctrl+H behavior.