commit-push-prがpush remoteへのgit pushを自動許可

Claude Code v2.1.206から、/commit-push-prが確認なしでgit pushを実行できる宛先が広がりました。これまではoriginという名前のリモートだけが自動許可の対象でした。v2.1.206からは、remote.pushDefaultで指定したリモートと、設定済みリモートが1つしかない場合のそのリモートも対象に入ります。

対象は/commit-push-prというスキル経由のpushだけです。Claude Code全体のgit pushの権限が緩んだわけではありません。この変更は2026年7月6日〜10日の週(公式の週次まとめのWeek 28、v2.1.202〜v2.1.206)に配布されました。

/commit-push-prの自動許可対象がどう変わったか

/commit-push-prは、変更のコミット作成からpush、プルリクエスト作成までを一括で進める組み込みスキルです。公式changelogのv2.1.206には次の1文が載っています。

/commit-push-pr now auto-allows git push to the repo's configured push remote (remote.pushDefault, or the sole remote when only one is configured) in addition to origin. (/commit-push-prは、git pushの自動許可先に、originに加えてリポジトリの設定済みpushリモート — remote.pushDefault、または設定済みリモートが1つだけの場合はそのリモート — を含めるようになった)

fork経由のコントリビュートのように、読み取り元(origin)とpush先を分けている構成では、remote.pushDefaultがpush先を指す設定です。今回の変更はこの構成で効きます。リリース全体の内容はClaude Code v2.1.206 — MCPタイムアウト修正、/doctorがCLAUDE.md分割を提案にまとめています。

/commit-push-prの仕事はpushだけではありません。v2.1.20では、MCP経由でSlackチャンネルを設定していれば、作成したプルリクエストのURLが自動投稿されるようになりました。コミット作成からpush、PR作成、通知までを1つのスキルが受け持っています。

今回のchangelogの文面が広げているのは、git pushの宛先だけです。PR作成に使うghコマンドへの言及はありません。後述するv2.1.229の危険フラグ制限は、/commit-push-prが発行するgitとghの危険フラグ付きコマンドにかかる別の変更です。

remote.pushDefaultはどのリモートを指すのか

remote.pushDefaultは、git pushを引数なしで実行したときの既定のpush先リモートを決めるgitの設定項目です。Claude Codeの自動許可は、この設定が指すリモートを対象にします。

gitの挙動を、ローカルの空リポジトリ2つ(up.gitとfk.git)をoriginとforkに見立てて試しました(git 2.50.1)。pushは--dry-runで、ネットワークは使っていません。

git remote -v
git config --get remote.pushDefault      # 未設定なら何も出ない
git push --dry-run -v                    # pushDefault もupstreamも無い状態
git config remote.pushDefault fork
git push --dry-run -v                    # pushDefault を設定した後
git config branch.main.pushRemote origin
git push --dry-run -v                    # ブランチ単位の設定も加えた後

出力は次のようになりました。1回目は宛先が決まらずエラー、2回目はfork、3回目はoriginです。

fatal: The current branch main has no upstream branch.
To push the current branch and set the remote as upstream, use
    git push --set-upstream origin main
 
Pushing to ../fk.git
 * [new branch]      main -> main
 
Pushing to ../up.git
 = [up to date]      main -> main

3回目の結果が、設定を確かめるうえでの要点です。branch.<名前>.pushRemoteを設定したブランチでは、gitはremote.pushDefaultよりそちらを優先してpush先を決めます。v2.1.206のchangelogが挙げているのはremote.pushDefaultと「唯一のリモート」だけで、branch.<名前>.pushRemoteには触れていません。

ブランチ単位でpush先を変えている場合、gitが実際に選ぶリモートと自動許可の対象が一致するとは限りません。気になるときは、一度ターミナルで--dry-runを試すと安全です。

remote.pushDefaultが未設定で、リモートが複数ある場合は、origin以外への自動許可は広がりません。

既存のask・denyルールは上書きされない

権限ルールは、deny、ask、allowの順に評価され、最初に一致したルールが結果を決めます。ルールの具体性は順序に影響しません。allow側の対象を広げる今回の変更は、先に評価されるdeny・askを越えません。

settings.jsonでgit push全体をaskにしている場合を考えます。

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

denyは、どの階層に置いても、他の階層のallowでは打ち消せません。askもallowより先に評価され、一致すればallowがあっても確認が出ます。

