Codex改行の入力方法とShift+Enter・Windows対処を確認

Codexの改行で最初に分ける「入力」と「送信」

Codex CLIで改行を扱うときに混乱しやすいのは、文章を編集している途中の入力と、完成した依頼をCodexへ渡す送信が、同じ画面の中で連続して行われるからです。一般的なテキストエディタではEnterを押せば次の行へ移りますが、対話型の入力欄ではEnterが送信に割り当てられていることがあります。Codexの不具合に見えても、実際には「行を増やすキー」と「依頼を確定するキー」を取り違えているだけの場合があります。

まず覚えたいのは、画面上に二行目が現れたかどうかを送信前に見ることです。一行目を入力した後に改行操作を行い、カーソルが次の行へ移ったことを確認してから二行目を入力します。二行目が表示されないままEnterを押すと、その時点の一行が送られるため、貼り付けた文章や長い依頼では意図しない内容で処理が始まることがあります。短いテストで入力欄の反応を確認してから本番の依頼へ進むと、原因を増やさずに済みます。

改行の扱いは、使っているCodexの入口でも少し変わります。Codex CLIのTUI、VS Code内のCodex画面、デスクトップアプリの入力欄は、同じCodexに接続していてもキーボードを受け取る層が異なります。CLIで使えるキーがVS Codeでもそのまま動くとは限らず、反対にエディタ側のショートカットがCLIへ届くとも限りません。記事や設定を読む前に、どの画面で入力しているかを明確にすることが、Codex改行の切り分けの出発点です。

Enter・Ctrl+J・Shift+Enterの役割

改行に関係するキーは、名前が似ていても端末へ届く信号や画面側の割り当てが同じとは限りません。Enterは送信、Ctrl+Jは改行、Shift+Enterは改行に割り当てられている環境もあれば送信として解釈される環境もあります。どれか一つを全員に通用する正解と決めず、画面にどう表示されたかを基準に判断してください。

Enterは一行の依頼を送るキー

Enterを押してすぐ応答が始まるなら、その入力欄ではEnterが送信に使われています。これは異常とは限らず、短い質問をすぐ渡せるようにした通常の設計です。文章を複数行にしたいときはEnterを連打せず、先に改行用の操作を使います。入力が送られた後に「改行できない」と気付いた場合は、同じ依頼を繰り返すのではなく、次の短いテストで現在のキー割り当てを確かめます。

Ctrl+Jは改行を入れる候補

Codex公式リポジトリの利用者向け議論では、CLIの入力欄でCtrl+Jを改行に使う説明が共有されています。Ctrl+Jを押してカーソルが下の行へ移れば、その端末では改行操作として機能しています。反応がない場合は、端末や多重化ソフトがCtrlの入力を先に受け取っていないか、IMEが確定前の文字列を保持していないかを分けて確認します。Ctrl+Jで試すときも、まず「一行目」と入力して表示の変化を見てください。

Shift+Enterは端末側との相性を確認する

Shift+Enterは、一般的なチャット画面で改行に使われることが多い一方、端末ではEnterと同じ信号になる場合があります。Codex公式資料は/keymapでshift-enterのようなキー名を割り当てる方法を示しているため、使いたい場合は現在の設定を確認してから変更します。押した直後に依頼が送られたら、その画面では改行として登録されていないと判断し、Ctrl+Jまたはキー割り当ての見直しへ戻ります。

Codexの改行を確認する手順

ここでは、問題を大きくしないために、入力欄の反応、キーの割り当て、送信前の表示、実際の依頼という順に確認します。最初から長い仕様書を貼り付けると、一行目で送られたのか、貼り付け処理が変わったのか、端末が固まったのかを判定しにくくなります。各段階で画面に起きたことを一つだけ見て、次へ進んでください。

Step 1: 二行の短いテスト文を用意する

入力欄に次の二行を入れる準備をします。これはCodexへ本格的な依頼を送るための文章ではなく、改行が入力欄に残るかを見るための確認文です。

一行目の確認
二行目の確認

