CodexをNushellで使う設定と補完、&&エラーの詳しい直し方

CodexをNushellで使うときの結論

CodexとNushellは併用できるが、「Nushellの画面からcodexを起動できる」という意味と、「Codexが生成するすべてのコマンドをNushellがそのまま解釈できる」という意味は同じではない。OpenAIの公式ページは、Codex CLIを端末からコードの調査、編集、コマンド実行まで行う入口として説明している（出典: https://learn.chatgpt.com/docs/codex/cli ）。一方、公式のコマンド参照で補完生成の対象として挙げられているのはBash、Zsh、Fish、PowerShell、Elvishであり、Nushellは含まれていない（出典: https://learn.chatgpt.com/docs/developer-commands?surface=cli ）。したがって現状は、起動は試せるが、シェル固有部分には回避策が必要な組み合わせと理解するのが正確だ。

起動できても完全対応とは限らない

codexという外部コマンドをNushellが見つけられれば、Codexの対話画面は通常どおり開ける。しかし、その後にCodexがcd path && commandのような一般的なシェル向け構文を実行すると、Nushell側で解析に失敗することがある。画面表示、ファイル読取、モデルとの対話が動いていても、コマンド実行だけが止まるケースがあるため、最初の起動だけで対応可否を判断しない方がよい。

なぜ今Nushell対応を確認するのか

OpenAIの更新履歴では、2026年7月21日にCodex CLI 0.145.0が公開されている（出典: https://learn.chatgpt.com/docs/changelog ）。CLIは短い間隔で改善されているため、古い記事に書かれた対応状況をそのまま前提にするのは危険だ。ただし、最新版になったことはNushell固有の問題が解消されたことを意味しない。OpenAI公式リポジトリでは、Nushellをログインシェルにすると&&を含むコマンドが失敗するという報告が2026年2月に登録され、2026年7月23日の確認時点でも未解決だった（出典: https://github.com/openai/codex/issues/10819 ）。更新日と既知の制限を別々に確認する必要がある。

最新版の確認と対応状況の確認は別作業

codex --versionで最新版を使っていると分かっても、Nushellの構文差まで吸収されるとは限らない。最新版かどうかは不具合を切り分ける前提であり、特定シェルへの対応を保証するものではない。更新後も同じエラーが出る場合は、再インストールを繰り返すより、どのシェルが実際にコマンドを解釈しているかを確認した方が原因に近づきやすい。

CodexとNushellの役割を分けて考える

Nushellは、表やレコードなどの構造化データを扱いやすいシェルで、一般的なBash系シェルとは構文やパイプの考え方が異なる。Codex CLIは端末上で動く対話画面だが、作業中にはファイル検索、テスト、開発用コマンドなどをシェルへ渡す。ここでCodexが想定した構文と、実際の親シェルが解釈できる構文に差があると、依頼内容ではなくコマンドの解析段階で止まる。Nushellの公式ガイドも、Bashのcommand1 && command2に対応する書き方をNushellではcommand1; command2として紹介しており、構文差が明示されている（出典: https://www.nushell.sh/book/coming_from_bash.html ）。

問題はCodexの回答内容より手前で起きる

nu::parser::shell_andandは、コード修正の内容が間違っているという意味ではない。Nushellが受け取ったコマンド文字列を解析できず、実行に入る前に止めたことを示す。Codexへ同じ依頼を何度も言い換えるだけでは改善しない場合があるため、まず親シェルを対応済みのものへ替え、同じ依頼が通るかを比較するのが有効だ。

CodexをNushell環境で安定させる手順

最も安全な考え方は、Nushellを普段のシェルとして使い続けながら、Codexのセッションだけを対応シェルの子プロセスとして開くことだ。Nushellをアンインストールしたり、OS全体のログインシェルを変更したりする必要はない。まずCodexの配置と版を確認し、次にZsh、Bash、PowerShellのいずれかを経由して起動する。安定したことを確認してから、必要な場合だけNushellのconfig.nuへ短い起動コマンドを追加する。

Step 1: Codexの配置と版を確認する

