[BUG] Ctrl-G external editor issues (micro) with kitty keyboard protocol

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?

Claude Code enables the kitty keyboard protocol on the terminal but doesn't properly handle the resulting CSI u escape sequences in certain states. This causes raw escape sequences to appear as literal text input instead of being interpreted as key presses.

What Should Happen?

• Ctrl-S should trigger the save action in micro when using it as an external editor via Ctrl-G
• Ctrl-G should open the external editor with full keyboard functionality
• CSI u sequences should never appear as literal text in any context

Error Messages/Logs

Steps to Reproduce

Environment

• Terminal: iTerm2 (macOS)
• CSI u / "Report modifiers using CSI u": Disabled in iTerm2 Preferences
• OS: macOS

Root Cause

Claude Code appears to request kitty keyboard protocol mode from the terminal (likely via \x1b[>u or similar), but then fails to parse the CSI u formatted
responses. Since the terminal is in kitty protocol mode at Claude Code's request, keystrokes are sent as CSI u sequences (e.g., \x1b[115;5u for Ctrl-S), and
these are rendered as literal text rather than interpreted.

This also affects spawned child processes (e.g., the external editor opened via Ctrl-G), which inherit the terminal's kitty protocol state but have no awareness
of it.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.42

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Related Issues

• #10375 — Focus reporting escape sequences injected into input
• #21766 — Escape sequences constantly outputting to input line
• #5196 — Terminal input handling breaks keyboard shortcuts on macOS