まず「一行目の確認」だけを入力し、送信しないまま改行操作を行います。画面に二行目の入力位置が現れることを確認してから、二行目を入力します。入力途中で応答が始まった場合は、Enterが送信になっていることが分かるため、その場でテストを止めてください。

Step 2: Ctrl+JとShift+Enterを一つずつ試す

短い一行を表示した状態で、Ctrl+Jを一度だけ押します。カーソルが次の行へ移るなら、現在の画面ではその操作が改行です。変化がなければ、同じ状態でShift+Enterを一度だけ試します。二つを連続して押すと、どちらが効いたのか判断できなくなるため、毎回一行だけを消してから同じテストを繰り返します。

押した結果は「二行目が表示された」「送信された」「何も起きない」の三つに分けて記録します。送信された場合は再実行せず、キー割り当てと端末の設定を確認します。何も起きない場合は、Codexが入力を受け取っていないのか、カーソル表示だけが変わらないのかを、矢印キーや文字入力で確かめます。

Step 3: 送信前に二行の表示を確認する

二行が入力欄に残ったら、マウスで別の場所をクリックしたり、長い文章を貼り付けたりせず、表示されたままの状態を見ます。一行目の末尾でカーソルが止まっていないか、二行目の先頭に文字があるか、改行した位置に不要な空白がないかを確認します。画面上で二行が保たれていれば、少なくとも今回の入力経路では改行操作が働いています。

ここで確認したいのは、文章の意味ではなく、改行が送信されず入力欄にとどまった事実です。日本語入力では確定前の文字と確定後の文字が表示上で違って見えることがあるため、まず入力を確定してから改行を試します。変換中にキーを押して反応が変わった場合は、CodexではなくIMEの状態を先に整えます。

Step 4: 小さな依頼だけを送って結果を比べる

改行を確認できたら、二行の内容を使って小さな依頼を送ります。たとえば一行目に目的、二行目に確認してほしい範囲を書き、送信後の表示で二行がそのまま残っているかを確認します。ここではコード変更を頼まず、内容が届いたかだけを見ます。入力欄の表示と送信後の履歴が一致すれば、改行と送信の基本的な組み合わせは確認できています。

このテストを毎回同じ文章で行うと、Codexを更新した後や端末を変えた後の差を比べやすくなります。逆に、最初から複雑な依頼を送り、結果が不十分だった理由を改行のせいにすると、文章の指示不足とキー処理の問題が混ざります。確認用の依頼は短く、同じものを使うことが大切です。

Windows Terminalで改行が送信に変わるとき

Windowsでは、Codexの入力欄だけでなくWindows Terminal、PowerShell、IME、貼り付け機能が入力の途中に関わります。Shift+Enterを押したつもりでも、端末がEnterだけをCodexへ渡せば、Codexは送信として扱います。逆に、端末が特別なキー信号を渡しても、Codex側の現在の割り当てがそれを改行として受け取らなければ、同じように送信や無反応へ見えます。

Windowsでまず見る入力経路

最初に、同じCodexを別の入口から開いたのか、同じ端末の中で再起動しただけなのかを区別します。Windows TerminalのPowerShellから起動したCLIと、VS Codeの統合端末から起動したCLIでは、キーボードの経路が異なることがあります。片方でCtrl+Jが効き、片方で効かないなら、Codexの依頼文ではなく端末側の受け渡しを比較する材料になります。

次に、IMEを英数入力へ切り替えた状態で「一行目」と入力し、改行操作を試します。日本語入力の変換中だけ問題が起きるなら、確定前の文字列を処理する層が関係しています。英数入力でも送信されるなら、キー割り当てか端末の経路を見ます。OS全体の設定を一度に変えず、入力経路を一つずつ絞るのが安全です。

貼り付けと手入力を分けて試す

複数行の貼り付けは便利ですが、貼り付けた改行がEnterと同じ送信として処理される報告があります。OpenAIのCodexリポジトリには、Windows Terminalで複数行を貼り付けたとき最初の改行が送信として扱われる事例が記録されています（出典: Windows Terminalの入力に関する公式リポジトリの報告）。この場合は、貼り付け内容をそのまま再送するのではなく、短い一行を手入力し、改行キーを押したときの反応を別に見ます。

