Claude Media
Claude CodeでAltGr文字が入力できない — Windows Terminalの原因と回避策
Claude CodeTips

Claude CodeでAltGr文字が入力できない — Windows Terminalの原因と回避策

Windows TerminalのClaude Codeで€や{ [ ] }などAltGr文字が消える原因をkittyキーボードプロトコルから説明し、効く回避策と効かない設定を分けます。

読了目安 約8分

このTipsでできること

Windows TerminalでClaude Codeを使うと、AltGrを押しながら打つ文字(€ { [ ] } \ | など)がプロンプトに入らないことがあります。エラーは出ず、キーを押しても何も起きません。

原因は、Claude Codeが有効にするkittyキーボードプロトコルと、Windows TerminalがAltGrを報告する方法の食い違いです。この記事では、症状の見分け方、原因の仕組み、いま使える回避策を扱います。あわせて、試しても効かない設定も先に挙げます。

症状 — どのキーが落ちて、どれが動くか

GitHubのIssue #94873に報告されている症状は、次のとおりです。

  • フランス語AZERTY配列で、€ # { [ | \ ] }(第3レベルの文字)が入力できない
  • ノルウェー語配列でも、{(AltGr+7)、[(AltGr+8)、](AltGr+9)、}(AltGr+0)が入らない
  • 基底キーが非ASCIIの組み合わせ(à é è ç)は、引き続き入力できる
  • 同じキーはPowerShellでもWSLのbashでも正常に打てる
  • 貼り付けは正常に動く

最後の2点が診断の決め手です。ターミナル自体やキーボード配列が壊れているのではなく、Claude Codeの入力処理だけで起きています。

報告環境は、Claude Code 2.1.273(native Windowsバイナリ)、Windows Terminal 1.25.1912.0、Windows 11です。後続のコメントでは、2.1.276と2.1.281でも再現しています。

Issueが挙げる影響レイアウトは、フランス語、ドイツ語、スペイン語、ポーランド語、北欧語です。日本語配列での報告は確認できていません。

原因 — AltGrがCtrl+Altに見える問題とkittyプロトコル

AltGrはWindowsでCtrl+Altとして扱われる

WindowsではAltGrが物理的にはCtrl+Altとして報告されます。従来のターミナル入力では、キーボード配列が生成した文字(€など)がそのままアプリに届くので問題は表に出ませんでした。

kittyプロトコルを有効にすると報告形式が変わる

