{"version":"2.1.268","anchor":"push-default-remote-detection-now-returns-multiple-candidate","canonical_anchor":"push-default-remote-detection-now-returns-multiple-candidate","heading":"Push-default remote detection now returns multiple candidate remotes","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/push-default-remote-detection-now-returns-multiple-candidate","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Push-default remote detection now returns multiple candidate remotes\n\nGit push permission rules can now include both origin and a custom pushDefault remote at once\n\n**What**\n\nWhen Claude Code figures out which git remotes to grant push permission for (so it can suggest a rule like `git push origin *`), it now returns multiple candidate remotes instead of picking just one. It includes `origin` when present, plus whatever remote is configured as `remote.pushDefault`, as long as that name fits an expected naming pattern.\n\n**Why**\n\nRepos that push to both `origin` and a separate configured push remote (like a fork or an upstream) now get permission rules covering both, instead of Claude Code having to choose only one and potentially still prompting for the other.\n\n- Area: Elsewhere\n- Names: `remote.pushDefault`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}