Claude Codeで改行できない・貼り付けが崩れる時の対処法 — ターミナル別2026年版
Claude Codeで「Enterを押すと送信されてしまう」「ペーストが変になる」問題を公式ドキュメントベースで解決。Shift+Enter対応表、Ctrl+Jとバックスラッシュ、tmux設定、800文字超のペースト挙動まで。
エンジニアのゆとです。
Claude Codeで複数行のプロンプトを書こうとしてEnterを押した瞬間、書きかけの文章がそのまま送信された経験、ある人は多いと思う。自分も最初の週はこれで何度もIssueの下書きを事故送信した。原因はバグではなく仕様で、ターミナルごとに対処法が違う。この記事ではどのターミナルでも効く方法から、ペーストが変になる別の問題まで、公式ドキュメントの記述をベースに整理する。
なぜ改行できないのか
Claude CodeのプロンプトはEnterで送信される設計になっている。複数行を書きたい場合は別の操作で改行を挿入する必要があるが、ここでつまずく理由は単純だ。
多くのターミナルは、EnterキーとShift+Enterキーを押しても、Claude Code側に届く信号（バイト列）が同じになる。ターミナルが「Shiftが押されていた」という情報をそもそも送っていないケースが多いということだ。Claude Code自体はShift+Enterを区別して処理できるようになっているが、ターミナルから区別する情報が来なければ、どうしようもない。
だから「Claude Codeの設定を直せば解決する」話ではなく、「使っているターミナルがShiftの情報を送ってくれるかどうか」の話になる。ここを理解しておくと、以降の対処法がなぜ環境ごとに違うのか腑に落ちる。
どのターミナルでも100%効く2つの方法
環境判別が面倒な人は、まずこの2つだけ覚えておけばいい。公式ドキュメントで「すべてのターミナルで設定不要で動く」と明記されている方法だ。
Ctrl+Jを押す- 行末で
\（バックスラッシュ）を入力してEnterを押す
どちらもターミナルの種類やOSに関係なく動く。急いでいて原因切り分けをしたくない場合は、この2つのどちらかを覚えるだけで当面のストレスは消える。
Shift+Enterはターミナルによって挙動が別物
「毎回Ctrl+Jを打つのは面倒」という人向けに、Shift+Enterで改行したい場合の対応状況を整理する。2026年8月時点の公式ドキュメントに基づく分類だ。
| ターミナル | Shift+Enterの挙動 |
|---|---|
| Ghostty / Kitty / iTerm2 / WezTerm / Warp / Apple Terminal / Windows Terminal | 設定不要でそのまま使える |
| VS Code / Cursor / Devin Desktop / Alacritty / Zed | /terminal-setup を1回実行すれば使える |
| gnome-terminal / JetBrains系IDE（PyCharm、Android Studioなど） | 仕様上サポートされておらず、今後も対応予定なし |
見て分かる通り、単体のターミナルアプリ（iTerm2やWindows Terminalなど）は素の状態で動く一方、エディタに内蔵された統合ターミナル（VS CodeやCursor）は追加設定が必要になる。この違いを知らずに「iTerm2では効いたのにVS Codeでは効かない」と混乱するケースをよく見かける。
gnome-terminalとJetBrains系IDEは「未対応」ではなく「対応予定なし」だ。これらの環境を使っている人は、Shift+Enterを追いかけるより、先に挙げたCtrl+Jかバックスラッシュに乗り換えたほうが早い。
/terminal-setup を実行すると実際に何が起きるか
VS Code・Cursor・Devin Desktop・Alacritty・Zedのユーザーは /terminal-setup を実行することになるが、これは単に「Shift+Enterのキーバインドを1個書き込むだけ」のコマンドではない。副作用まで含めて理解しておくと、後で「なぜか設定が変わった」と戸惑わずに済む。
エディタ設定ファイルへの書き込み
VS Code・Cursor・Devin Desktopでは、/terminal-setup がキーバインドに加えて2つのエディタ設定を書き換える。
terminal.integrated.gpuAccelerationを"off"にする（文字化け・ちらつき対策）terminal.integrated.mouseWheelScrollSensitivityを調整する（フルスクリーンモードでのスクロールを滑らかにする）
このGPU描画オフの設定は、実は日本語入力時の文字化け・表示崩れの対策そのものでもある。同じ現象で困っている場合は、原因の切り分け方を別記事にまとめてあるのであわせて読んでほしい。
初回実行時は Installed VSCode terminal Shift+Enter key binding のような確認メッセージが出る。すでに設定済みの場合は already configured と表示されて何も変更されない。既存のキーバインドを勝手に上書きすることはない。
反映されない場合は、tmuxやscreenの中から実行していないか確認してほしい。ホスト側のターミナル設定ファイルに書き込む処理なので、tmux内から実行しても正しく反映されない。ホストターミナルで直接実行する必要がある。
macOSでOption+Enterも使いたい場合
Claude CodeにはOption+Enterで改行するショートカットや、Option+Pでモデルを切り替えるショートカットもある。ただしmacOSのターミナルはデフォルトでOptionキーを修飾キーとして送らない設定になっていることが多く、これも「設定していないから動かない」パターンの1つだ。
Apple Terminal.appを初回起動時の設定プロンプトで承諾していれば、/terminal-setup によって自動でOption=Metaが有効化されている。iTerm2の場合は少し毛色が違い、/terminal-setup を実行すると「Applications in terminal may access clipboard」も同時に有効になり、/copy コマンドでシステムクリップボードに書き込めるようになる。iTerm2は再起動しないと反映されない点も覚えておくといい。
tmux配下で使っている人はもう1手間必要
tmuxの中でClaude Codeを動かしている場合、外側のターミナルがShift+Enterに対応していても、tmuxがそれを飲み込んでしまう。デスクトップ通知やプログレスバーも同様に外に届かなくなる。
~/.tmux.conf に以下を追加して tmux source-file ~/.tmux.conf を実行すれば直る。
set -g allow-passthrough on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'allow-passthrough が通知やプログレス表示を外側に届ける設定、extended-keys の2行がShift+Enterと素のEnterをtmuxに区別させる設定だ。tmuxを使っていない人はこの節は無視して構わない。
改行の次に詰まる「貼り付け」の話
改行問題が片付いた後、次にぶつかりやすいのがペースト（貼り付け）まわりの違和感だ。「大量のコードを貼り付けたら表示が乱れた」「貼り付けたはずの内容が消えた」という相談も多いが、これは不具合ではなく仕様を知らないだけのケースがほとんどだ。
800文字・2行を超えると自動でプレースホルダー化される
Claude Codeは、800文字を超えるか2行を超える内容を貼り付けると、入力欄の表示を [Pasted text #1 +120 lines] のようなプレースホルダーに自動的に置き換える。これは入力欄が長文で埋め尽くされて操作不能になるのを防ぐための仕様で、実際に送信される内容は省略されず、フルテキストがそのままClaude Codeに渡る。
「貼り付けたのに内容が短縮されて表示されている」と焦って貼り直す必要はない。プレースホルダーの見た目はただの表示上の圧縮で、中身は消えていない。
貼り付けた内容は ~/.claude/paste-cache/ に保存される
このプレースホルダー化された内容は ~/.claude/paste-cache/ にキャッシュされる。コマンド履歴（上矢印キーでの呼び出し）から過去のプロンプトを再送信したときも、このキャッシュがあればフルテキストがちゃんと再送される。これはセッションをまたいでも有効で、cleanupPeriodDays の設定日数が経過するまで保持され続ける。
ただし、キャッシュファイルは起動時に cleanupPeriodDays を超えた古いものから削除される。日数が経ってからコマンド履歴で古いプロンプトを呼び出すと、参照先のキャッシュがすでに消えていることがある。その場合Claude Codeは [Pasted text #N] という文字列をそのまま送ることはせず、次のいずれかの挙動になる。
- 残りのテキストがあるプロンプトなら、プレースホルダー部分だけ取り除いて残りを送信する
- シェルモード（
!）やスラッシュコマンド、あるいは取り除くと本文が空になる場合は送信自体をキャンセルし、プレースホルダー付きの元のテキストを入力欄に戻す
後者のケースに遭遇したら、プレースホルダーを手動で消すか内容を書き直してから再送信すればいい。
VS Code統合ターミナルは大きい貼り付けで文字が欠落することがある
もう1つ、VS Codeの統合ターミナル特有の制限として、非常に大きいテキストを貼り付けると、Claude Codeに届く前に文字が欠落することがある。これはClaude Code側の不具合というより、VS Code統合ターミナルの入力処理の制限に近い。
ファイル全体やログの丸ごと貼り付けのような用途では、貼り付けに頼らず、いったんファイルに保存してClaude Codeにパスで読ませたほうが確実だ。会話のログも読みやすく保たれるし、後のターンでもファイルパスで参照できるので、そもそもこちらのやり方のほうが実務では扱いやすい。
自分の環境で確認した組み合わせ
自分は普段Macで、iTerm2とVS Code統合ターミナルを行き来しながらClaude Codeを使っている。iTerm2ではShift+Enterが最初から効くので特に何もしていないが、VS Code側は導入時に /terminal-setup を一度実行してある。両方の環境を切り替えて使っていると「あれ、さっきのショートカットが効かない」となりがちなので、自分がいまどっちのターミナルにいるかを意識する癖がついた。
大きめのエラーログをVS Code側の統合ターミナルに直接貼り付けようとして一部が欠けた経験もあり、それ以降ログ類は基本的にファイルに落としてから読ませるようにしている。地味だけどこれだけで貼り付け起因のトラブルはほぼなくなった。
それでも直らない時のチェックリスト
一通り設定しても改善しない場合は、以下の順番で確認してほしい。
Ctrl+Jかバックスラッシュ+Enterは効くか → 効かない場合はターミナルとの接続自体を疑う/terminal-setupをホストターミナルで直接実行したか（tmux/screen内からではないか）- tmux配下なら
~/.tmux.confの3行を追加してsource-fileを実行したか - macOSでOption系ショートカットを使いたいなら、ターミナル側で「Option as Meta Key」相当の設定が有効になっているか
- VS Code統合ターミナルで大きい貼り付けが崩れるなら、ファイル経由に切り替える
ここまでやって直らない場合は、ターミナルアプリ自体を対応済みのもの（iTerm2、Windows Terminal、Ghosttyなど）に変える選択肢も検討していい。
FAQ
Shift+Enterがどうしても効かない場合はどうすればいい
Ctrl+Jかバックスラッシュ+Enterを使えば、対応表に関係なくどのターミナルでも改行できる。Shift+Enterはあくまで「使えると便利」なショートカットであって、必須ではない。
/terminal-setup を複数回実行しても問題ないか
問題ない。すでに設定済みの項目は上書きされず、already configured と表示されるだけで終わる。既存のキーバインドを壊す心配はしなくていい。
EnterとShift+Enterの役割を逆にすることはできるか
できる。キーバインド設定ファイルで chat:newline と chat:submit のアクションを入れ替えれば、Enterで改行してShift+Enterで送信する動作に変更できる。Vimに慣れている人などは、この逆転設定のほうがしっくりくることもある。
初めてClaude Codeを触るが、こういうつまずきは他にもあるか
改行やペーストのようなターミナル起因のつまずきは、最初の数日に集中して起きやすい。自分が初めて触った時に詰まったポイントは別記事にまとめてある。
まとめ
改行できない問題の本質は、Claude Code側の不具合ではなく「ターミナルがShiftの情報を送っているかどうか」の違いにある。迷ったらCtrl+Jかバックスラッシュ+Enterで確実に回避しつつ、余裕があれば /terminal-setup でShift+Enterも使えるようにしておく。ペースト周りは800文字・2行というしきい値と paste-cache の仕組みを知っておくだけで、「消えた」と焦る場面はかなり減る。
小さい話に見えて、複数行のプロンプトを日常的に書く人にとっては地味に効いてくる部分なので、一度設定してしまえばあとは意識せずに済む。
