Moonshot / Kimi 2026年5月11日のリリースノート解説: Kimi CLI 1.42.0

Kimi Code CLI の公式 changelog に、2026年5月11日付で Kimi CLI 1.42.0 が掲載されました。今回の中心は、Windows環境でのShell実行をGit Bashへ寄せる変更、Windows上のPOSIX形式パス対応、再実行時の表示整理、subagentへのワークフロー プロンプト注入抑制です。CLIを日常的なコーディング エージェントとして使うチームでは、OS差分と自動実行時の挙動に関わるため、単なる小修正ではなく運用確認が必要な更新です。

要点

• WindowsのShell backendがPowerShellからGit Bashへ切り替わる
• ReadFile、WriteFile、Glob、GrepなどがWindows上のPOSIX形式パスを受け付ける
• 失敗したLLM stepの再実行時に、途中までstreamされた出力を混ぜずに整理する
• wire protocolに再実行イベントが追加され、失敗・再試行の状態を追跡しやすくなる
• subagentにroot ワークフロー向けプロンプトが入り込まないよう整理された

今回の更新で変わること

一番大きいのは、WindowsでShell toolを使うときの前提がPowerShellではなくGit Bashになる点です。これにより、&&、||、pipe、/dev/null、grep、sedなど、LinuxやmacOSに近いコマンド記法をWindowsでも使いやすくなります。コーディング エージェントの出力はUnix系のコマンドに寄りがちなため、Windows利用者にとっては成功率を上げる方向の変更です。一方で、Git for Windowsが必要になり、bash.exeの探索や環境変数による明示指定が関係します。社内端末でGit Bashが標準導入されていない場合は、アップデート後の初回起動やShell tool実行でつまずく可能性があります。

パス処理も実務上は重要です。Windows上で /c/Users/foo や /cygdrive/c/Users/foo のようなPOSIX形式のパスを受け付け、native Windows pathへ変換するようになりました。LLMが生成するパスや、Git Bash環境でコピーしたパスがそのまま読み書き系toolに渡るケースでは、失敗を減らせます。

また、LLM stepがレート制限やserver errorで途中失敗した場合に、前回の未完了streamと再実行後の出力が混ざらないようになりました。エージェントの長い作業では、途中で失敗した表示が残るとユーザーがどの出力を信頼すべきか判断しづらくなります。今回の変更はUI上の見やすさだけでなく、作業ログの信頼性にも関係します。

対象になりそうなユーザー・チーム

• WindowsでKimi CLIを使っている開発者
• CLI エージェントを社内開発端末やVDIで展開しているplatform team
• subagentや長時間実行を使ってコーディング ワークフローを組んでいるチーム
• CLIのログや再実行状態を監査・トラブルシュートに使う運用担当者

まず確認したいこと

Windows利用者は、Git for Windowsが導入済みか、bash.exeがKimi CLIから検出できるかを確認するのが先です。PowerShell固有のコマンドやredirectに依存している手順があれば、Git Bash前提で動くかも見直す必要があります。逆に、これまでWindowsだけで失敗していたUnix風コマンドやPOSIX pathの扱いは改善する可能性があります。

どう読むべきか

Kimi CLI 1.42.0は、派手な新機能というより、コーディング エージェントを複数OSで安定して動かすための土台を整えるリリースです。特にWindows対応は、個人利用の便利さだけでなく、企業内でCLI エージェントを標準化する際の障害を減らします。アップデート後は、Windows端末でShell tool、ファイル読み書き、長いエージェント run、再実行表示を一通り確認しておくと安全です。