Feature Limitation: Copilot Agent can only operate from the default branch (e.g., main)

[krackinDev]

Select Topic Area

Product Feedback

Copilot Feature Area

Copilot Agent Mode

Body

GitHub Copilot's restriction to the default branch makes it incompatible with real-world, branch-based workflows. This limits its usefulness as a true AI pair programmer and undermines its value in dynamic development environments. Allowing context from the active feature branch is essential for Copilot to be collaborative, accurate, and productive.

using the docs here this line of text really stopped me before even beginning

Copilot will always start its changes from the repository's default branch. Copilot cannot branch off from any other branch—for example, a feature branch or a release branch.

The restriction breaks the core utility of Copilot as an AI pair programmer. As an engineer actively working in a feature branch, I need Copilot to: Understand the local committed changes I’ve made and say i want it to
Refactor or generate code based on new or modified classes that don’t exist in main.
Avoid conflicts or rework due to misaligned branch context.

Since Copilot always pulls context from main, it's effectively blind to:
Unmerged changes
Branch-specific logic
Work-in-progress architecture

Who would benefit from fixing this
Any developer using GitHub Copilot for real-time development as a "PAIR" programmer, especially in fast-moving teams or when doing POCs, spikes, or experiments.
Teams that follow GitFlow, trunk-based development, or work with release branches.
Anyone who wants to use Copilot as a collaborator in an iterative, context-aware development cycle.

Copilot should allow the user to choose or specify the source branch from which context is derived, or default to the main branch.

Example Use Case
I'm working on a feature branch feature/ai-rule-validation where I've started building out new domain entities and rewriting an old service into utilizing AI to . I want to assign Copilot Agent to :
"Refactor OldService to use a factory pattern and move initialization logic into ServiceFactories.
Refactor the service using SOLID design principles
Build tests to verify the isolated functionality"
so that i can focus on the next set of features I'm working on. This feature branch may or may not be pulled into our main branch depending on whether it is successful and useful and cost effective , which we will only know later
But since Copilot only sees main, it:
Misses new class definitions
Suggests changes that don’t compile in my current state
Ignores architectural shifts I’ve made in the branch
This turns Copilot into a standalone engineer, not a pair programmer, and forces me to reconcile context manually.

[Akash1134]

Hi @krackinDev ,

Thank you for sharing this valuable feedback about GitHub Copilot Agent. You've highlighted an important limitation that impacts real-world development workflows, and your detailed explanation helps us understand the practical implications of this restriction.

Understanding the Current Limitation

You're absolutely right that Copilot Agent's current limitation of only operating from the default branch creates challenges for developers following standard branch-based workflows. As stated in the documentation:

Copilot will always start its changes from the repository's default branch. Copilot cannot branch off from any other branch—for example, a feature branch or a release branch.

This does indeed create friction for developers like yourself who are working on feature branches with new or modified code that doesn't exist in the main branch yet, particularly when:

• Working with unmerged changes
• Implementing branch-specific logic
• Developing work-in-progress architecture
• Building experimental features that may or may not be merged later

Why This Matters

The limitation undermines Copilot's potential as a true pair programmer since it lacks awareness of your current development context. Real-world software development rarely happens directly on the main branch - developers typically work in feature branches that may contain significant changes from the default branch.

Your example of working on a feature branch with AI rule validation, where you want Copilot Agent to help refactor services and build tests, perfectly illustrates how this limitation prevents Copilot from being fully effective as a collaborator in iterative development.

Potential Improvements

Based on your feedback, these approaches would make Copilot Agent more useful:

1. Allow users to specify which branch provides the context for Copilot Agent
2. Have Copilot Agent automatically detect and use the current active branch
3. Provide an option to merge temporary changes from feature branches into Copilot's working environment

What's Next

I've documented your feedback, which will be reviewed by our product team. While we can't guarantee immediate changes, feedback like yours is essential for improving GitHub Copilot and prioritizing enhancements.

In the meantime, you may want to consider:

• Creating a minimal set of changes on your feature branch that you absolutely need for Copilot Agent to be aware of, and temporarily merging these into your default branch (if possible)
• Using GitHub Copilot Chat instead of the Agent for specific tasks within your feature branch, as it has better contextual awareness of your current working files

Thank you for taking the time to provide this detailed feedback. Thoughtful reports like yours help us make GitHub Copilot more useful for real-world development scenarios.

[colin-srsbsns]

"1. Allow users to specify which branch provides the context for Copilot Agent" - would be the winner in my book.

[smkelly2]

Since it's driven by Issue assignment, why doesn't Issue support identifying which branch the issue was observed on? It's common in my team's workflow that issues seen in production (main) are entirely different from those seen in pre-production (stage/dev) using GitFlow. If I want the tool to fix the Issue for me, I need to be able to specify in which lifecycle stage/branch the Issue was observed in. I was tempted to just add this information to the Issue description in hopes that Copilot would cue up with that context, but per the above thread, it seems this is not possible.

[mathiaswillburger]

+1

I agree, this is really important - especially for teams using Gitflow-based branching scenarios. In those cases, the main branch can be quite far from develop until the next release. That means the independent Copilot Agent is starting from a codebase that's not really accurate for the current work. Really hope this gets improved soon!

[mlanning]

Thank you so much for bringing this up. I just started working with Coding Agent last night and was really stuck on this. I thought that surely someone else has run into this—it's imperative for most, if not all, workflows.