Nushellで次の2行を実行し、codexの実体と版を確認する。which codexで何も返らない場合は、シェル互換性を調べる前にPATHを直す必要がある。版が表示されるなら、少なくともNushellからCodexの実行ファイルへ到達できている。

which codex
codex --version

OpenAIの公式ページでは、プロジェクトのディレクトリを開いてcodexを実行する流れが案内されている（出典: https://learn.chatgpt.com/docs/codex/cli ）。版が古い場合は、同ページの更新方法に沿って更新し、もう一度codex --versionを確認する。ここでは、PATHの問題とNushell構文の問題を混ぜないことが重要だ。

Step 2: 対応シェルを経由して起動する

macOSまたはLinuxでは、NushellからZshかBashを開き、その中でCodexを起動する。まずは設定を保存せず、2段階で試す方が結果を判断しやすい。Zshを使う場合は次の順序で入力し、表示がZshへ切り替わってからcodexを実行する。

zsh -l

codex

Bashを使う環境なら、最初の行をbash -lに置き換える。WindowsではNushellからPowerShellを開き、その中でcodexを実行する。

pwsh -NoLogo

codex

この方法で同じ依頼が通るなら、Codex本体や対象プロジェクトより、Nushellとの構文差が原因である可能性が高い。逆に、対応シェルでも止まるなら、版、権限、対象コマンド、プロジェクト固有の設定を別に調べる。

Step 3: Nushell側に起動コマンドを保存する

毎回シェルを開き直すのが手間なら、動作確認後にconfig.nuへ専用コマンドを追加できる。Nushellの公式設定ガイドは、config nuで設定ファイルを開き、起動時に読み込む独自コマンドを定義する方法を案内している（出典: https://www.nushell.sh/book/configuration.html ）。macOSでZshを使う例は次のとおりだ。

def codex-safe [] {
  with-env { SHELL: "/bin/zsh" } {
    ^zsh -lic codex
  }
}

保存してNushellを開き直したら、codex-safeで起動する。この定義はNushellそのものを変更するのではなく、Codexを開くときだけZshを経由させるためのものだ。Zshの場所が/bin/zshではない環境では、which zshの結果に合わせてパスを直す。WindowsではまずPowerShellへ切り替える2段階の方法を使い、問題が解消したことを確認してから短縮方法を検討すると安全だ。

&&エラーと補完の注意点

Nushellとの併用で誤解しやすいのは、&&の解析エラーとコマンド補完の不足が別問題であることだ。前者はCodexが実行しようとした文字列をNushellが解釈できない問題で、後者はcodexのサブコマンドや引数候補をTabキーで出すための生成機能にNushellが含まれていない問題である。対話画面の中で使うスラッシュコマンドの候補表示とも別なので、補完がなくてもCodex自体を起動して使うことはできる。症状ごとに回避策を分けると混乱しにくい。

nu::parser::shell_andandが出る理由

OpenAI公式リポジトリの報告では、NushellがログインシェルのときにCodexがcd "..." && bun devを実行し、&&非対応として停止した例が示されている（出典: https://github.com/openai/codex/issues/10819 ）。この表示が出たら、対象コマンドをNushell向けに手で直すか、前述の対応シェルを経由する。単発ならCodexへ「Nushell構文を使い、&&を使わない」と伝える方法もあるが、すべての内部コマンドへ反映される保証はない。継続利用ではシェルを分ける方が再発を抑えやすい。

Nushell向け補完を生成できない理由

公式のコマンド参照によると、codex completionが受け付ける値はBash、Zsh、Fish、PowerShell、Elvishである（出典: https://learn.chatgpt.com/docs/developer-commands?surface=cli ）。Nushellを指定する正式な値は記載されていない。また、Nushell補完の追加要望はOpenAI公式リポジトリで「対応予定なし」として閉じられている（出典: https://github.com/openai/codex/issues/6030 ）。そのため、codex completion nuを前提にした設定例は避けるべきだ。補完が必要なら対応シェル側で生成し、Nushellではcodexまたはcodex-safeを直接起動する運用が分かりやすい。