手入力で改行できるのに貼り付けで送られるなら、Codexの文章作成方法を変える余地があります。まず要点を一行ずつ手入力し、送信前に二行の表示を確認します。長文を渡す必要があるときは、入力欄へ全量を貼る前に短い一部分で試し、先頭の改行が送信に変わらないことを確認してください。

VS Codeのショートカットと混同しない

VS Codeには独自のキーバインドがあり、統合端末へ届く前にショートカットとして処理されることがあります。Codexの画面がエディタのパネルなのか、VS Code内で開いた端末なのかを確認し、同じ場所で改行テストを行います。エディタ側の設定を変更しても、CLIの入力欄へ届くキー信号が変わるとは限りません。画面の種類ごとに結果を残すと、設定変更の効果を追いやすくなります。

/keymapでCodexの改行キーを見直す

公式の開発者コマンド資料では、/keymapを使ってTUIのショートカットを確認、変更、保存できると説明されています。キーの名前としてshift-enterやpage-downなどが示され、入力欄に関係する編集操作を選んで割り当てます。改行を自分の端末で使いやすいキーにしたい場合は、まず現在の設定を表示し、空いている組み合わせを一つ選びます（出典: Codex公式の開発者コマンド資料）。

編集欄の操作を選ぶ

/keymapを開いたら、全体のキーではなく、文字を入力する編集欄のコンテキストを選びます。そこで改行に相当する操作を探し、使いたいキーを入力します。資料上の表記と、実際の画面に表示される操作名が版によって少し違う場合があるため、名前を推測して設定ファイルへ書き足すのではなく、表示された候補を使ってください。変更後はテスト文で二行が表示されることを確認します。

設定を変えてもすぐに送信されるなら、選んだ操作が編集欄の改行ではなく送信に割り当てられていないかを見ます。また、同じキーを端末やVS Codeが先に使っていないかも確認します。Codexの設定、端末の設定、エディタの設定を同時に変えると、どこで改善したのか分からなくなるので、一回の確認で変える場所は一つに絞ります。

保存場所と版番号を記録する

公式資料では、キー割り当ての変更はconfig.toml内のtui.keymapへ保存されると説明されています。設定が残ったかを確認するときは、Codexを終了して再起動した後に/keymapを開き、同じキーが表示されるかを見ます。ファイルの内容を直接編集する場合でも、設定の意味を理解しないまま行を増やすのではなく、まず画面から変更できる範囲を使うほうが戻しやすくなります。

版を切り替えた後は、割り当てが消えたのか、端末がキーを渡さなくなったのかを分けます。codex --versionで表示された版、Windows TerminalかVS Codeか、IMEの状態、Ctrl+JとShift+Enterの結果を短く記録しておくと、同じ問題を再現できます。記録は長い説明にせず、比較できる事実を残すことが目的です。

0.147.0更新後に確認したいCodexの入力ポイント

2026年8月7日に公開されたCodex CLI 0.147.0のリリースノートには、フォーカスが戻ったとき、外部接続の初期化中、特定の端末ショートカットを扱うときに、入力が失われたり止まったりする問題の修正が記載されています。日本語文字や絵文字、リンクの表示、Windowsの背景処理とファイルパスも修正対象です。改行の相談でこの版に触れる理由は、入力欄の反応を端末の相性だけで決めつけず、更新前後で同じ確認をする材料が増えたからです。

更新を改行の万能薬にしない

0.147.0へ更新して入力の取りこぼしが減っても、Enterが送信として働く設計や、Shift+Enterを端末が別の信号へ変える問題まで一度に消えるとは限りません。リリースノートに書かれた修正と、自分の端末で起きている症状を分けて読みます。更新後に改行が効かない場合は、まず版番号、端末、入力経路を揃え、短い二行のテストで同じ症状が出るかを確認します。

