An existing origin is a saved remote configuration, not a failed push. Inspect its destinations, then either change that remote URL or keep it and add a second name. Do not remove the old remote just to make an add command succeed.
Reproduce the boundary in a disposable fixture
Inspect fetch and push destinations before changing an existing remote name.
Use a new empty temporary directory for this fixture. The example creates only local test data. Commands marked with example.invalid do not identify a real service.
git init -q demo
cd demo
git remote add origin https://example.invalid/old.git
if git remote add origin https://example.invalid/new.git 2>error.txt; then exit 1; fi
git remote get-url --all origin
git remote set-url origin https://example.invalid/new.git
git remote get-url --all origin
git remote get-url --push --all origin
git remote add upstream https://example.invalid/old.git
git remote -vObserved result
https://example.invalid/old.git
https://example.invalid/new.git
https://example.invalid/new.git
origin https://example.invalid/new.git (fetch)
origin https://example.invalid/new.git (push)
upstream https://example.invalid/old.git (fetch)
upstream https://example.invalid/old.git (push)What the result means
This fixture configures names only; it never contacts either example address. The second add fails because origin is already taken. set-url changes the existing entry, while upstream preserves a separate route to the original location. Neither operation uploads commits. The failure therefore says nothing about remote permissions, branch protection or whether your intended repository is empty.
Choose the correction for your workflow
In the real checkout, first run git remote -v and both get-url commands shown above. Decide whether origin should represent the new destination. If yes, record the old URLs and use set-url with the exact repository address you intend to use. If you still need the original, a separate remote name can make the two workflows clearer. Read the resulting fetch and push URLs again before any push. When a remote has explicit push URLs or multiple URLs, inspect all of them rather than assuming the displayed fetch address controls every push.
Limits and the next check
Changing a URL does not grant access or reconcile histories. If a subsequent push fails, inspect that new error independently. Do not put tokens in example URLs or publish a remote listing that contains embedded credentials. Removing and re-adding a remote can discard useful configuration, so changing a single address is usually easier to review. This guide does not perform a push or fix authentication.
Related: Compare the related workflow boundary.
This isolated example was executed on macOS on November 10, 2026 (KST). Available tools: node v26.5.0, git git version 2.39.3 (Apple Git-145), npm 11.17.0, jq jq-1.7.1-apple. Shell fixtures use Bash and repository-path identity uses Python 3. This checks the illustrated contract, not your project, host service or every tool version.