Windows Terminalは1.25 Preview(v1.25.622.0)でkittyキーボードプロトコルに対応しました。アプリがこのプロトコルを要求すると、AltGrの押下は文字そのものではなく、ESC[101;3uのようなCSI uシーケンスで届きます。この例は基底キーe(コード101)とaltのみの修飾子(;3は3−1で2、つまりalt単独)を表します。

Issueの計測結果は次の表のとおりです。Win32プログラムでCONIN$を仮想端末入力モードにし、要求するモードを変えながら生のバイト列を記録したものです。

要求したモードAltGr+E(€)AltGr+8()判定
なしAltGr+E(€)E2 82 ACAltGr+8()\判定正常
ESC[>4;2m(modifyOtherKeys)AltGr+E(€)E2 82 ACAltGr+8()\判定正常
ESC[>1u(曖昧さ解消フラグのみ)AltGr+E(€)ESC[101;3uAltGr+8()ESC[95;3u判定文字が失われる
ESC[>0u(フラグ0)AltGr+E(€)E2 82 ACAltGr+8()\判定正常

曖昧さ解消フラグを立てただけで壊れる点がポイントです。「代替キーを報告する」オプションの問題ではありません。Windows TerminalはAltGrのCtrl側の修飾子を落とし、しかも生成文字ではなくキーの基底コードだけを渡すので、受け取る側からは元の文字を復元できません。

なお表のAltGr+0(@)は、フラグを立てても文字が届きました。基底キーの都合で、落ちるキーと通るキーが混在します。

Claude Code側でも救済が働かない

Issueの調査では、Claude Code側に3つの原因が重なっています。

  1. Windows Terminalではkittyプロトコル系の拡張キー機能が、ターミナルの判別だけで有効と決まる。環境変数で切る手段がない
  2. WT_SESSIONを消してもプローブが走り、Windows Terminalが応答して結局有効になる
  3. AltGrの救済処理はctrlとmetaの両方が立つ入力しか対象にしないため、alt単独で届くWindows Terminalでは発動しない

3つ目の帰結として、CLAUDE_CODE_ALTGR_AS_TEXT=1を設定しても挙動が変わりません。Issueの報告者が実測で確認しています。この変数は公式の環境変数リファレンスには載っていません。

2.1.124では起きなかった

Issueによれば、2.1.124は同種のシーケンスを出しつつ、WT_SESSIONがある環境では該当経路を通らない除外処理を持っていました。2.1.270、2.1.272、2.1.273には同じコードが入っており、除外が消えたことが退行の実体だと分析されています。この分析はバンドルコードの読解に基づく報告者の推定です。

自分の環境が該当するかを確かめる

次の3点が揃えば、この症状である可能性が高くなります。

確認項目該当するときの状態
ターミナル該当するときの状態Windows Terminal 1.25系(Preview)
Claude Codeの起動形態該当するときの状態native Windowsバイナリ(claude.exe)
入力の切り分け該当するときの状態PowerShellでは打てて、Claude Codeのプロンプトだけ打てない

バージョンは次のコマンドで確認できます。

claude --version
$env:WT_SESSION

WT_SESSIONに値が入っていればWindows Terminalの中です。値は判別に使うだけで、消しても直りません(前節の2点目)。

Issueのコメントによると、安定版の1.24.11911.0のリリースノートにはkittyプロトコルの記載がなく、影響を受けるのは1.25 Previewの利用者に限られています。1.25が安定版に入れば、AltGrを使う全レイアウトの利用者が同じ影響を受けます。

回避策 — 効くものと効かないもの

効かないと報告されているもの

  • CLAUDE_CODE_ALTGR_AS_TEXT=1の設定(前述のとおり判定に届かない)
  • WT_SESSIONを空にして起動する(コメントによると、AltGrのモードが「off」に解決されるだけで直らない)

報告で有効だったもの

  1. 従来のコンソールホストで動かす: Win+Rからconhost.exe pwshを起動し、その中でclaudeを実行するとAltGrが戻ったと報告されています。一部の字形の描画が粗くなる、という副作用も同じ報告にあります
  2. WSLシェルから起動する: 同じclaude.exeをWSLのシェルから起動すると影響を受けません。バイト列がLinuxのptyから来るためで、kittyプロトコルは要求されません
  3. 貼り付けで入れる: 貼り付けは正常に動くので、必要な記号だけ別のエディタからコピーして貼れます。応急処置です

試す価値があるがIssueでは未検証のもの

Windows Terminal側には、kittyプロトコルを切る設定があります。プロファイル設定のcompatibility.kittyKeyboardMode(既定値true、設定UIでは「Allow Kitty Keyboard Protocol」)で、1.25 Previewの1.25.923.0では「この設定でプロトコルを無効にしても効かない」不具合が直っています。

{
  "profiles": {
    "defaults": {
      "compatibility.kittyKeyboardMode": false
    }
  }
}

Windows Terminal本体の修正PRでは、この設定を無効にしたフランス語Bepo配列でAltGr+Yが{になることが検証されています。ただし、Claude Codeと組み合わせて直るかどうかは、Issue #94873には報告がありません。試す場合は次の2点を先に押さえてください。

  • 設定を切ると、kittyプロトコルに依存する入力(修飾キーの状態の判別など)が全プロファイルの対象で弱まる可能性がある。defaultsではなく、Claude Code専用のプロファイルだけに設定する形が安全
  • Shift+Enterによる改行は、公式ドキュメント上はWindows Terminalで設定不要で動く。プロトコルを切った状態でも動くかは確認できていない。切ったら、公式の説明どおり\のあとにEnterを押す方法とCtrl+Jで改行できるかも確かめておく

Windows Terminalの設定はJSONのsettings.jsonを直接開いて編集できます。プロファイルごとに切る場合はdefaultsをlist内の対象プロファイルに置き換えます。

使い分けの早見表

状況向く回避策失うもの
記号が数個だけ必要向く回避策貼り付け失うもの手間だけ
Windows Terminalを続けたい向く回避策kittyプロトコルの無効化(要検証)失うもの不明(検証が必要)
描画の粗さを許容できる向く回避策conhost.exeで起動失うもの一部字形の見た目
WSLを使っている向く回避策WSLシェルから起動失うものなし(環境が必要)

Issueが挙げる恒久的な修正案

Issue #94873は、修正方針を4つ挙げています。

  1. Windows Terminalを除外し、2.1.124の挙動に戻す
  2. AltGrの判定を緩めて、alt単独でもWindowsなら対象にする。あわせてCLAUDE_CODE_ALTGR_AS_TEXTを修飾キー判定より前に読む
  3. kittyのフラグ16(関連テキストの報告)を要求し、CSI uの3番目のパラメーターから文字を復元する
  4. せめて拡張キー機能を切る環境変数を用意する

現状では、Claude Code側の環境変数で回避する道はありません。2.1.281を使うコメント投稿者が「同じ問題」と報告しており、その時点で修正版の言及はありませんでした。バージョンを上げても直る保証はないため、上の回避策で切り分けるのが確実です。

似た症状との切り分け

同じWindows Terminalでも、症状が違えば原因も別です。

  • リンクをCtrl+クリックすると2回開く場合は、入力ではなくマウス処理の問題です。Claude Codeのリンクが2回開く問題の記事にまとめています
  • WezTermでShift+記号が反転する場合は、WezTermの記号入力の記事の領分で、原因は別です
  • Shift+Enterが改行にならない場合は、terminal-setupの記事を確認してください
  • JetBrains IDEの統合ターミナルで同じ症状が出るなら、IssueのコメントによるとJetBrainsの新しいターミナル(IJPL-254887)が原因で、従来のターミナルに戻すと直ります。今回の不具合とは無関係です

Claude Codeのキー操作全般は、ショートカット一覧から確認できます。

まとめ

Windows TerminalでAltGr文字が入らないのは、kittyキーボードプロトコルが有効になった状態で、AltGrがalt単独の修飾子と基底キーで届き、Claude Codeが元の文字を復元できないためです。2.1.124では起きず、2.1.273以降で報告されています。AltGrを使う配列のPreview利用者が対象で、1.25が安定版になれば範囲は広がります。

CLAUDE_CODE_ALTGR_AS_TEXTは効かないので、当面の手段はconhost.exeでの起動、WSLシェルからの起動、貼り付けの3つです。Windows Terminalのcompatibility.kittyKeyboardModeを切る方法は、理屈の上では筋がよい一方、Claude Codeとの組み合わせは未検証です。試すときは専用プロファイルで、Shift+Enterの動作も合わせて確かめてください。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →