Claude CodeがWindowsでexit code 1・出力なしになる原因と切り分け

WindowsのClaude Codeで、Write-Output "hello" や exit 0 のような自明なコマンドまで、すべて「Exit code 1」だけを返して終わることがあります。stdoutもstderrも空で、エラーの手がかりが画面に出ません。GitHubのissue #94196には、この症状が複数の環境から報告されています。報告をたどると、最初に疑う場所は実行ポリシーやウイルス対策ソフトではなく、セッションをプロジェクトフォルダなしで始めていないかでした。

どんな症状か:コマンドの中身に関係なく即座に失敗する

#94196の報告者は、Windows 11でデスクトップアプリのCodeタブを開き、シェルツールでコマンドを実行しています。結果は次のとおりです。

• どのコマンドでも「Exit code 1」だけが返り、stdoutとstderrは空
• 同じコマンドを通常のターミナルで手入力すると成功する
• -NonInteractive -NoProfile を付けた起動も、アプリの外では成功する
• ファイル系のツール(Read/Write/Edit/Glob/Grep)は普通に動き、プロセスの実行だけが失敗する

最後の点が切り分けの起点になります。作業フォルダにはアクセスできているので、権限や存在しないパスの問題とは違います。コマンドの中身が壊れているわけでもありません。子プロセスを起動して結果を読み戻す経路のどこかで、失敗が起きています。

起動できないのではなく、起動したあとに結果が戻らないという点で、別の症状とも区別できます。シェルが1つも見つからない場合は、Claude Code on Windows requires either Git for Windows (for bash) or PowerShell というエラー文が出ます。#94196のように文言なしで「Exit code 1」だけが返る場合、シェルは見つかっており、失敗はその後の起動や結果の読み戻しで起きています。

最初に確認する条件:フォルダを選ばずに始めたセッション

#94196には4件のコメントが付いています。うち2件が、発生条件を絞り込む手がかりでした。

1件目の報告者は、デスクトップアプリ1.52386.6のWindows 11 Proで、2026年9月14日(UTC。日本時間では同日17時台)に症状が出始めたと書いています。直前まで動いていたのはClaude Code 2.1.266で、アプリがセッションを2.1.270に切り替えた直後から失敗しました。その後の追記で、発生条件は次のように絞られています。

• 2.1.270でも、プロジェクトフォルダを選ばずに始めたデスクトップセッションでだけ失敗する
• フォルダを選んで始めた新しいセッションは、同じ2.1.270で問題なく動く
• 端末から claude.exe -p を実行すると、2.1.266でも2.1.270でも動く
• すでに壊れているセッションを、あとから実在のフォルダへ移しても直らない

フォルダなしで始めたセッションは、%APPDATA%\Claude\scratch-workspaces 以下の作業場所で動きます。報告者の説明では、アプリがMSIX(Microsoftストア形式のパッケージ)として入っている場合、このパスは %LOCALAPPDATA%\Packages\Claude_…\LocalCache 側へ仮想化されます。

4件目の報告者は、Windows Server 2022(ビルド10.0.20348)で同じ症状を再現しました。デスクトップアプリは1.52386.6、CLIは2.1.270で、MSIX版です。この報告者は、通常のプロセスから作業場所のパスに Test-Path をかけると False になり、%LOCALAPPDATA%\Packages\… 側の同等のパスなら True になると書いています。アプリが「ある」と思っている場所が、パッケージ外のプロセスからは見えない状態です。

この報告者は、セッションの途中でディレクトリ変更ツールを使い、作業場所を通常のDocumentsフォルダへ移す試みもしています。結果は変わらず、失敗はセッションの開始時点で決まり、現在のcwdで再評価されるものではないと結論づけています。

回避策は「フォルダを選んで新しいセッションを始める」

報告で効果が確認されている回避策は1つです。プロジェクトフォルダを選んだ状態で、新しいセッションを始めます。2件のコメントが、この方法で症状が出ないことを確かめています。壊れたセッションの作業場所を後から変える方法は、2件の報告のどちらでも効いていません。

デスクトップアプリのドキュメントでは、Codeタブのセッションが「チャット履歴と、プロジェクトフォルダを1つずつ持つ」ものと説明されています。フォルダの指定はセッション作成時の選択項目の1つです。普段からフォルダを選んで始めていれば、この症状に当たらなかったと考えられます。

ただし、#94196はopenのままで、修正バージョンも記載されていません。2.1.270より新しいバージョンで直っているかどうかは、issueからは分かりません。バージョンを更新したあとは、フォルダなしの新規セッションで Write-Output "hello" を1回流して確かめるのが確実です。

原因として疑う順番:報告者が除外したものと、除外できないもの

フォルダなしセッションが条件だと分かる前、報告者たちは多くの原因を潰しています。これらを最初から疑い直す必要はありません。

プロセスの生成が見えている点は、ウイルス対策ソフトを疑うときの判断材料になります。4件目の報告者は、Win32_Process でClaude.exeの子プロセスを観測しました。claude.exe の下に conhost.exe --headless があり、その下に powershell.exe が立ち上がっています。プロセスの作成自体が止められているなら、この連鎖は見えません。AppLocker・WDAC・グループポリシーも、この環境では当てはまらないと確認されています。

ここで1つ、食い違いがあります。ドキュメントは、Claude CodeがPowerShellを -ExecutionPolicy Bypass 付きで起動すると説明しています。一方、この報告者が観測した powershell.exe は引数なしでした。デスクトップアプリ経由の起動と、ドキュメントが説明する起動が同じ経路かどうかは、issueのやり取りからは分かりません。

引数なしで起動したPowerShellは、通常の起動バナーを出してからプロンプトを表示します。この報告者は、出力を読む側が -NoLogo 付きのきれいなプロンプトを期待していれば、これだけで解析が崩れるかもしれないと推測しています。ただし推測であり、検証した結果ではありません。

手元で切り分ける手順

次の順に進めると、原因の層を1つずつ消せます。

手順2〜4で使う確認用のコマンドは、アプリの外のPowerShellで実行します。

claude --version
powershell.exe -NonInteractive -NoProfile `
  -Command "Write-Output 'hello'"
Get-Command pwsh, powershell, git, bash `
  -ErrorAction SilentlyContinue | Format-Table Name, Source
where.exe git

claude --version で、アプリ側とCLI側のバージョンが一致しているかを控えます。#94196の報告では、アプリが内部のClaude Codeを切り替えたタイミングで症状が出ており、バージョンは手がかりになります。Get-Command は、どのシェルがPATH上で見えるかの確認用です。何も表示されなければ、PowerShellの既定の場所である C:\Windows\System32\WindowsPowerShell\v1.0\ をPATHに加えます。

シェルの検出で詰まっているときの確認点

フォルダなしセッションに当てはまらない場合は、シェルの検出と起動の側を疑います。

Git for Windowsを入れていると、BashツールはGit Bashを使います。Claude Codeが見つけられないときは、settings.json の env で場所を指定できます。

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

環境変数のドキュメントによると、指定したパスが存在しない、またはファイル名が bash.exe・sh.exe・bash・sh のどれでもない場合、この変数は無視されて自動検出に戻ります。--debug で警告が見られます。v2.1.219より前は、存在しないパスだと起動時に終了していました。

Claude Codeは、起動したフォルダや node_modules、.venv のような仮想環境フォルダの下に置かれた git を、実行ファイルの混入を避けるためスキップします。たとえば C:\dev\env\myproject から起動して、Gitが C:\dev\env\myproject\Git にあると、見つけてもらえません。この場合は CLAUDE_CODE_GIT_BASH_PATH で指定します。

PowerShellツールの側にも、切り分けに使える設定があります。

• CLAUDE_CODE_USE_POWERSHELL_TOOL=0: Git Bashがある環境でPowerShellツールを止め、Bashツール経由に寄せられます
• CLAUDE_CODE_DISABLE_WINDOWS_SHELL_LAUNCHER=1: PowerShellをcmd.exeのランチャーを通さず直接起動します(v2.1.269以降)

どちらも、#94196で症状が改善したという報告は出ていません。「経路を変えて挙動が変わるか」を見る切り分けとして試す位置づけです。Bashを拒否する権限ルールを書くと、Git Bash環境ではPowerShellツールも止まる仕様がある点にも注意が要ります。Bashツールを丸ごと消す規則なら、そのセッションにシェルツールが1つも残りません。

症状が似た別の不具合との見分け方

「Windowsでコマンドの出力が取れない」報告は、原因の違う不具合が複数あります。見た目が近いものを並べます。

終了コードが0か1か、出力が完全に空かどうかが、最初の分かれ目です。なお grep や findstr が一致なしで終了コード1を返すのは、ドキュメント上は失敗として扱われません。コマンド自体が1を返す正当な場合と、ツールが即失敗している場合は、出力の有無とあわせて見分けます。

MSIX版のデスクトップアプリを組織に配布している場合は、導入形態の確認にWindowsへの一括導入の手順が使えます。

まとめ

exit code 1・出力なしの即時失敗は、コマンドの書き方ではなく、シェルプロセスの起動と結果の読み戻しの経路で起きています。#94196の報告では、デスクトップアプリでフォルダを選ばずに始めたセッションが共通の条件で、フォルダを選んだ新しいセッションを始めると回避できました。報告者たちは、実行ポリシーの確認・サンドボックス設定の切り替え・再インストールを試しましたが、どれも症状を変えませんでした。

フォルダを選んでも直らないときは、CLI側で動くかを確かめ、シェルの検出、PATH、セキュリティソフトの順に絞ります。アプリ側の不具合の可能性が残るため、バージョンと再現条件を控えてissueに追記するのが、修正に最も近い手段です。