Claude Media
Claude CodeのiTerm2でCtrl+Enterがメニューを開くときの回避策

Claude CodeのiTerm2でCtrl+Enterがメニューを開くときの回避策

iTerm2でキュー済みメッセージを送るCtrl+Enterを押すと、右クリックメニューが開いて何も送られません。症状の切り分けと、Ctrl+X Ctrl+Sやkeybindings.jsonでの回避策をまとめます。

iTerm2でClaude Codeを使っていて、キューに積んだメッセージをCtrl+Enterで送ろうとしたら、iTerm2の右クリックメニューが開いて何も送られない。この症状はGitHub issue #97163で報告されています。キューに積んだ内容は送られないまま残ります。回避策としてまず使えるのは、どのターミナルでも同じ動作をするCtrl+X Ctrl+Sです。

Ctrl+Enter自体の仕様はClaude CodeのCtrl+Enterでキューを待たずに送信するで扱っています。ここでは、iTerm2でキーが届かないときの切り分けと逃げ道に絞ります。

iTerm2でCtrl+Enterがメニューを開く症状

issueの報告内容は次のとおりです。Claudeが応答している最中にメッセージを送るとキューに入り、画面にctrl+enter to send nowというヒントが出ます。そこでCtrl+Enterを押すと、送信されずにiTerm2の右クリックメニューが開き、メッセージはキューに残ったままになります。

報告者の再現手順は3段階です。

  1. iTerm2で既定の設定のままclaudeを起動する
  2. Claudeの応答中にメッセージを送り、キューに積む
  3. Ctrl+Enterを押す

期待される結果はキュー済みメッセージの送信で、実際にはメニューが開くだけでした。報告者の環境はClaude Code 2.1.282、iTerm2 3.4.4、TERM=xterm-256color、tmuxなし、macOS 26.6.2で、カスタムキーバインドは設定していません。

つまりClaude Code側のバグというより、キーがClaude Codeに届く前にターミナル側で消費されている症状です。ラベルはbug、platform:macos、area:tuiが付いています。

何が起きているのか

issueの報告者は、既定のiTerm2がCtrl+Enterを独立したキーとして渡していない可能性を挙げています。そうだとすれば、ヒントの出し方か/terminal-setupで設定する手段が必要だ、という提案です。これは報告者の推測で、原因の確定ではありません。

公式ドキュメントには、関連する記述が2か所あります。

  • 拡張キーを報告しないターミナルでは、Ctrl+Enterは素のEnterとして届く
  • Ctrl+X Ctrl+Sはどのターミナルでも動く

今回のiTerm2は、素のEnterとして届くのではなく、メニュー表示という別の動作にキーが取られている点が違います。Ctrl+EnterがClaude Codeまで届かないという結果は同じです。

なお/terminal-setupがiTerm2で行うのは、ドキュメント上は/copyでクリップボードに書き込むための設定の有効化です。Ctrl+Enterのための設定は含まれていません。iTerm2はShift+Enterによる改行が設定なしで動く端末の一覧に入っていますが、それは改行キーの話です。Ctrl+Enterの扱いとは別に考える必要があります。

回避策1: Ctrl+X Ctrl+Sで送る

最も手間がかからないのは、chat:sendNowの2つ目の既定バインドを使うことです。Ctrl+EnterとCtrl+X Ctrl+Sは同じアクションに割り当てられています。

> 大きめのリファクタを進めて
# Claudeが作業を開始
> ついでにテストも直しておいて
# Enterでキューに積まれる
#
# Ctrl+Enterの代わりに Ctrl+X を押してから Ctrl+S を押す
# → キュー済みのメッセージと下書きがその場で送信される

Ctrl+Xを押してからCtrl+Sを続ける連続入力です。公式ドキュメントも、Ctrl+Enterが素のEnterとして届く端末では「どのターミナルでも動くのはCtrl+X Ctrl+S」と案内しています。v2.1.275より前のバージョンにはchat:sendNow自体がないので、先にバージョンを確認してください。

