One Day My Push Had an Extra Destination — Guarding Against /commit-push-pr Pushing to Remotes Beyond origin

How Push Targets Grow Without You Noticing

The paths by which a push gains a destination are fairly predictable. In rough order of how easily a personal developer trips over them:

1. A backup mirror registration — you added mirror to keep a copy on another service, but you also set a pushurl, making it writable.
2. Pulling in an upstream fork — you registered upstream meaning it to be fetch-only, yet its push URL is not empty and gets picked up as a target.
3. A leftover test remote — you pushed to another environment once, forgot to git remote remove, and the registration lingers.

Every one of these is a remote added "to read" or "left behind," with no malice and no awareness of a mistake. That is precisely why, when the command widens its scope, the push lands quietly. The goal is not to delete every remote. Keep reference remotes as references, and restrict pushes to an allowed set. Draw that line, and you keep the convenience while removing the accident.

Three Layers to Stop an Unintended Push

One layer is not enough. I think in three.

The first layer is the inventory. Use the commands above to surface every remote you can push to, and strip any pushurl you did not intend. For read-only remotes, you can also assign an invalid push URL to seal off writes.

The second layer is the hook. An inventory goes stale after a single pass, so you insert something that mechanically checks against an allowlist on every push. That is the heart of this piece.

The third layer is a pre-run check. Unattended runs cannot use interactive confirmation, so log which remotes the config allows pushing to at the very start of the job. Later, reading the log, you can verify the destination was what you expected.

Block Off-Allowlist Remotes With a pre-push Hook

The pre-push hook fires just before a push actually goes to the network, and if it exits non-zero, the push itself aborts. Put an allowlist check here and, even when the command widens the destination, you hold the last line.

First, the bare state before the hook. Any remote passes straight through.

# Before: no hook. Every remote /commit-push-pr targets gets pushed as-is
$ git push mirror main
# → reaches backup.example with no confirmation

With the hook in place, remote names not on the allowlist are rejected. Drop this in .git/hooks/pre-push and make it executable. Git passes the target remote name as the first argument.

#!/usr/bin/env bash
# .git/hooks/pre-push
# Only let pushes through to allowed remotes; abort otherwise.
set -euo pipefail
 
ALLOWED="origin"          # space-separated for multiple: "origin release"
remote_name="$1"          # the push target remote name
 
is_allowed=0
for r in $ALLOWED; do
  if [ "$remote_name" = "$r" ]; then
    is_allowed=1
    break
  fi
done
 
if [ "$is_allowed" -ne 1 ]; then
  echo "pre-push: blocked push to '$remote_name' (allowed: $ALLOWED)" >&2
  echo "pre-push: add it to ALLOWED only if you truly intend to push there" >&2
  exit 1
fi
 
exit 0

$ chmod +x .git/hooks/pre-push
# After: a push to a non-allowed remote is aborted by the hook
$ git push mirror main
pre-push: blocked push to 'mirror' (allowed: origin)
error: failed to push some refs to '...'

The strength of this approach is that whatever remotes /commit-push-pr targets internally, you hold the final exit in one place. If the command's behavior shifts again later, the judgment — the allowlist — stays on your side. There is one pitfall. .git/hooks is not included in a clone, so the hook is lost every time you re-clone the repository. In a setup that pushes from disposable clones at night, that gap turned into a real incident in production for me. As a countermeasure, I recommend folding the hook placement into your pre-push routine right after cloning. Pointing core.hooksPath at a shared directory and keeping the hook body under version control works well too.

Notes for Unattended and Scheduled Runs

In an interactive session, an extra destination leaves room to notice — "wait, that's one target too many." An unattended run has no such room. The confirmation prompt either does not appear or has no one to answer it. That is exactly why the correctness of the target has to be guaranteed structurally, before the run.

What I keep as a habit is stamping the "remotes I could push to" into the log at the very start of the job.

echo "== push targets check =="
git config --get remote.pushDefault || echo "pushDefault: (none, origin)"
git remote -v | awk '$3=="(push)"{print $1, $2}'

Those few lines let you confirm at a glance, when you read the log later, whether the destination really was only origin. The hook is the first barrier; this log is a second visual check. If one goes stale, the other remains.

Confirm the Hook Actually Fires

Once you add a guard, confirming the guard works is part of the same job. A hook that does not fire can be worse than none, precisely because you believe it is there. To exercise only the hook's decision without pushing anything to the network, invoke a dry-run against a throwaway branch ref.

#!/usr/bin/env bash
# verify-prepush.sh — check the pre-push hook rejects off-allowlist remotes
set -uo pipefail
 
check() {
  local remote="$1" expect="$2"
  # never sends; only triggers the hook's decision
  git push --dry-run "$remote" HEAD:refs/heads/__hook_probe__ >/dev/null 2>&1
  local code=$?
  if [ "$expect" = "allow" ] && [ "$code" -eq 0 ]; then
    echo "OK  $remote was allowed"
  elif [ "$expect" = "block" ] && [ "$code" -ne 0 ]; then
    echo "OK  $remote was blocked by the hook"
  else
    echo "NG  $remote expected=$expect actual_code=$code" >&2
    return 1
  fi
}
 
check origin allow
check mirror block

If origin passes and mirror stops as expected, the hook is doing its job. Because of --dry-run, the check itself never dirties a real remote. I personally run this once whenever I change the hook and whenever I change how the clone workflow runs. Feeling reassured by adding a guard and confirming the guard fires are two different things.

Wrapping Up

The change that made /commit-push-pr target push remotes beyond origin is nothing to worry about on a single remote. But if you keep even a second remote, your push destination can grow from the moment you register it. As a next step, inventory git remote -v and your push-related config once, and check for any pushurl you did not intend. If even one unfamiliar destination turns up, the pre-push hook in this article earns its place. I hope it helps in your own setup — thank you for reading.