自動起動した CLI エージェントが「初回プロンプト」で無言のまま固まる問題を潰す

対象: Windows で Claude Code を cmd /c start ... claude.cmd "<プロンプト>" のように人が見ていない窓から起動する自動化 （セッション自動再開、夜間バッチ、タスクスケジューラ等）。同種の TUI ツール全般にも応用できる。

症状

自動起動の仕組みは正しく動いているのに、窓が初回プロンプトで止まったまま何時間も放置される。 プロセスは生きているのでヘルスチェックも通り、誰も気付かない（実測: 27分放置。同型で丸1日眠っていた例もある）。

止める犯人は2つある。IDE 拡張から起動している間は一度も出ないので、自動化を書いた本人は再現できない。

1. テーマ選択 Choose the text style that looks best with your terminal
2. フォルダ信頼 Quick safety check: Is this a project you trust?

原因1: テーマ未設定 — 置き場所を間違えると消える

~/.claude/settings.json に "theme": "dark" を入れる。

{ "theme": "dark", "hooks": { } }

~/.claude.json（グローバル状態ファイル）側に theme を書いても数十秒で消える。アプリが状態を書き戻すとき、 知らない top-level キーとして落とされるため。実測では書いた25秒後に消滅し、同時に書いた別キー （projects[].hasTrustDialogAccepted）は正規キーなので残った。 「書いた直後に効いた」ことを根拠に完了報告すると、後で静かに戻る。書いてから20〜30秒待って読み直すこと。

版によっては config サブコマンドが存在しない。<cli> config get theme と打つとサブコマンドではなくプロンプトとして解釈され、 セッションが1本立ち上がってトークンを溶かすので、まず <cli> --help でサブコマンドの有無を確認する。

原因2: 作業フォルダが未信頼 — ここは勝手に潰さない

信頼状態は ~/.claude.json の projects["<パス>"].hasTrustDialogAccepted。キーはツールが書く形式に合わせる （例: d:/foo/bar のように小文字ドライブ＋スラッシュ）。既存エントリを1つ開いて表記を確認してから足す。

// ~/.claude.json に対して: 対象フォルダだけ true にする
const dirs = ['<フォルダ1>', '<フォルダ2>'];
for (const d of dirs) c.projects[d] = { ...(c.projects[d] || {}), hasTrustDialogAccepted: true };

これは安全確認のゲートなので、エージェントの判断で一括承認してはいけない。

• 対象を列挙して「このフォルダを信頼済みにしてよいか」を人に確認し、同意を得た分だけ立てる
• 新規フォルダでは従来どおり確認が出る状態を残す（ゲートごと無効化しない）
• 「手作業ゼロ」を安全機構の解除で達成しない、という原則の適用例

検証: 画面を撮って目視する（これをやらないと直したつもりで終わる）

自動起動と同じ経路で窓を実際に起動し、スクリーンショットを撮って読む。所要20秒、撮影後に窓を閉じるところまで自動化する。

Add-Type -AssemblyName System.Drawing
$t0 = Get-Date
Start-Process cmd.exe -ArgumentList '/c start "" /D "<作業フォルダ>" "<CLIのフルパス>"'
Start-Sleep -Seconds 18
Add-Type -TypeDefinition @'
using System;using System.Runtime.InteropServices;
public class W{
 [DllImport("user32.dll")] public static extern bool SetForegroundWindow(IntPtr h);
 [DllImport("user32.dll")] public static extern bool GetWindowRect(IntPtr h,out R r);
 [DllImport("user32.dll")] public static extern bool ShowWindow(IntPtr h,int c);
 [StructLayout(LayoutKind.Sequential)] public struct R{public int L,T,Rt,B;}}
'@
$p = Get-Process | Where-Object { $_.ProcessName -in @('cmd','WindowsTerminal') -and $_.MainWindowHandle -ne 0 -and $_.StartTime -gt $t0 } | Select-Object -First 1
[W]::ShowWindow($p.MainWindowHandle, 9); [W]::SetForegroundWindow($p.MainWindowHandle); Start-Sleep 2
$r = New-Object W+R; [W]::GetWindowRect($p.MainWindowHandle, [ref]$r)
$bmp = New-Object System.Drawing.Bitmap(($r.Rt-$r.L), ($r.B-$r.T))
[System.Drawing.Graphics]::FromImage($bmp).CopyFromScreen($r.L, $r.T, 0, 0, $bmp.Size)
$bmp.Save('<出力先>\shot.png')
Stop-Process -Id $p.Id -Force

撮った PNG をエージェントに読ませ、入力待ちのプロンプト行まで到達しているかを見る。

効かなかった検証方法（先に潰しておく）

• コンソールバッファ直読み (FreeConsole → AttachConsole(pid) → CreateFileW("CONOUT$")): CONOUT$ が開けず失敗した。 接続先 pid を親子どちらにしても同じ。時間を溶かすので最初からスクショにする。
• 起動時の副作用ファイルを見る: 設定キャッシュ等はプロンプトで止まっていても書かれるため、 「止まっている」と「入力待ちに到達した」を区別できない。セッションログは最初の入力があるまで作られない。
• --print / 非対話モードで試す: TUI を通らないので初回プロンプトの検証にならない。

手順まとめ

1. ~/.claude/settings.json に theme を追加（~/.claude.json ではない）
2. 20〜30秒待って読み直し、消えていないことを確認
3. 自動起動が使うフォルダを列挙し、人の同意を取って信頼フラグを立てる
4. 同じ経路で窓を起動してスクショを撮り、入力待ちまで到達したことを目視
5. 撮影用の窓は必ず kill する（放置窓を自分で増やさない）

副次的に見つかること

この調査中に「設定ファイルにモードを書いたのに読むコードが1行も無く、設定が死んでいる」という類のズレが露出しやすい。 自動起動の入口（呼び出し元）を1本 grep して、設定キーが実際に読まれているかも併せて確認しておくと良い。