送信後の挙動は、どちらのキーでも変わりません。公式ドキュメントによると、動作中の内容で次のように分かれます。

  • シェルコマンドやサブエージェントなど、バックグラウンドに移せる処理が走っているとき: その処理はバックグラウンドへ移って動き続け、同じターンの中でClaudeがメッセージを読む
  • 応答を書いている最中、またはバックグラウンドに移せない処理の最中: ターンを中断して、キューのメッセージを次に送る
  • キューの先頭側に!のシェルコマンドが積まれているとき: ターンを中断する

v2.1.281より前は、どの場合でもターンを中断していました。シェルモードでは、このキーはコマンドをキューに積むだけです。

回避策2: keybindings.jsonで別のキーを割り当てる

覚えやすい単独のキーを使いたい場合は、~/.claude/keybindings.jsonでchat:sendNowに別の割り当てを足せます。/keybindingsを実行すると設定ファイルが作成され、開けます。変更は再起動なしで反映されます。

{
  "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "meta+s": "chat:sendNow"
      }
    }
  ]
}

例としてmeta+s(Option+S)を割り当てています。これは書き方を示す例で、ほかの割り当てと衝突しないかは自分の環境で確認してください。iTerm2でOptionをMetaとして送る設定は、Claude CodeでiTerm2のOption keyとクリップボードを有効化するにまとめています。

設定ミスはデバッグログに警告が出ます。スペルミスの修飾キー(ctl+kなど)は認識できない部分が捨てられ、残ったキーに割り当てが適用されます。動作しないときは、割り当てが想定外のキーに付いていないか疑ってください。Ctrl+C・Ctrl+D・Ctrl+Mなどは予約済みで、再割り当てできません。Ctrl+Enterは予約の対象外です。ショートカット全体の一覧はClaude Codeショートカット一覧にあります。

回避策3: iTerm2側でCtrl+Enterの扱いを変える

iTerm2にもキーの割り当て機能があります。Settings → Profiles → Keysの「Key Mappings」で、押したキーに対するアクションを選べます。公式ドキュメントには、次のようなアクションが載っています。

アクション説明
Ignore説明キー入力は何もしない
Send Hex Code説明指定した16進コード列を送る(0xで始め、スペース区切り)
Send Escape Sequence説明ESCに続けて指定の文字列を送る
Send Text説明指定した文字列を送る

Settings → Keysの「Key Bindings」にも同じ仕組みがあり、こちらは全プロファイルに効きます。ただし、プロファイル側の設定が優先されます。

アクションを割り当てる前に確かめたい設定がもう1つあります。同じProfiles → Keysの「General」タブにある「Report modifiers using CSI u」です。iTerm2のドキュメントは、修飾キーをより多くのキー・組み合わせで報告する拡張的なキー報告方式を有効にする設定だと説明しています。あわせて「推奨しない」とも書かれていて、アプリ側はKittyキーボードプロトコルを使うべきだという立場です。

Claude Codeの公式ドキュメントは、拡張キーを報告しない端末ではCtrl+Enterが素のEnterとして届くと書いています。その点で、修飾キーの報告方式を変えるこの設定は筋の通った候補です。ただしiTerm2のドキュメントにも、Claude Codeのドキュメントにも、この設定でCtrl+Enterが届くようになるという記述はありません。右クリックメニューの表示より先に効くのかも未確認です。「Apps can change how keys are reported」(アプリがキー報告のモードを変えられる設定)が有効な点とあわせて、試すなら下の切り分けで届き方を確かめてください。

ここから先は、公式ドキュメントの記述からの推論で、この記事では動作を確認していません。Ctrl+XとCtrl+Sは制御文字としてそれぞれ0x18と0x13に当たるので、Ctrl+Enterのキーに対して「Send Hex Code」で0x18 0x13を送れば、Ctrl+X Ctrl+Sと同じバイト列をClaude Codeに渡せる可能性があります。ただし、iTerm2がCtrl+Enterのメニュー表示より先にこのマッピングを適用するかは、issueにも公式ドキュメントにも記載がありません。試すときは、まずcatで何が届くかを確かめるのが安全です。