書く場所で変わるのは、効く範囲です。~/.claude/settings.json(ユーザー設定)なら手元のすべてのリポジトリ、.claude/settings.json(共有プロジェクト設定)ならそのリポジトリを使うメンバー全員、.claude/settings.local.jsonなら自分だけ・そのリポジトリだけです。

組織として確認を外させたくない場合は、managed settingsに置きます。managed settingsの権限ルールは他のどの階層からも上書きされません。設定ファイル同士の優先順位は、managed settings、コマンドライン引数、プロジェクトローカル、共有プロジェクト、ユーザーの順です。

もう1点、公式のBashルールの説明に注意が要ります。ルールが照合するのはClaudeが書いたコマンドの文字列です。Bash(git push *)はgit push origin mainを止めますが、次の書き方は止めません。

一致しなかったコマンドは、他のルールと権限モードで扱いが決まります。公式は、denyやaskのBashルールはコマンドの書き方に依存しない境界ではないと説明しています。ファイルシステムやネットワークの制限にはサンドボックスを、コマンド全文を自前で検査したい場合にはPreToolUseフックを使う、という案内です。PreToolUseフックが終了コード2で止めた呼び出しは、allowルールが一致していても実行されません。

今回の変更で確認が省略されるのは、git pushにaskやdenyを書いていない状態に限られます。ルールの書き方全般はClaude Code settings.json完全ガイドにあります。

pushの自動許可が広がると、確認なしで書き込まれるリモートが増えます。自分のforkにもupstreamにも書き込み権限がある構成では、remote.pushDefaultの値を取り違えると、意図しないリモートへ確認なしでpushが進みます。設定したときは、git remote -vの宛先と見比べておくと取り違えに気づけます。

Claude Codeの権限システムには、ユーザーが承認しても解除されないハードコードされたブロックも別にあります。worktree隔離下のセッションがmain checkoutへgit -Cでリダイレクトする操作は、PreToolUseフックで承認しても拒否されたままです。詳しくはClaude Codeのworktreeはmainへの読み取り専用gitも拒否するで扱っています。今回の変更はこの逆方向で、確認を求めていた操作を自動許可へ広げるものです。

/commit-push-prの自動承認は両方向に調整されている

push先を広げたv2.1.206のあと、/commit-push-prは別のリリースで自動承認の範囲を絞る変更も受けました。CHANGELOG.mdのv2.1.229には次の1文があります。

Changed /commit-push-pr so git/gh commands with dangerous flags (--force, --amend, --no-verify, etc.) are no longer auto-approved (/commit-push-prが発行するgit・ghコマンドのうち、--force・--amend・--no-verifyなど危険フラグを含むものは自動承認の対象外になった)

--forceは取り消しにくい操作で、--no-verifyはフックを迂回する操作です。同じスキルの中で、宛先を広げる変更と、リスクの高い操作を確認に戻す変更が別々に入っています。

自分の環境で確かめる手順

影響の出方は、リモートの構成と権限ルールで決まります。CI環境や無人の自動化でClaude Codeを動かしている場合も、基準は同じです。人が都度確認できない分、確認なしでpushされるリモートを先に把握しておく意味が大きくなります。

この3点の結果が、次の表のどの行に当たるかを決めます。

Coworkのgit push拒否とは別の仕組み

今回の自動許可は、ターミナルセッションで/commit-push-prを実行したときの権限ルールの話です。Coworkのクラウドセッションでgit pushが「not in this session's authorized repository set」のようなエラーで拒否される場合、原因は権限ルールではなく、gitプロキシ側が管理する別の認可の仕組みです。似た症状でも原因は別なので、切り分けが必要です。詳しくは「authorized repository set」エラーでCoworkのgit pushが拒否されるにまとめています。

今回の変更はpushを止める仕組みではなく、確認プロンプトを省略する仕組みです。git pushがエラーで失敗するなら、権限ルールより先に、認証切れやブランチ保護、Coworkのような別経路の認可制限を疑うほうが近道です。

まとめ

持ち帰る判断は1つです。確認を残したいリモートがあるなら、自動許可の対象がどこまで広がっても、git pushにaskルールを置いておけば今回の変更の影響を受けません。ブランチ単位でbranch.<名前>.pushRemoteを使っている構成だけは、gitが選ぶ宛先と自動許可の対象がずれうるため、--dry-runで先に確かめておく価値があります。