朝いちで、Claude Codeに任せとる作業が止まっとった。原因は許可の設定。前の日に同じ止まり方をしたばっかりで、そこはもう直したはずやった。
許可リストは、止まったファイルを1本ずつ名指しで足しても、次に別のファイルを触った瞬間また止まります。名指しは名指ししたものにしか効かんから。人が画面を見とる時は押せば済むけど、無人で走らせる予定があるなら、最初からフォルダ単位（末尾に **）で書いとくほうが早いです。ただしファイルの書き込みは Edit(...) の形で（9月の追記を参照）。
前にWindows自動化で黙って壊れる罠3つという記事を書きました。あっちは「エラーも出さずに間違う」話。今回は逆です。ちゃんと止まってくれるのに、何回直しても同じところで止まる話。
名指しで許可を足した翌日、また同じところで止まった
Claude Codeには「この操作は毎回確認せんでええ」を登録しておく許可リストがあります。設定ファイルの中の allow ってところ。ここに書いてある操作は確認なしで通る。書いてない操作は画面に確認が出て、人が押すまで待つ。
普段はこれで困りません。問題は人が画面を見てへん時です。決まった時刻に自動で走る作業を組んどると、確認待ちのまま固まって、誰も押さんまま朝が来る。
で、実際に止まりました。止まったファイルを1本、許可リストに名指しで足した。その翌日、同じフォルダの別のファイルで、まったく同じ止まり方をした。
当たり前です。名指しは名指ししたものにしか効かん。頭では分かっとるのに、目の前で止まっとるファイル名をそのまま貼るのが一番早く見えてまう。しかもその場では直った気になれるのが厄介なところ。
自分の許可リストを数えたら113本あった
今日あらためて数えました。うちの設定ファイルの allow に並んどる行が113本。
中を見ると、同じフォルダの話が固まって並んどるところがあります。フォルダそのものが1本、そのフォルダの中のファイルが9本。合わせて10本、全部が同じフォルダの中身でした。
そしてそのちょっと下に、あとから足したらしい1行がある。同じフォルダのパスの末尾に **（この下は全部、という意味）を付けたやつ。操作の種類は上の10本と同じ（書き込み）。場所もこのフォルダの中。つまり、あとから足したこの1本が、名指ししたファイル9本を丸ごと含んどる形です。残りの1本はフォルダそのものを指した行なので、ここでは数に入れてません。
順番に足していった跡が、そのまま並んで残っとる形です。何回止まってこうなったかまでは記録してません。ただあとの1本で足りるものを、先に9本ぶん名指しで書いとったのは確か。
押したはずの「常に許可」が、設定ファイルに無い
確認の画面には「今回だけ許可」と「常に許可」があります。常に許可を押したら、次からは聞かれんはず。
押しました。翌日、同じところで止まりました。
設定ファイルを見に行ったら、更新時刻が前の日から動いてへん。押した内容がここに入った形跡がない。
ここは正直に書いときます。押し間違えたのか、別の場所に保存されとるのか、そこまでは確かめられてません。分かったのは更新時刻が動いてへん、の一点だけ。ただ無人で回す側から見たら理由はどっちでもよくて、次の実行では効いてへんが結論になります。
追記（2026年9月）：答えらしきものが公式のドキュメントにありました。ファイルの書き込みの確認で「次から聞かんで」を選んでも、設定ファイルには保存されず、そのセッションが終わるまでしか効かん、と書いてある。コマンドの実行やWebの取得は保存されるのに、書き込みだけは保存されん仕様です。止まったのは書き込みやったので、たぶんこれ。この記事を書いた8月の版でも同じ仕様やったかまでは確かめてません。
打った対策が効いたかは、次に同じ場面が来るまで分からん
これがいちばん気持ち悪いところ。
対策を打った日、手元に残るのは「打った」という記憶だけです。効いた証拠はどこにも出ません。止まらんかった記録も、うまく通った印も残らん。何も起きんのやから当然といえば当然。
答え合わせができるのは、次に同じ場面が来た時。今回で言うと翌日の朝です。そこで初めて「効いてへんかった」が分かる。
自分でツールを組んどると、こういう答えが遅れて出る修正がけっこう混ざります。直した気になって次の作業へ行って、忘れた頃に同じところで転ぶ。
無人で回す予定があるなら、最初からフォルダ単位で書く
結論はシンプルです。
- 人が横で見とるやつは名指しでええ。止まっても押せば済む
- 無人で走らせるやつは最初からフォルダ単位で書く（末尾に
**） - 広げすぎが怖いならフォルダのほうを分ける。自動で触ってええものだけをそこに置いて、そのフォルダにだけ広い許可を出す
実際うちも、フォルダごと許可しとるのは用途を決めた特定のフォルダだけです。どのフォルダにも出しとるわけやない。広い許可を1本と、置き場所の設計をセットにするのが今のところの落とし所。
もう1個。止まった時にその工程だけ諦めて先に進む作りにしておくと、被害が1工程で止まります。許可が1個足りんかっただけでその日の全部が飛ぶのは、あまりにもったいない。
この手の「黙って止まる」「黙って間違う」は、まだ何個か手元に溜まっとります。次はそのへんをまとめて書くつもり。
その「黙って間違う」側の1つは、あとでフォームの自動入力が届いてなかった話｜画面に出ても送信は空に書きました。
許可リストの書き方｜コマンドとファイルで形が違う
ここからは、書いた後に公式のドキュメントを読み直して分かったことです（2026年9月時点）。許可リストは設定ファイルの permissions の中に書きます。置き場所は3つ。
~/.claude/settings.json：自分の全部のプロジェクトに効く.claude/settings.json：そのプロジェクト用。チームで共有する前提.claude/settings.local.json：そのプロジェクト用で、自分だけ
書き方はこんな形です。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Edit(/auto-work/**)"
],
"deny": [
"Bash(git push *)"
]
}
}コマンドは Bash(...)。* は「ここに何が入ってもええ」の意味で、Bash(npm run *) なら npm run で始まるコマンドが全部通ります。細かいけど、* の前のスペースも条件のうちで、Bash(ls *) は lsof を通さんのに、スペース無しの Bash(ls*) は通してまう。
ファイルの書き込みは Edit(...)。ここは自分がやらかしとったところで、公式には「Write(...) で書いたパスの行は受け付けるけど判定には使わん（起動時に警告を出す）」と書いてあります。9月にうちの設定ファイルを数え直したら、Write で書いた行が12本残っとった。
しかもその12本のうち11本は、この記事の前半で数えた「名指し10本と、あとから足したフォルダ単位の1本」そのものでした。全部 Write(...) の形で、場所は .claude フォルダの中。下に書くとおり .claude の中は許可リストでは通らん場所なので、今の公式の説明どおりなら、フォルダ単位に広げた1本も効いてへんかった側です。「フォルダ単位で書く」という結論は変えてません。ただ、Edit の形で、.claude と .git の外のフォルダに書く、が条件になります。
パスの書き方もまぎらわしい。まず ** はフォルダをまたいで下を全部、* は1つのフォルダの中だけ。そのうえで、頭の付け方で起点が変わります。
~/で始める：自分のホームフォルダが起点。Edit(~/tool/**)なら、ユーザーフォルダの下の tool の中全部。個人のパソコンならこれがいちばん書きやすい/1本で始める：設定ファイルの持ち主の場所が起点。プロジェクトの設定に書いたEdit(/auto-work/**)は、プロジェクトの中の auto-work フォルダ- 何も付けない：今作業しとるフォルダが起点
//で始める：ディスクの根っこから。Windows はC:\が/c/に直されてから照合されるので//c/...の形
もう1個覚えとくとええのが順番です。deny（禁止）→ ask（毎回確認）→ allow（許可）の順に見て、最初に当たったもので決まる。広い禁止を1本書いたら、細かい許可を足してもその穴は開けられません。
それと、.claude や .git のフォルダへの書き込みは、許可リストに書いても自動では通りません。設定そのものが壊れんように守られとる場所です。うちでも .claude の中に書かせる工程だけは、何を足しても毎回確認で止まっとりました。理由が分かるまで、しばらく同じ所で転んでた。
権限モード6つの違い
許可リストとは別に、「どこまで聞かずに進めるか」を丸ごと切り替える権限モードがあります。公式のドキュメントに載っとる6つを、何が確認なしで通るかで並べるとこうなる。
| モード | 確認なしで通るもの |
|---|---|
| default（画面の表示は Manual） | 読むだけ。それ以外は毎回聞く |
| acceptEdits | 読む・ファイルの編集・mkdir や mv などのよく使うファイル操作 |
| plan | 読んで調べるだけ。計画を承認するまでファイルは書き換えん |
| auto | ほぼ全部。かわりに裏で別のモデルが操作を見張る |
| dontAsk | 読むだけと、許可リストにあるもの。確認が要る操作は聞かずに全部断る |
| bypassPermissions | 確認をほぼ全部飛ばす。公式はコンテナや仮想マシンの中だけで使えと書いとる |
使っとる最中は Shift+Tab で順に切り替わります。auto で始まっとる時は1回押すと default に落ちて、あとは default → acceptEdits → plan → default の輪。始める時のモードは、設定ファイルの "defaultMode" か、起動時の claude --permission-mode plan のような指定で決まります。
この記事の話で効いてくるのは dontAsk です。無人で走らせた時に困ったのは「確認待ちのまま朝まで固まる」ことでした。dontAsk は、確認が出るはずの操作を待たずに断って先へ進む。止まる場所が「固まる」から「その操作だけ失敗する」に変わるので、上に書いた「その工程だけ諦めて先に進む」とも相性がええ。公式もCIやスクリプト向けと書いてます。うちはまだ切り替えてなくて、設定ファイルは default のままです。
ちなみに公式によると、Pro・Max・Team のプランは何も設定せんと auto で始まります（v2.1.228以降、Windowsで直接動かす場合は v2.1.233以降）。気づいたら確認が出んようになっとった、という人はここを見てみてください。出所は公式の権限の設定と権限モードのページです。
よくある質問
許可リストは最初から全部許可にしたらあかんの？
やめといたほうがええです。許可リストは「間違って消す」「間違って送る」を止める最後の柵でもあるので。おすすめは、自動で触ってええ場所を専用のフォルダにまとめて、そこにだけ広い許可を出す形。
名指しで足した古い行は消したほうがいい？
Edit(...) で書いた広い許可が1本あれば（.claude や .git の外なら）、名指しの行は無くても通ります。ただ消すのは何日か回して問題なしを確かめてからで十分。うちも今は残したままです。
止まったことに、どうやって気づくの？
確認待ちの停止はエラーやないので、失敗の記録が残りません。うちは自動で走らせとる作業に、走った印を毎回1行残させてます。その1行が無い日は、途中で止まったと分かる。