うまく動かないときの切り分け

不具合を早く切り分けるには、最初に「実行ファイルが見つからない」「Nushell構文で止まる」「Codexが起動した後の作業で止まる」の三つを区別する。which codexで見つからないならPATH、nu::parser::shell_andandならシェル構文、対応シェルでも同じ開発コマンドが失敗するなら対象プロジェクト側を疑う。最新版のCodexにはローカル環境を診断するcodex doctorもあり、公式参照ではインストール、設定、認証、実行環境、Git、端末などの状態を確認する安定版コマンドとして説明されている（出典: https://learn.chatgpt.com/docs/developer-commands?surface=cli ）。

Step 1: PATHと版を再確認する

which codexとcodex --versionをNushell、続いてZshまたはPowerShellで実行する。片方だけ見つからない場合は、それぞれが読み込むPATHに差がある。Nushell公式ガイドではPATHをリストとして扱い、$env.pathへディレクトリを追加する方法が示されている（出典: https://www.nushell.sh/book/configuration.html ）。実行ファイルの場所を確認せずに再導入すると、古い版と新しい版が併存することがあるので注意したい。

Step 2: 診断結果を短く確認する

対応シェルから次のコマンドを実行し、端末や設定に明確な異常がないかを確認する。結果に多くの情報が含まれるため、共有する場合は個人のパスや環境情報が含まれていないかを先に読む。

codex doctor --summary

診断が正常でもNushellだけで&&エラーが再現するなら、Nushell固有問題として扱いやすい。対応シェルでも失敗する場合は、Codexへ渡した依頼、実行されたコマンド、終了コードを見比べる。原因を一度に決めつけず、同じプロジェクトと同じ依頼で親シェルだけを変えると差が明確になる。

Step 3: CodexアプリとCLIを分けて試す

公式リポジトリの未解決報告は、NushellをログインシェルにしたCodexアプリで発生した例である。CLIを対応シェルから開くと動くのにアプリだけ止まる場合は、アプリが参照するログインシェルの影響が考えられる。反対にCLIでも同じ構文エラーになるなら、端末で実際に使われている親シェルを確認する。アプリとCLIを同じ条件だと思わず、入口ごとに一度ずつ試すと、設定を変更すべき場所が絞り込める。

Nushellを残すか対応シェルへ切り替えるか

Nushellの構造化データ処理を日常的に使っているなら、OS全体のログインシェルを変更する必要はない。普段はNushellを使い、Codexを開くときだけcodex-safeやZsh、PowerShellを使う分離が現実的だ。一方、Codexへ頻繁にコマンド実行を任せ、毎回シェル差を意識したくない場合は、Codexを使う端末だけ対応シェルに固定した方が確認の負担が少ない。判断基準は好みではなく、Codexが実行するコマンドの量と、Nushell固有機能を同じ端末で使う必要性である。

Nushellの利点を残したまま分離できる

データの絞り込みや表形式の操作はNushellで行い、コード編集やテストを伴うCodexのセッションはZshやPowerShellへ渡すという分担ができる。シェルを完全に置き換えないため、既存のNushell設定を保ちやすい。問題が解消された将来の版を試すときも、専用コマンドだけを外して比較でき、元の環境へ戻しやすい。

まとめ

CodexはNushellから起動できるが、2026年7月23日時点でNushellを全面的な対応シェルとして扱うのは早い。公式の補完生成対象にNushellは含まれず、ログインシェルがNushellの場合に&&で止まる問題も未解決だ。まずwhich codexとcodex --versionで導入状態を確認し、macOS・LinuxではZshかBash、WindowsではPowerShellを経由して同じ依頼を試す。そこで動けば、Codex本体ではなくシェル構文差を原因として切り分けやすい。普段のNushellは残し、Codex用の入口だけを分ける構成なら、Nushellの利点とCodexの安定性を両立できる。今後の更新で対応状況が変わる可能性があるため、更新履歴、公式コマンド参照、関連報告の状態を定期的に見直すことも忘れないようにしたい。