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段階です。
- iTerm2で既定の設定のまま
claudeを起動する - Claudeの応答中にメッセージを送り、キューに積む
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を押したときの挙動 | 報告元 |
|---|---|---|
| iTerm2 | Ctrl+Enterを押したときの挙動右クリックメニューが開く | 報告元起票者 |
| Ghostty | Ctrl+Enterを押したときの挙動フルスクリーンが切り替わる | 報告元コメント |
| Windows Terminal | Ctrl+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での注意 |
|---|---|---|
| キューに積む | 既定のキーEnter | iTerm2での注意影響なし |
| キューを今すぐ送る | 既定のキーCtrl+Enter / Ctrl+X Ctrl+S | iTerm2での注意Ctrl+Enterはメニューに取られる場合がある |
| ターンを止めて送る | 既定のキーEsc | iTerm2での注意影響なし |
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」で解決できるかは未検証なので、試すなら届くバイト列を確認しながら進めてください。