AI CLIのTUIキーバインドを切り分ける

AI CLIでShift+Enterを押しても改行されず、送信されてしまうことがあります。この症状をTUIのバグだと思って設定を探し続けると、端末が送った入力とアプリが解釈した入力を混同します。

今回は、入力が届く経路を端末・シェル・TUIに分け、Codexの/keymap、外部エディター、Vim mode、statuslineを順番に確認します。キー名の動作は製品とバージョンで変わるため、固定したブログ記事より、実行中のTUIが表示するヘルプを優先します。

入力は3層を通る

キーボード
  -> Windows Terminal / iTerm / WezTermなど
  -> WSL / SSH / シェル
  -> CodexやOpenCodeのTUI

各層が「Shift+Enter」という名前をそのまま渡すわけではありません。端末がEnterと同じ復帰文字を送れば、TUI側で別の動作へ割り当てても区別できません。tmuxやSSHを挟むと、さらに入力を加工する箇所が増えます。

まず同じキーを別の端末、tmuxなし、SSHなしで試します。ここで挙動が変わるなら、アプリの設定だけを調べる前に境界を1つずつ戻します。

Enterは送信や確定に使われるため、複数行のcomposerでは別の改行入力が必要になることがあります。Shift+Enterを使う方法は端末が区別できる場合に限られ、Ctrl+Jは改行文字として扱われる経路が比較的単純です。

確認の順番は次です。

Codexのdeveloper commandsでは、/keymapでショートカットを確認・変更し、設定をconfig.tomlのtui.keymapへ保存できると説明されています。ctrl-aやshift-enterのような表記は、TUIが実際に認識したキー名です。

キーバインドの相性を解決するために、長い仕様やログをTUIへ直接貼り続ける必要はありません。CodexのCLI customizationでは、composerでCtrl+Gを押すとVISUAL、なければEDITORのエディターを開けると案内されています。

export VISUAL=vim
export EDITOR=vim

長い依頼を外部エディターで作り、保存してcomposerへ戻す運用にすると、端末ごとの改行・Undo・貼り付けの差を小さくできます。エディターの指定はシェルやOSごとに異なるため、実際に開くかを短い入力で確認します。

Codexの/vimは、そのsessionのcomposerをVim modeへ切り替える。初期状態から有効にする設定を使う場合は、利用中のCLIバージョンがサポートする設定名を公式の設定リファレンスで確認します。確認後に、次のような設定を検討します。

[tui]
vim_mode_default = true

シェルでset -o viを設定しても、TUIのcomposerへ自動で継承されるとは限りません。シェルの入力編集とTUIの入力編集を別の層として扱います。

OpenCodeはKeybindsで操作の割り当てを公開しています。両方を使う場合も、移動・送信・改行・取消だけを同じ考え方へそろえ、設定ファイル全体を無理に共通化しない方が保守しやすいです。

Codexの/statuslineでは、モデル、推論設定、コンテキスト、レート制限、Gitブランチ、トークン数、session ID、作業ディレクトリ、バージョンなどを表示・並べ替えできます。公式資料では設定がconfig.tomlのtui.status_lineへ保存されます。

常時表示する候補は、次の4〜5項目で十分です。

狭い端末で折り返すなら、session IDや詳細なトークン数を外す。必要なときだけ/statusや利用状況の表示で補う。statuslineの目的は情報量を増やすことではなく、誤ったworktreeやモデルで作業しないことにあります。

次の順番なら、入力の消失地点を絞りやすいです。

キー操作はアプリ設定だけでは完結しません。確実に区別できる入力を先に採用し、必要な操作だけ端末とTUIの双方で調整すると、環境差に強くなります。