F13-F20 do not send proper Kitty protocol escape sequences in applications that support Kitty protocol

[hajdamak]

Windows Terminal version

1.25.1322.0

Windows build number

10.0.26200.8390

Other Software

Latest versions of Nushell, Yazi

Steps to reproduce

• Trigger any of F13-F20 keys using keyboard that have them or using AutoHotKey (or any other software that is able to generate such key press) to generate them
• Applications that supports Kitty protocol (for example Yazi or Nushell with Kitty protocol enabled) it seems do not receive proper Kitty sequences but rather traditional ones. This makes keybindings in these applications to not work at all or work incorrectly, for example F18 is recognized in Nushell and Yazi as F15.

Expected Behavior

F13-F20 should generate proper Kitty protocol escape sequences in applications that support Kitty protocol. So they can properly use these keys in bindings.

Actual Behavior

Traditional escape sequences are sent to applications that support Kitty protocol for F13-F20 keys which breaks keybindings for these keys.

[danyalahmed1995]

I was able to reproduce this at the raw Windows Terminal input layer, without involving Nushell/Yazi.

Environment:

• Windows Terminal: 1.25.1322.0
• Shell: PowerShell 7.6.1
• WT_SESSION present

I requested Kitty keyboard mode with ESC[>1u, then sent VK_F13 through VK_F20. The output still used legacy sequences for the keys that produced output:

• F13 / VK 0x7C: ESC[25~
• F14 / VK 0x7D: ESC[26~
• F15 / VK 0x7E: ESC[28~
• F18 / VK 0x81: ESC[32~
• F19 / VK 0x82: ESC[33~
• F20 / VK 0x83: ESC[34~

Expected Kitty protocol output would be ESC[57376u through ESC[57383u.

So this appears to reproduce before Nushell/Yazi are involved.

I attached the small Python repro script I used for testing.

kitty_fkey_probe.py

[danyalahmed1995]

I opened #20246 for this.

This reproduces in the raw Terminal input path. The PR adds a regression test for Kitty disambiguation mode and adjusts the F13-F24 path so those keys use CSI-u instead of falling through to the legacy function-key handling.

[hajdamak]

• @danyalahmed1995 Do you know maybe whether this might also solve F16 Is not usable in Terminal #14907 ?

[danyalahmed1995]

Not exactly my PR #20246 covers Kitty protocol input-encoding layer because the fix handles the full F13-F24 range. So if #14907 is about F16 producing the wrong escape sequence under Kitty disambiguation mode.

#20246 covers F16 once it reaches the TerminalInput Kitty encoding path as VK_F16. In that case it should now be handled with the rest of the F13-F24 range instead of falling through to legacy function-key handling.

From the older discussion in #14907 though, it sounds like that issue may happen earlier, where F16 is not reaching TerminalInput as VK_F16 at all, or is being reported as a different key.

[hajdamak]

@danyalahmed1995 Do you know maybe whether this earlier stage is still in Windows Terminal?

[danyalahmed1995]

I haven’t re-tested the #14907 path on a patched build.

In my raw repro for this issue, F16/F17 did not produce useful output, while the other F13-F20 keys showed the legacy sequence fallback. #20246 covers F16/F17 in the TerminalInput Kitty encoding path via the F13-F24 regression test, but if #14907 is about F16/F17 not reaching TerminalInput at all, that would still be a separate earlier-stage issue.

[danyalahmed1995]

I did a quick check against my installed Windows Terminal 1.25.1322.0, not a patched build.

With the same raw repro script, F13/F14/F15 and F18/F19/F20 still produce the legacy fallback sequences, but F16/F17 did not produce output in that test. So the earlier-stage F16/F17 behavior from #14907 may still be separate from #20246.

#20246 covers the Kitty encoding path once the key reaches TerminalInput as VK_F16/VK_F17, but it probably does not address a case where those keys are not delivered to that layer at all. I used the same python script that i attached in my earlier comment.

Attached a screenshot for it