I agree, this limitation is pretty significant for teams that use a branching strategy where main isn't the primary development branch. As a temporary workaround, you can set your default branch to develop (or whichever branch you want Coding Agent to branch from). This way, new branches and pull requests generated by the agent will start from the correct base. It's not ideal, especially if you rely on main as your release branch, but it does help keep your workflow consistent until a more flexible solution is available.

Hopefully, GitHub will address this soon and allow us to specify a base branch for Coding Agent actions. In the meantime, switching the default branch is a practical workaround for teams with similar needs.

[mathiaswillburger]

Thanks for pointing out the workaround @mlanning . At least that helps in the meanwhile to be closer to the actual development status than branching from main.

[programcsharp]

This (and much more) could be handled by evaluating instructions at branch time gen. I'd like to be able to specify the source branch and I'd also like to be able to specify branch naming.

If copilot evaluated .github/copilot-instructions.md when generating a branch and followed them, or had a separate branch gen instructions. that would cleanly solve the problem.

It would also be great to evaluate the issue description for branch instructions at time of branch gen as that would allow following specific instructions there. We sometimes start a feature branch off another feature branch given a dependency. We also sometimes do scaffolding work in a branch first before letting the agent loose.

Instructions that would be useful to handle in copilot instructions:

• "start from the develop branch"
• "name the branch <issue-number>-short-branch-description

Instructions that would be useful to handle in issue instructions::

• "start from the 56789-feature branch"
• "work in the 12345-feature branch -- i've added some initial scaffolding"

[JohnVottero]

+1

This is really important. I tried created a branch for an issue before I assigned the issue to Copilot and Copilot ignored that branch.

For us, this is a showstopper for most issues.

[chris-cheshire]

• 1

Agreed, we cannot use this in production until we can select branch which makes it a showstopper

[krackinDev]

Can we get an update on this @Akash1134 ? can we expect a resolution? this seems like a big flaw

[75py]

I found a workaround for specifying a base branch when using GitHub Copilot Coding Agent.

Workaround Steps:

1. Open GitHub Copilot Chat
2. Attach the target repository
3. Specify your instructions along with the base branch like this:
   @github Please create a PR from branch 'feature-sample' that [your task description]
4. Allow the permissions when prompted

This method allows the Coding Agent to create a PR from your specified branch instead of the default branch.

Here's the relevant documentation: https://docs.github.com/en/copilot/how-tos/agents/copilot-coding-agent/asking-copilot-to-create-a-pull-request

Important Note:

While this workaround helps, I strongly believe this functionality should be implemented as a standard feature. For teams using git-flow or other branching strategies, being able to specify the base branch directly through Issues (maybe via labels or special syntax) would be much more intuitive and efficient.

Please GitHub team, consider implementing this as a native feature! 🙏

Hope this helps others facing the same challenge!

[larryeby]

I would love to see this. It is a limitation I’ve come across as well and I’ve had to manually pull down the branch, rebase and make big adjustments to the code due to this a few times already.

+1 to the idea of adding the target branch directly to the issue. This solves multiple problems at once since it also allows teams to track issues across branches better in non-AI workflows as well.

[clong-viimed]

I've recently started to use this feature too and it wasn't until copilot was telling me that it couldn't find the files that I was asking for it to update that were in the branch that I had specified in my request, did I then realize that it was creating it's PR from the main branch which was irrelevant to the task at hand.

[Viir]

@larryeby @clong-viimed does this way of selecting a branch work for you?

[larryeby]

This works for a one-person team, but isn’t really a scalable option. I wouldn’t say no to having this as a stop gap if it’s easy to include since it is much better than nothing at all.

Ideally, a GitHub issue would have a drop-down for the target branch and copilot could use that.

I think that also has the added benefit of setting more context for human developers as well as AI agents, so it’s kind of a win-win if the target branch is directly set on the GitHub Issue we would assign to the agent.

[larryeby]

I also think @JohnVottero’s suggestion of creating a branch based on the issue ID and copilot knowing to use that could work in the meantime as a workaround. It’s just a bit of extra overhead where we need to both create an issue and a branch before assigning it to copilot.

[JohnVottero]

No, that way of selecting a branch does not work for me. It is still too "global". We could have several feature branches in flight at any one time and we want to each issue that makes up the feature to branch off of that feature branch. If I create a branch for an issue and then assign the issue to Copilot I expect Copilot to use that branch.

…

On Thu, Jul 31, 2025 at 1:11 PM Michael Rätzel ***@***.***> wrote: @larryeby <https://github.com/larryeby> @clong-viimed <https://github.com/clong-viimed> does this way of selecting a branch work for you? image.png (view on web) <https://github.com/user-attachments/assets/ad4e0cfa-a6e3-4649-b2f3-ee7c080b1a6f> — Reply to this email directly, view it on GitHub <#159836 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARNZOCJHQ5SDZT25HCHVR6L3LJE4HAVCNFSM6AAAAAB5RD7SK2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJVGAYTSMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mike-williams-nlplogix]

This issue is definitely a showstopper for us.

I want to be able to assign an issue directly to copilot without having to create a branch or go to the agents screen to tell it which branch to use.

I've tried referencing the branch in the issue description, adding comments to tell it which branch to use, and actually associating the issue with the branch I want it to work from. None of which work.

The fact that copilot straight-up ignores the branch associated with the issue is maddening.