commit-push-prがpush remoteへのgit pushを自動許可
Claude Code v2.1.206で、/commit-push-prのgit push自動許可にpush remoteが加わりました。remote.pushDefaultとask/denyルールとの関係を扱います。
Claude Code v2.1.206から、/commit-push-prが確認なしでgit pushを実行できる対象が広がりました。これまではoriginという名前のリモートへのpushだけが自動許可の対象でした。この版からは、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-prnow auto-allowsgit pushto the repo's configured push remote (remote.pushDefault, or the sole remote when only one is configured) in addition toorigin. (/commit-push-prは、git pushの自動許可先に、originに加えてリポジトリの設定済みpushリモート —remote.pushDefault、または設定済みリモートが1つだけの場合はそのリモート — を含めるようになった)
この変更が効くのは、複数のリモートを使い分けるワークフローです。originは読み取り専用のミラーで、実際のpush先は別名のリモートに設定しているケースでは、v2.1.205までは毎回確認が挟まっていました。v2.1.206からは、remote.pushDefaultさえ設定していれば、そのリモートへのpushも確認なしで進みます。内部ミラーへoriginを向けたままpushだけ別リモートで行う構成や、fork経由のコントリビュート運用では、まさにremote.pushDefaultがpush先を指す設定なので、この変更の恩恵をそのまま受けます。リリース全体の内容はClaude Code v2.1.206 — MCPタイムアウト修正、/doctorがCLAUDE.md分割を提案にまとめています。
/commit-push-prが扱うのはgitのpushだけではありません。v2.1.20では、MCP経由でSlackチャンネルを設定していれば、作成したプルリクエストのURLが自動投稿されるようになりました。コミット作成からpush、PR作成、通知までを一続きの操作としてまとめているスキルです。
今回自動許可の対象が広がったのは、あくまでgit pushというコマンドに限られます。自動許可が広がったのはgit pushの宛先だけで、PR作成に使うgh pr createは対象外です。/commit-push-prが発行するgit・ghコマンド全体の危険フラグ制限(後述するv2.1.229の変更)は範囲がもっと広い一方、今回のpush remote拡大はgit pushの宛先だけに絞った変更だと読めます。
remote.pushDefaultはどのリモートを対象にするか
remote.pushDefaultは、gitの設定項目の1つで、git pushを引数なしで実行したときのデフォルトのpush先リモートを指定します。Claude Codeの自動許可は、この設定値をそのまま読み取って対象リモートを決めます。
git remote -v
git config --get remote.pushDefault
git config remote.pushDefault upstreamremote.pushDefaultを設定していない場合、Claude Codeは設定済みリモートが1つだけならそのリモートを自動許可の対象にします。リモートが複数あるのにremote.pushDefaultを設定していない場合、origin以外のリモートへの自動許可は広がりません。forkへのpushとupstreamへのpushを使い分けているリポジトリでは、この設定の有無で挙動が変わります。
既存のask・denyルールは上書きされない
Claude Codeの権限ルールは、denyが最初に評価され、次にask、最後にallowという順で、最初に一致したルールが適用されます。この評価順は/commit-push-pr固有の自動許可にも共通して働きます。今回の変更はallow側の対象を広げるものなので、それより先に評価されるdeny・askのルールがあれば、そちらが優先されます。
settings.jsonで次のようにgit push全体をaskに指定している場合を考えます。
{
"permissions": {
"ask": ["Bash(git push *)"]
}
}このaskルールはどの設定ファイルに書いても有効です。~/.claude/settings.json(ユーザー設定)に書けば手元のすべてのリポジトリに、プロジェクトの.claude/settings.json(共有プロジェクト設定、gitでコミットしてチームに配る想定)に書けばそのリポジトリを使うメンバー全員に、.claude/settings.local.json(プロジェクトローカル設定)に書けば自分だけ・このリポジトリだけに適用されます。公式ドキュメントが示す優先順位は、managed settings・コマンドライン(--settings)・プロジェクトローカル設定・共有プロジェクト設定・ユーザー設定の順です。組織としてgit pushの確認を誰にも外させたくない場合は、ユーザー側の設定では上書きされないmanaged settingsにaskルールを置く必要があります。
今回の変更で確認が省略されるのは、git pushについてaskやdenyを明示していない、権限ルールが既定のままの状態に限られます。settings.jsonの権限ルールの書き方全般はClaude Code settings.json完全ガイドにまとめています。
pushの自動許可対象が広がるということは、確認なしで書き込まれるリモートの数が増えるということでもあります。forkからのコントリビュートで、自分のforkだけでなくupstream側にも書き込み権限を持っているような構成では、remote.pushDefaultの設定先を意図せず取り違えると、想定していないリモートへ確認なしでpushが進む可能性はゼロではありません。remote.pushDefaultを設定するときは、その値が指すリモートが本当にpushしたい先かどうかを、git remote -vで見比べておくと安全です。
Claude Codeの権限システムには、ユーザーが承認しても解除されないハードコードされたブロックも別に存在します。worktree隔離下のセッションがmain checkoutへgit -Cでリダイレクトする操作は、PreToolUseフックで承認しても拒否されたままです。詳しくはClaude Codeのworktreeはmainへの読み取り専用gitも拒否するで扱っています。今回の/commit-push-prの変更はこれとは逆方向で、確認を求めていた操作を自動許可へ広げるものです。
/commit-push-prの自動承認は両方向に調整されている
push先を広げたv2.1.206のあと、/commit-push-prは別のリリースで自動承認の範囲を絞る変更も受けています。CHANGELOG.mdのv2.1.229には次の1文が記載されています。
Changed
/commit-push-prso 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など危険フラグを含むものは自動承認の対象外になった)
| バージョン | /commit-push-prの自動承認に関する変更 |
|---|---|
| v2.1.206 | /commit-push-prの自動承認に関する変更git pushの自動許可先に、origin以外の設定済みpushリモートを追加 |
| v2.1.229 | /commit-push-prの自動承認に関する変更--force・--amend・--no-verifyなど危険フラグ付きのgit/ghコマンドを自動承認の対象外に変更 |
v2.1.206はpushできるリモートの種類を増やす方向の調整でした。v2.1.229では逆に、同じ/commit-push-prが発行するgit・ghコマンドのうち、--forceのような取り消しにくい操作や--no-verifyのようにフックを迂回する操作を自動承認から外しています。対象範囲を広げる調整と、リスクの高い操作を切り分けて絞る調整が、同じスキルの中で別々に進んでいます。取り消しやすいpush先を増やす調整と、取り消しにくい操作を絞る調整は、どちらも「確認疲れを減らしつつ危険な操作だけは確認を残す」という同じ方向を向いた変更です。
影響を受ける利用形態の早見表
同じ/commit-push-prでも、リモートの構成と権限ルールの設定次第で今回の変更の効き方は変わります。自分のリポジトリがどの行に当てはまるかは、git remote -vと.claude/settings.json・.claude/settings.local.json・~/.claude/settings.jsonのいずれかにあるpermissions.ask・permissions.denyを見れば判断できます。CI環境や無人の自動化パイプラインでClaude Codeを動かしている場合も判断基準は同じで、人が都度確認できない分、事前にどのリモートまで確認なしでpushされるかを把握しておく価値が大きくなります。
| 利用形態 | 影響 |
|---|---|
pushリモートがoriginのみ | 影響変化なし。従来どおりoriginへのpushが自動許可の対象 |
remote.pushDefaultをfork・upstream等に設定済み | 影響確認なしで進む対象がそのリモートまで拡大 |
複数リモートを使うがremote.pushDefault未設定 | 影響origin以外は引き続き自動許可の対象外 |
settings.jsonでgit pushをask・denyに指定済み | 影響変化なし。既存ルールが自動許可より先に評価される |
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のような別経路の認可制限であることのほうが多くなります。
まとめ
/commit-push-prはv2.1.206から、origin以外に設定したremote.pushDefault、または唯一のリモートへのgit pushも自動許可するようになりました。対象はこのスキル経由のpushに限られ、settings.jsonでgit pushをaskやdenyに指定していれば、従来どおり確認や拒否が優先されます。同じスキルはその後のv2.1.229で、--forceのような危険フラグ付きのコマンドを自動承認から外しており、pushの対象範囲を広げる一方でリスクの高い操作は別に絞り込む調整が続いています。自分の環境がどちらの挙動になるかは、git config --get remote.pushDefaultの結果と、~/.claude/settings.json・プロジェクトの.claude/settings.json・.claude/settings.local.jsonに設定した権限ルールを順に確認すれば判断できます。