Shift+Enter multiline input broken in WSL2 terminal (regression in 2.1.70)

Environment

• OS: Windows 11 (VSCode native) + WSL2 (Ubuntu) — Claude Code runs as a Linux process inside WSL2
• Terminal: VSCode integrated terminal using a WSL2 bash profile (no Claude Code VSCode extension)
• Claude Code: 2.1.69 (working) → 2.1.70 (broken)
• Note: Claude Code has no visibility into the VSCode host from WSL2, so native terminal detection (terminal === "vscode") does not apply. The sendSequence workaround is the only viable multiline input path for this configuration.

Description

In VSCode with WSL2, the standard workaround for multiline input uses a custom keybinding that sends \\\r\n on Shift+Enter. This worked correctly through v2.1.69 but broke in v2.1.70.

VSCode keybindings.json (working config on 2.1.69):

[
    {
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\\\r\n"
        },
        "when": "terminalFocus"
    }
]

Expected Behavior

Shift+Enter appends a line continuation (\\) and moves to a new input line without submitting the prompt.

Actual Behavior in 2.1.70

Shift+Enter submits the input immediately — the \\\r\n sequence is ignored and the prompt is sent to Claude for evaluation as if Enter was pressed.

Attempted Workaround (also failed)

Added a WSL-specific binding using bracketed paste mode escape sequences:

[
    {
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\\\r\n"
        },
        "when": "terminalFocus"
    },
    {
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\^[[200~\r\n\^[[201~"
        },
        "when": "terminalFocus && remoteName == 'wsl'"
    }
]

This did not restore the expected behavior in 2.1.70.

Workaround

Pin to v2.1.69.