切り分け: Ctrl+Enterが何として届くか

どこでキーが消えているかは、Claude Codeを起動せずに確かめられます。issueのコメントでも、catを使ってキーが届いていないことを確認した例が報告されています。

cat -v
# Ctrl+Enter を押す。何も表示されなければ、キーはアプリ(cat)まで届いていない
# ^M と表示されれば、素のEnterと同じものとして届いている
# 確認できたら Ctrl+D で終了

結果の読み方は次のとおりです。

表示意味
何も出ない意味ターミナル側がキーを消費している(今回の症状)
^M(Enterと同じ)意味拡張キーが報告されず、素のEnterとして届いている

Enterを単独で押したときに出る表示と見比べると判断しやすくなります。何も出ないなら、Claude Code側の設定をいくら変えてもCtrl+Enterは動きません。回避策1か2に進んでください。回避策3のiTerm2側の設定を変えたときも、そのたびにこのcat -vでキーの届き方が変わったかを見ると、効いたかどうかを切り分けられます。

他のターミナルで報告されている挙動

issueのコメントには、iTerm2以外の環境の報告があります。

ターミナルCtrl+Enterを押したときの挙動報告元
iTerm2Ctrl+Enterを押したときの挙動右クリックメニューが開く報告元起票者
GhosttyCtrl+Enterを押したときの挙動フルスクリーンが切り替わる報告元コメント
Windows TerminalCtrl+Enterを押したときの挙動改行が入る(別issue #96796あり)報告元コメント
Terminal.app(macOS)Ctrl+Enterを押したときの挙動GUIのコンテキストメニューが開く報告元コメント
VS Codeのターミナル(macOS)Ctrl+Enterを押したときの挙動何も起きない(catで確認)報告元コメント

コメントの一人は、フルサイズキーボードのテンキー側のEnterとCtrlを組み合わせる回避策も挙げています。Ghostty上ではフルスクリーンが切り替わらず、Claude Codeに届いたとのことです。iTerm2で同じ手が通るかは、issueには書かれていません。テンキーのないノートPCでは使えない手でもあります。

ターミナルごとにCtrl+Enterの扱いが違う以上、特定の端末向けの設定だけで直すより、Ctrl+X Ctrl+Sかkeybindings.jsonの割り当てのほうが環境を選びません。

対応状況と、キーバインドの使い分け

issueはOpenのままで、修正されたバージョンの記載はありません。コメントはユーザー同士の情報共有にとどまっています。

最後に、キューに関わる3つの操作を並べます。

操作既定のキーiTerm2での注意
キューに積む既定のキーEnteriTerm2での注意影響なし
キューを今すぐ送る既定のキーCtrl+Enter / Ctrl+X Ctrl+SiTerm2での注意Ctrl+Enterはメニューに取られる場合がある
ターンを止めて送る既定のキーEsciTerm2での注意影響なし

Escはターンを中断しつつキューの内容を送り、Ctrl+Enterは動作中の処理を残せる場合がある点が違います。使い分けはClaude Codeでメッセージをキューに入れる方法に詳しくあります。

まとめ

iTerm2では、キュー済みメッセージを送るCtrl+Enterがメニュー表示に取られ、Claude Codeに届かないことがあります。issueはopenで、修正は見えていません。当面の逃げ道は、同じchat:sendNowに割り当てられたCtrl+X Ctrl+Sと、keybindings.jsonでの別キーの割り当てです。原因の切り分けはcat -vでできます。iTerm2側のKey Mappingsや「Report modifiers using CSI u」で解決できるかは未検証なので、試すなら届くバイト列を確認しながら進めてください。

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