Claude CodeでWezTermの記号が入力できないときの対処法

WezTermでenable_kitty_keyboard = trueを有効にしていると、Shift+/を押しても?ではなく/が入力されることがあります。人によってはShift付きの英字が小文字のまま入力される、Shift+1やShift+Enterごと反応しなくなるなど、崩れ方の範囲が違います。v2.1.247で入った回帰で、v2.1.269のchangelogに修正項目があります。それでも一部の環境では症状が残っています。

WezTermで記号入力がおかしくなるとはどんな症状か

最初の報告は、Shift+/だけが?にならない症状でした。WSL2上のUbuntuでWezTermを使う環境で、v2.1.246では問題なく、v2.1.247に上げた直後から発生しています。Shift付きの英字は正しく入力されるため、記号だけがおかしいことに気づきにくいのが厄介な点です。

同じissueには、環境ごとに崩れ方の違う報告が積み上がっています。同じエスケープシーケンスを受け取っても、結果は次のように分かれます。

AZERTYの報告者は、v2.1.270でも) = , * ù <が崩れ、. / §は正常だったと書いています。同じShift付き記号でも、レイアウトによって壊れるキーが入れ替わります。

原因はkitty keyboardプロトコルの取りこぼし

WezTermはenable_kitty_keyboardを有効にすると、Claude Codeが要求するkitty keyboardプロトコルのflagに応答します。v2.1.246まではflag 1を、v2.1.247からはflag 4(代替キーの報告)を含むflag 5を要求しています。