更新前はCtrl+Jが効いていたのに、更新後は入力が止まる、あるいはフォーカスを戻した後だけ一文字目が消えるという場合は、単純なキー割り当てではなく入力の取りこぼしを疑います。反対に、常にEnterで即送信されるだけなら、送信と改行の割り当てを分ける確認が先です。症状の頻度と発生条件を言い分けると、不要な再導入を避けられます。

変更後の再現テストをそろえる

更新の前後で、「一行目を入力」「Ctrl+J」「二行目を入力」「表示を確認」「最後にEnter」という同じ順番を試します。途中で入力が消えたか、カーソルが動かなかったか、送信されたかを一つずつ記録します。WindowsではWindows TerminalとVS Codeを別々に試し、IMEの確定状態もそろえます。これだけで、Codexの版変更と端末の変更を同じ原因として扱わずに済みます。

公式リリースにある修正は、すべての環境で同じ結果を保証する説明ではありません。特に試験版や端末固有の設定を使っている場合は、安定版へ戻すかどうかを先に決めず、まず再現条件と入力結果を残します。サポートへ報告するときも、版番号、OS、端末、再現キー、送信されたかどうかがそろっていると、症状を伝えやすくなります。

Codex改行で避けたい三つの早合点

改行の問題は、短い操作の違いが大きな依頼結果の違いへつながるため、原因を早く決めすぎないことが重要です。Enterを押して送信されたこと、Shift+Enterが無反応だったこと、貼り付けた文章が一行目で止まったことは、似ていても確認する場所が違います。次の三つを分けて考えれば、設定を増やさずに原因を絞れます。

Enterが送信されるのは故障とは限らない

Enterで応答が始まるなら、まず送信キーとしての動作を確認したと考えます。改行用のキーを探す前に、送られた文章が一行で完成していたのか、入力途中だったのかを見ます。一行の質問を送るだけなら正常な動作であり、複数行の依頼を作るときだけ別の操作を使えば足ります。すべての送信を不具合と扱わないことが、最初の切り分けを短くします。

Shift+Enterが使えないときに端末全体を疑いすぎない

Shift+Enterが送信になったからといって、WindowsやCodex全体が壊れたとは限りません。端末がShiftの情報を取り除いている、VS Codeが先に処理している、Codex側で改行に割り当てられていないなど、複数の可能性があります。Ctrl+Jで同じ短いテストを行い、結果が違えば、入力欄が使えるかどうかと、特定のキーが届くかどうかを分けて判断できます。

貼り付け成功だけで依頼内容を判断しない

貼り付け後に文字が見えていても、改行が送信操作として解釈されていないとは限りません。複数行の先頭だけで処理が始まった場合は、残りの文章が届いていない可能性があります。貼り付けた直後にEnterを押さず、行数と末尾の文字を確認します。長い依頼ほど、少量で入力結果を確認してから本体を渡すほうが、意図しない処理を避けられます。

Codexの改行を安定させるための考え方

改行を安定させる近道は、特別なキーを暗記することではなく、入力欄で文章を整える段階と、Codexへ送信する段階を分けることです。短いテストでCtrl+JまたはShift+Enterの結果を確認し、必要なら/keymapで編集欄の割り当てを見直します。WindowsではWindows Terminal、PowerShell、VS Code、IME、貼り付けという入力経路を一度に変えず、症状が出る場所を一つずつ比べます。

2026年8月7日公開の0.147.0は、端末入力の取りこぼしやWindowsの処理を含む修正を備えていますが、Enterが送信になること自体を改める更新ではありません。公式リリースノートと公式CLI資料を確認し、更新前後で同じ二行テストを行うことが、版の変更と環境の変更を分ける方法です。問題が残る場合は、版番号、画面、端末、キー、表示結果、送信結果を短く残しておくと、次の確認を迷いません。

Codex改行の基本は、二行目が表示されるまで送信しないことです。Enterは送信、Ctrl+Jは改行の候補、Shift+Enterはキー割り当てと端末の相性を確認する操作として覚えます。まず小さな文章で試し、入力が保たれていることを見てから本来の依頼を送る。この順番なら、Codex CLIでもWindowsの端末でも、改行と送信を落ち着いて切り分けられます。