[BUG] [2.1.83] CapsLock outputs [57358u escape sequences in VSCode integrated terminal when multiple terminals are open
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?
When running claude inside VSCode integrated terminal with multiple terminals open, pressing CapsLock outputs repeated [57358u escape sequences as literal text instead of toggling CapsLock. This does not occur in the native macOS Terminal app.
Claude Code activates the kitty keyboard protocol (KKP) on session start. When multiple VSCode terminals are open, the KKP state leaks across terminals after switching between them — the terminal that was not running Claude starts receiving raw KKP escape sequences on key input.
What Should Happen?
CapsLock should toggle normally with no terminal output.
Error Messages/Logs
[57358u[57358u[57358u[57358u[57358uThis appears on the input line every time CapsLock is pressed while a Claude session is active.
Steps to Reproduce
- Open VSCode on macOS
- Open 2 or more integrated terminals
- Run
claudein one terminal (session starts) - Switch to another terminal (or stay in the same one)
- Press CapsLock
Expected: CapsLock toggles normally, no output
Actual: [57358u[57358u[57358u... is printed repeatedly
Is this a regression?
Yes, this worked in a previous version.
Last Working Version
2.1.81
Claude Code Version
2.1.83 (Claude Code)
Claude Model
Sonnet
Platform
Anthropic API
Operating System
macOS (Apple Silicon arm64)
Terminal/Shell
VS Code integrated terminal (zsh)
Additional Information
Workaround: Downgrade to 2.1.81 resolves the issue:
ln -sf ~/.local/share/claude/versions/2.1.81 ~/.local/bin/claude
export DISABLE_AUTOUPDATER=1 # add to ~/.zshrcSetting "terminal.integrated.enableExtendedKeys": false and "terminal.integrated.shellIntegration.enabled": false in VSCode settings did not resolve the issue, confirming that Claude Code itself is injecting KKP activation sequences directly into the pty regardless of VSCode settings.
Related Issues:
- #27001 — Kitty keyboard protocol causes raw escape sequences in external editors
- #27868 — KKP detection ignores KITTY_WINDOW_ID when TERM_PROGRAM is set
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Root Cause Analysis
After comparing the release notes between v2.1.81 and v2.1.83, the following fix in v2.1.83 is likely the culprit:
Mouse tracking (
\e[?1003hetc.) and the kitty keyboard protocol (KKP) share the same terminal raw mode entry/exit path. The fix for mouse tracking escape sequence leakage likely modified the cleanup logic, and in doing so, the KKP deactivation sequence (\e[<1uor equivalent) is either no longer being sent on session exit, or its timing changed — causing KKP state to persist in the pty after Claude exits.When multiple VSCode integrated terminals are open, this lingering KKP state leaks to other terminals, causing modifier keys like CapsLock to emit raw CSI u sequences (
[57358u) as literal text.This regression does not appear in v2.1.81, which predates the mouse tracking leak fix.
Further binary analysis of the bundled JS (extracted from the Bun SEA executable) is planned to pinpoint the exact code change.
I just tested in v2.1.81, macOS and it's an issue there. First time noticing it, actually, could be something external?
<img width="421" height="104" alt="Image" src="https://github.com/user-attachments/assets/31214498-9712-4a59-a2fd-64e67c3bf8cd" />
v2.1.83 - appeared today on 2 different Macbooks: (15.7.3 and 15.7.4).
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.