auto modeで許可したgit pushがブロックされる不具合と回避策
auto modeで「pushして」と伝えたのに、分類器が理由なしで止める報告が複数出ています。GitHub issueの内容と現行docsを突き合わせ、止まったときの確認先と設定での回避策を示します。
Claude Codeのauto modeで「pushして」と明示したのに、分類器が理由を示さずに止める。GitHubのissueに、この報告が少なくとも3件並んでいます。docsの記述では、作業中リポジトリへのpushは確認なしで通る操作です。報告された挙動と文書の説明には食い違いがあります。
この記事では、3件の報告で何が起きたかと、止まったときに確認する場所、設定での回避策を順に扱います。3件はいずれもopenのままなので、回避策はdocsに書かれた仕組みの範囲で組み立てます。
報告されている3件の症状
報告内容は次のとおりです。
| issue | 環境 | 止まった操作 | 特徴 |
|---|---|---|---|
| #98079 | 環境macOS、Opus 5.5、外部アプリ経由で起動 | 止まった操作作業中ブランチへのgit pushとgit branch -D | 特徴3回連続で拒否。理由の説明なし |
| #98109 | 環境Windows 11、VS Code拡張 | 止まった操作作業ツリー内の1ファイル編集(Python経由の文字列置換) | 特徴同一コマンドの再試行は通った |
| #98478 | 環境Windows 11、VS Code拡張、並列セッション | 止まった操作mainへのpush、gh pr merge、デプロイ用スクリプトなど | 特徴ユーザーが明示指示した操作も拒否 |
共通点は拒否メッセージです。3件ともjudged this action dangerous (it gave no explanation)という文言が報告されています。#98478には、Merge Without ReviewやProduction Readsのように、規則名が付いた拒否も含まれます。
#98079: 指示してもpushが通らない
報告者は、ローカルのコミットをmainへ送るfast-forwardのpushをチャットで明示的に頼みました。forceのオプションはありません。それでもgit fetch && git push origin mainは3回拒否されました。
次に、拒否メッセージの案内に沿って許可ルールの追加をClaudeに頼みましたが、これも[Self-Modification]として拒否されています。チャット欄に!git pushを入力しても、その環境ではモデルへの平文として渡るだけで実行されませんでした。結果として、ユーザーがセッションを離れて別の端末で作業する羽目になっています。
#98109: 同じコマンドが再試行では通る
作業ツリー内の1ファイルを書き換える操作が、理由なしで拒否されました。ユーザーが再試行を指示すると、バイト単位で同一のコマンドが何も聞かれずに実行されています。判定が毎回同じとは限らない、という報告です。
#98478: 「mergeして」「deployして」も止まる
並列セッションで、ユーザーが明示的に指示したPRのマージとデプロイが拒否されました。同じ内容を1手順ずつ直接実行すると、マージ以外は通ったとされています。スクリプトにまとめた形が引っかかった可能性は、報告からは切り分けられていません。
docsでは何が止まる設計なのか
現行のdocsは、この種のpushを止める対象に挙げていません。
- 作業中リポジトリのどのブランチへのpushも、確認なしで通る。デフォルトブランチへのpushも含まれる
- 例外は、
production・release・gh-pagesのように、名前がデプロイ先や公開先を示す非デフォルトブランチ。分類器が個別に判断する - force push、シークレットがコミットに入る場合、リポジトリ外へ秘密を送る変更は、pushでも止まる
つまり、#98079のようにmainへのfast-forwardを送る操作は、文書上は通る側にあります。docsは、拒否理由の出方についても「ほとんどのセッションでは[Data Exfiltration]のような規則名が示される」と説明しています。説明文のない拒否は、この記述とも合いません。
明示した意図が効くのはどこまでか
auto modeの分類器には優先順位があります。hard_denyは無条件で止め、soft_denyはユーザーの意図やallowの例外で覆せます。ユーザーの発言が、実行しようとしている操作を直接かつ具体的に述べていれば、分類器はsoft_denyに当たる操作も許可します。
ただし条件があります。「リポジトリを整理して」のような一般的な依頼は、明示的な意図に数えられません。「このブランチをforce-pushして」まで言う必要があります。また、承認が及ぶのは名指しした1回の操作です。後続の操作は、承認を継続として与えない限り再び判定されます。
会話中の「待って」が残っている可能性
見落としやすいのが、逆向きの働きです。「pushしないで」「レビューが終わるまでデプロイを待って」といった発言は、分類器にとって止める合図になります。docsによれば、境界は後のメッセージで解除するまで有効です。Claude自身が条件を満たしたと判断しても解除されません。
この境界はルールとして保存されず、分類器が毎回トランスクリプトから読み直します。長いセッションで古い発言が残っていれば、今回の「pushして」と矛盾した状態で判定されている恐れがあります。報告の中に、そうした発言があったかどうかは書かれていません。
止まったときに最初に見る場所
拒否が出たら、設定をいじる前に4つを見ます。
- 入力欄の近くの通知。
bash denied by auto mode · [規則名] · /permissionsの形で、ツールと規則名が出ます Ctrl+Oで開くトランスクリプト。畳まれたRan 3 shell commandsのような行を展開できます/permissionsのRecently deniedタブ。拒否の一覧が残り、rキーで再試行を指示できます- PermissionDeniedフック。拒否された入力を
tool_inputとして受け取れます
文言の読み分けも重要です。Denied by auto mode classifierに規則名が付いていれば、分類器が危険と判断した拒否です。分類器の応答がない、モデルが一時的に使えない、といった文言なら、判定そのものが出ていません。後者の対処はauto modeの分類器が応答不能になる原因と回避策にまとめています。
分類器のレビューをサーバー側に任せる構成では、サーバーが判定を返さなかった操作も拒否されます。判定なしの応答が10回続くと、そのターンは止まります。規則名のない拒否は、この経路の可能性もあります。
再試行は安いので先に試す
#98109では、同一コマンドの再試行が通りました。Recently deniedタブでrを押すと、モデルに「再試行してよい」と伝えるメッセージが送られ、会話が再開します。
フックで自動化する手もあります。PermissionDeniedフックが次のJSONを返すと、モデルに再試行を許す旨のメッセージが会話へ追加されます。
{
"hookSpecificOutput": {
"hookEventName": "PermissionDenied",
"retry": true
}
}注意点が2つあります。フックは拒否そのものを覆さず、モデルに再試行を促すだけです。また、分類器が判定を出さなかった拒否では、retry: trueは無視されます。
設定で回避する3つの方法
方法1: autoMode.allowで定型の操作を許可する
同じ型の操作が繰り返し止まるなら、autoMode.allowに自然文のルールを足します。"$defaults"を含めておくと、既定のルールを残したまま追加できます。
{
"autoMode": {
"allow": [
"$defaults",
"Pushing a fast-forward commit to the current repository's main branch is allowed when the user asks for it"
]
}
}書き込み先は~/.claude/settings.jsonです。分類器は、プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonにあるautoModeを読みません。リポジトリに含まれるファイルから、許可ルールを注入されないためです。/permissionsのAuto modeタブからも編集でき、変更は同じファイルに保存されます。
"$defaults"を忘れると、そのセクションの既定ルールが丸ごと置き換わります。soft_denyならforce pushやcurl | bashのブロックが消えるため、含めておく必要があります。
方法2: permissions.allowで具体的なコマンドを通す
判定順の1番目は、allow・ask・denyルールへの一致です。一致した操作は分類器の前に決着します。具体的なコマンドを書いたルールなら、auto modeに入っても残ります。
{
"permissions": {
"allow": [
"Bash(git push origin main)"
]
}
}一方、Bash(*)のような全面許可や、Bash(python*)のようなインタープリタ全体の許可は、auto modeに入る時点で外れます。広く書いても効きません。
この方法が#98079の症状に効くかどうかは、issueに報告がありません。docsの判定順から導いた設定であり、動作を保証するものではない点に注意してください。
方法3: askルールで「必ず聞く」に倒す
逆向きの発想もあります。止まるたびに原因を探すより、pushだけは常に確認を挟む運用にする方法です。
{
"permissions": {
"ask": ["Bash(git push *)"]
}
}内容に基づくaskルールは分類器より先に評価され、auto modeでも必ず確認が出ます。分類器が自動で拒否する経路を避け、人が承認できる経路に寄せられます。git -C <dir> pushのように書き方を変えたpushは、このルールに一致しない点には注意が必要です。
設定ファイルの編集はClaudeに頼まない
#98079では、許可ルールの追加をClaudeに頼んだ操作が[Self-Modification]で拒否されました。設定ファイルは、自分のエディタで直接書くのが確実です。/permissionsのタブから編集する方法も使えます。
切り分けの早見表
| 状況 | 疑うこと | 先に試すこと |
|---|---|---|
| 拒否に規則名が付いている | 疑うこと分類器の判定 | 先に試すことclaude auto-mode defaultsで規則の文面を読む |
| 理由なしで拒否され、再試行で通った | 疑うこと判定のぶれ(#98109) | 先に試すことrキーで再試行 |
| 同じ操作が3回続けて拒否された | 疑うこと分類器に文脈がない | 先に試すことautoMode.allowかenvironmentを足す |
| 「待って」と言った覚えがある | 疑うこと会話中の境界 | 先に試すこと解除を明示するか、圧縮後に言い直す |
productionなど名前がデプロイ先を示すブランチ | 疑うこと本番デプロイ扱い | 先に試すこと意図をブランチ名つきで明示する |
規則の文面は、claude auto-mode defaults --label 'Git Destructive'のように先頭のラベルを指定して読めます。実効設定はclaude auto-mode configで確かめられます。
繰り返し止まると、auto modeそのものが一時停止する
分類器が同じ操作を3回続けて、または合計20回ブロックすると、auto modeは一時停止して通常の確認プロンプトに戻ります。プロンプトで承認すると再開します。#98079の「3回拒否」は、この閾値と重なる回数です。
この回数は設定で変えられません。合計の数え方はセッションを通じて保持され、上限に達して戻ったときだけリセットされます。非対話の-p実行にはプロンプトの戻り先がなく、操作は実行されないまま、Claudeが作業を続けます。
報告するときに添える情報
誤ブロックは/feedbackで送れます。再現しやすくするには、次の情報が役立ちます。
- 拒否メッセージの全文と、通知に出た規則名
- 拒否された操作の入力(PermissionDeniedフックで取れます)
- 使っていた面(ターミナル、VS Code拡張、デスクトップ)とClaude Codeのバージョン
- 直前に「やめて」「待って」と伝えていなかったか
分類器まわりの関連仕様は、Claude Codeのauto mode分類器は何を止めているかとauto modeブロック一覧で扱っています。
まとめ
docsの設計では、作業リポジトリへの通常のpushは止まる対象ではありません。理由なしの拒否が出たら、まず再試行と会話中の境界を疑い、繰り返すなら~/.claude/settings.jsonのautoMode.allowで定型化するのが堅実です。pushを毎回確認したい運用なら、permissions.askが確実な手段になります。報告された3件はいずれもopenのままで、修正が入れば、ここで挙げた回避策は不要になります。