flag 4が有効だと、WezTermはShift+/を?の1バイトではなく、ESC [ 47:63;130uという12バイトのシーケンスで返します。47は素の/、63はShift込みの?、130はShiftとNumLockのモディファイア値です。

最初の報告者のデコーダ解析では、Claude Codeは63の欄を読まず、47だけからキー名を作っています。そこでShiftが付いていればtoUpperCase()で大文字化を試みます。英字なら'a'が'A'に変わるので救われますが、'/'.toUpperCase()は'/'のままです。

この報告者は、63の欄を読めば直るほか、flag 16を要求してターミナルに関連テキストを報告させる方法でも直ると提案しています。

1バイトの生の?をそのまま通す従来の経路も、12バイトのシーケンスは通りません。この仕組みで説明がつくのは記号の欠落です。AZERTYの報告者は、この経路では大文字化の判定が英字でも働いていないようだと書いています。

自分の環境が影響を受けているか確認する

症状の切り分けには、WezTermが実際に送っているバイト列を見るのが確実です。ターミナルで次のコマンドを実行し、Shift+/を押してからEnter、Ctrl+Dの順に入力します。

printf '\033[>5u'; od -c; printf '\033[<u\n'

Claude Codeが実際に要求するflagは>5uです。>1uなど別のflagで試すと問題が再現せず、ターミナル側は正常に見えてしまいます。

次はWindowsネイティブ環境の報告者が、flagごとにShift+/、Shift+1、Shift+;のバイト列を記録した結果です。

[A] flagを送らない(レガシー)
    SHIFT + / :  3f            ?
    SHIFT + 1 :  21            !
    SHIFT + ; :  3a            :
 
[B] flag >1u(v2.1.246が要求していた形)
    SHIFT + / :  3f            ?
    SHIFT + 1 :  21            !
    SHIFT + ; :  3a            :
 
[C] flag >5u(v2.1.247以降が要求する形)
    SHIFT + / :  ESC[47:63;130u
    SHIFT + 1 :  ESC[49:33;130u
    SHIFT + ; :  ESC[59:58;130u

[C]の形式が返ってきたら、flag 5が有効です。?の1バイトだけが返るなら、この不具合の対象外です。この記録ではWezTermは3つのキーすべてに「素のキー:Shift込みの文字」を載せていました。それでもClaude Code側で!と:は正しく入力され、?だけが崩れています。バイト列が同じでも結果が割れる点が、原因の特定を難しくしています。

症状別の対処法早見表

崩れ方によって、有効な対処が変わります。

最も確実な対処 — enable_kitty_keyboardを無効化する

最短の対処は、~/.wezterm.luaのenable_kitty_keyboard = trueをコメントアウトまたは削除することです。WezTermはデフォルトでこの設定をオフにしています。無効化すると、Claude Codeが要求するflagをWezTermが受け付けなくなり、記号もShift付き英字も従来どおりの1バイトの応答に戻ります。

反映は設定のホットリロードで済み、WezTermの再起動もClaude Codeセッションの再起動も要りません。ただし、Shift+Enterの改行のためだけにプロトコルを有効にしていた場合、この設定を切ると改行手段も一緒に失われます。

プロトコルを維持したまま個別キーだけ直す

kitty keyboardプロトコルを他の用途で使い続けたい場合は、影響を受けるキーだけをLuaのSendStringアクションでバイパスする方法があります。WezTerm側でキーを横取りし、プロトコルを経由せず生のバイト列をptyへ直接書き込む仕組みです。

local SHIFTED_PUNCTUATION = {
  '~', '!', '@', '#', '$', '%', '^', '&', '*', '(', ')',
  '_', '+', '{', '}', '|', ':', '"', '<', '>', '?',
}
 
for _, ch in ipairs(SHIFTED_PUNCTUATION) do
  table.insert(config.keys, { key = ch, mods = 'SHIFT', action = wezterm.action.SendString(ch) })
end

記号側はmods = 'SHIFT'のバインドだけが実際に発火します。WezTermはnormalize_shiftという内部処理で、ASCII英字だけをShift解除後の大文字表記に正規化し、記号はSHIFT修飾子を保持したまま扱います。そのためmods = 'NONE'側の記号バインドは一度もマッチしません。issueで最初に共有されたバインドは両方を書いていましたが、NONE側は削れます。

Shift+英字の大文字化まで失われている環境では、英字用に別のバインドが必要です。

{ key = 'A', mods = 'SHIFT', action = wezterm.action.SendString 'A' },

英字は記号と逆で、Shift付きの小文字キーが大文字キー側に正規化されるため、バインドはSHIFT修飾子付きの大文字キーに対して書きます。AZERTYでAltGr経由の入力までは救えません。AltGrは別のモディファイアとして届き、どちらのバインドにも一致しないからです。

Shift+Enterだけが目的ならCtrl+Jで代用する

kitty keyboardプロトコルを有効にしている理由がShift+Enterでの改行だけなら、プロトコルなしで解決できます。

Ctrl+Jまたは\に続けてEnterを押す方法は、どのターミナルでも設定なしに改行を挿入します。ただしAZERTYでは\の入力にAltGrが要るため、Ctrl+Jのほうが手軽です。実際、AZERTYの報告者がプロトコルを切れなかった理由は、\+Enterの代替がAltGrの組み合わせになるからでした。

もう1つは、WezTerm側でShift+Enterに生の改行文字を送るキーバインドを登録する方法です。Ctrl+Jと同じ改行文字を直接送るので、kitty keyboardプロトコルを経由せずに済みます。

{ key = 'Enter', mods = 'SHIFT', action = wezterm.action.SendString '\n' },

なおWezTermは/terminal-setupの対応対象には含まれていません。公式ドキュメントの対応表でWezTermは設定不要で動くターミナルに分類されているためです。/terminal-setupがキーバインドを書き込むのはVS Code・Cursor・Devin Desktop・Alacritty 0.16より前・Zedで、Alacritty 0.16以降はv2.1.269以降なら設定不要と案内されています。コマンド自体の使い方はterminal-setupコマンドでShift+Enterが効かないときの対処にあります。

v2.1.269で公式修正、それでも報告が続くケース

v2.1.269のchangelog(2026年9月11日)には、F1/F2/F4がkittyプロトコルのターミナルで動かない問題などと並んで、「Shift+punctuationがWezTermでShiftなしのキーになる(v2.1.247での回帰)」の修正が載っています。この修正は、最初の報告にあたる記号の欠落には効いたようです。

v2.1.269の修正が効いたのは、一部の経路だけでした。

v2.1.269以降も症状が残る場合の手立ては3つです。

• WezTerm側を更新する: あるコメントは、WezTermのkittyプロトコル実装側の問題で、nightlyでは解消すると書いています。最初の報告者はnightly 20260826を使っており、WezTerm側の動きも排除できないと注記しています。stable 20240203-110809-5046fc22を使う報告者も複数いるので、stable版の利用者は更新で挙動が変わる可能性があります
• バージョンを固定する: AZERTYの報告者は、v2.1.220に戻してDISABLE_AUTOUPDATER=1で自動更新を止めています。公式のsetupページにはcurl -fsSL https://claude.ai/install.sh | bash -s 2.1.89のように、ネイティブインストーラにバージョン番号を渡す書き方があります
• サードパーティのバイナリパッチを使う: issueに有志のツールが紹介されています。バイナリを書き換えるため、Anthropic公式の手段ではありません

QWERTZのように広い範囲で効かなくなった環境では、enable_kitty_keyboardの無効化が確実な手段として残ります。

まとめ

>5uのバイト列が[C]の形で返り、v2.1.269以降でも崩れが残るなら、まず崩れる範囲を見ます。記号だけならLuaバインドで足りますが、Shift+英字やShift+Enterまで効かないレイアウトでは、バインドを増やすよりenable_kitty_keyboardを切るほうが手数が少なく済みます。

ターミナル全般のキー入力設定はClaude Codeショートカット一覧、iTerm2固有の入力不具合はClaude CodeをiTerm2で使うとGOKが入力される不具合の対処法、IMEまわりの入力トラブルはClaude CodeのIME入力が重い・変換候補が重複する問題と対処法も参考にしてください。