Fix Windows Ctrl+J key event in ConPTY

[AndreKalberer]

Description

Fixes ConPTY input encoding for Ctrl-letter chords when an application enables Windows Terminal's private Win32 input mode (CSI ? 9001 h). Warp now tracks that mode and emits Win32 input record sequences for Ctrl+A-Z, preserving the original virtual key. This keeps Ctrl+J as VK_J instead of letting downstream clients infer Enter from the LF control character.

Linked Issue

Closes #11688

• The linked issue is labeled ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below.

Testing

• Added parser coverage for private Win32 input mode (CSI ? 9001 h).

• Added regression coverage that Ctrl+J emits VK_J in Win32 input mode.

• cargo fmt - cargo test -p warp_terminal

• cargo check -p warp --tests

• cargo clippy -p warp_terminal --tests -- -D warnings

• I have manually tested my changes locally with ./script/run

Screenshots / Videos Ctrl+J validation video:

Screen.Recording.2026-07-01.173407.mp4

The PR build reports:

• wVirtualKeyCode=0x004a (VK_J)
• uChar=0x000a (LF)
• PASS: Ctrl+J is reported as VK_J with LF.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed Ctrl+J in Codex CLI on Windows being reported as Ctrl+Enter.

[oz-for-oss]

@AndreKalberer

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @acarl005.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR adds support for Windows Terminal's private Win32 input mode in the terminal parser/model and emits Win32 input record sequences for Ctrl+A-Z chords so Ctrl+J preserves VK_J instead of being inferred as Enter.

Concerns

• No blocking correctness, security, or spec-alignment concerns found in the attached diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[acarl005]

@AndreKalberer Thanks for submitting the fix. Please upload a video demonstrating that ctrl+j works as intended and then I'll review.

[AndreKalberer]

Video demonstrating Ctrl+J in the PR build:

• wVirtualKeyCode=0x004a (VK_J)
• uChar=0x000a (LF)
• probe reports PASS: Ctrl+J is reported as VK_J with LF.

Video file to upload:

Screen.Recording.2026-07-01.173407.mp4

[github-actions]

Hi @AndreKalberer — a reviewer requested changes on this PR and it hasn't had activity from you in 7 days. When you get a chance, please push updates or reply to the review so a reviewer can take another look. Without activity, this PR will be automatically closed after 14 days of inactivity.

[AndreKalberer]

@acarl005 I uploaded the requested Ctrl+J demo above and added it to the PR description. The video shows the PR build reporting wVirtualKeyCode=0x004a (VK_J) with uChar=0x000a (LF), and the probe passes. Let me know if you need any other validation.

[acarl005]

@AndreKalberer Sorry review is taking so long. I wasn't expecting the fix to entail adding recognition for a whole new input protocol. It's deeper than I expected. I'll have to get to this next week.

[acarl005]

It was my mistake to label this as ready-to-implement. This is a very risky change. ConPTY unconditionally requests the Win32 input mode on all sessions upon creation. Recognizing this sequence will enable this input mode for all Windows users for all sessions, not just when using Codex (what the original issue was about). Furthermore, this PR only implements a small part of the protocol (Win32 input mode).