Allow us to block Copilot-generated issues (and PRs) from our own repositories

[mcclure]

Select Topic Area

Product Feedback

Feature Area

Issues

Body

I find the following two news items on the front page:

https://github.blog/changelog/2025-05-19-creating-issues-with-copilot-on-github-com-is-in-public-preview/

https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview/

This says to me that github will soon start allowing github users to submit issues which they did not write themselves and were machine-generated. I would consider these issues/PRs to be both a waste of my time and a violation of my projects' code of conduct¹. Filtering out AI-generated issues/PRs will become an additional burden for me as a maintainer, wasting not only my time, but also the time of the issue submitters (who generated "AI" content I will not respond to), as well as the time of your server (which had to prepare a response I will close without response).

As I am not the only person on this website with "AI"-hostile beliefs, the most straightforward way to avoid wasting a lot of effort by literally everyone is if Github allowed accounts/repositories to have a checkbox or something blocking use of built-in Copilot tools on designated repos/all repos on the account. If we are not granted these tools, and "AI" junk submissions become a problem, I may be forced to take drastic actions such as closing issues and PRs on my repos entirely, and moving issue hosting to sites such as Codeberg which do not have these maintainer-hostile tools built directly into the website.

Note: Because it appears that both issues and PRs written this way are posted by the "copilot" bot, a straightforward way to implement this would be if users could simply block the "copilot" bot. In my testing, it appears that you have special-cased "copilot" so that it is exempt from the block feature.

So you could satisfy my feature request by just not doing that.

¹ i don't at this time have codes of conduct on all my projects, but i will now be adding them for purposes of barring "AI"-generated submissions

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[SwiftScriptr]

Agreed. It should be, at the very least, opt-out.

Oh... Now here's where the lazy/fatigued people will use this to their advantage, these feautures don't only create Issues, but systemically close off and Ignoor older ones.

It's one thing to be ghosted in need of help as a user of many projects (that you want to acknowledge as useful and share) but it's anoher to 'rub salt in the wounds' of personal issues that get closed by bot!!!

Encouraging less human interaction is their M.O. IMO, SMH. (＃`Д´)

[eli-schwartz]

It has always been possible to use a stale-bot to disrespect users by closing their issues automatically on a timer. It doesn't incorporate a Large Language Model.

Nor does an automated form response involve a Large Language Model.

I do agree with you that their M.O. is clearly to encourage less human interaction though. :)

[mschilli87]

@corysimmons: pong 😉

[i-am-called-glitchy]

gotta use copilot to create a bot to autodeny copilot

[i-am-called-glitchy]

Feels like no one "reads the room" with these AI tools.

im 99% sure they do, but managers are just hyped and they demand AI.

[blryface]

peak

[charabaruk]

Yeah @i-am-called-glitchy called it being a management issue.

Our head of development wants us to go all-in on "AI" nonsense and I just want to smash my computer every time it's come up.

[SwiftScriptr]

Feels like no one "reads the room" with these AI tools.

(Myself) Speaking up for project users and not necessarily creators: Publically they (github) claim the main benefits but leave out the 'uno reverse' where the bots can close issues, pre-existing from it's system wide deployment, from users of the repo.

I rather propper etiquette and communication than the owners/creators using your AI Messenger buddy to 'dump' your concerns/issues for you without a thought of a supporters feelings, this has happened in the same android/phone based repos I'm involved in, active use for potential OS porting/development (google free ofcourse).

[Anonymous941]

Shareholders hear about AI, become convinced that (insert product here) needs more AI features, then the managers tell the developers to make it. They have to make something related to AI, even if the developers know it's completely useless or actively harmful (and this "feature" is both). Ultimately the motivation is profit, not actually making a good product.

Letting you block it would cause less people to use it, which means less impressive graphs to show off at the next meeting.

Also, Codeberg is always an option, you get free unlimited storage/private repos, and avoid the constant corporate nonsense like this that plagues GitHub...

[randomairborne]

I think there may be a editing error in your second full body paragraph- you suggest that the easiest way to waste everyone's time would be adding features to disable the waste of dev time that is Copilot PRs

[randomairborne]

this seems to be fixed

[peshala-prabhapoorna]

Repo owners must have control over when and where they use AI in the repo.

[pasabanov]

By the way, they can use all of your public (and possibly private) code you upload to GitHub to train their Copilot, regardless of your license restrictions, because this is stated in their Terms of Service!
Truly an evil and shitty move.

[tkreuzer]

If you don't want your code to be read (by an AI or human or monkey), don't put it on GitHub.

[RivenSkaye]

If you don't want your code to be read (by an AI or human or monkey), don't put it on GitHub.

It's not about it being read, it's about it being included in large datasets without consent, and about AI being used to generate complete issues and PRs. Codeberg and Sourcehut respect people not wanting that, and so should MS

[Pray4Love1]

I love the hate AI gets, just because you don't know how to use it doesn't mean you have to neglect what's never going away.. Feels like 1920 all over again but with AI... I dare anyone to give me any issue, any Protocol.

[Zannick]

I went to github.com/copilot (i.e. a user page) to see if I could block the user from there, and the GET request opted me into Copilot--or at least attempted to, since it gave me an error, and also a banner I had trouble getting rid of.

Your GitHub Copilot setup is incomplete. Please go to your settings page and complete your setup. [GitHub Copilot Setup button]

And in my settings page under Copilot Features, I had an initial issue where the page rejected my attempts to set Anthropic Claude and Google Gemini to "Disabled". It appears to work now having closed the tab and opened a new one, but that was alarming to see... Still, two entries in that settings page are locked at Enabled, so it is impossible to disable "Copilot in GitHub.com" and "Copilot in GitHub Desktop", despite "Show Copilot" being disabled and helpfully hiding all the UI elements that had shown up.

[Jackenmen]

FYI, this only applies to PRs created by their agent (when you assign Copilot to an issue - only available through the more expensive Copilot Pro+ plan, not the tier that is provided to maintainers of popular projects and stuednt), not when a user creates a PR with the help of Copilot through prompts and PRs the finished work.

Separately, for reviews (when you request a review from Copilot), copilot-pull-request-reviewer[bot] is used. There might be other users as well.

[mcclure]

Interesting, thanks.

In my testing, I was able to block copilot-swe-agent but not copilot-pull-request-reviewer. I wonder if it's possible both bots are a special system construct, and some random github user coincidentally made an account named copilot-swe-agent on March 14.

[f]

Interesting, thanks.

In my testing, I was able to block copilot-swe-agent but not copilot-pull-request-reviewer. I wonder if it's possible both bots are a special system construct, and some random github user coincidentally made an account named copilot-swe-agent on March 14.

If so, it's a bug. Because when I click onto the username on logs, it redirects to the profile.

[mcclure]

Ah, yeah, I don't think a bug would do that!

[CanadianBaconBoi]

Sorry for the necro, at this point it seems copilot-pull-request-reviewer has been converted to an organization, thus not blockable.

[hidde]

Please consider making this opt in, so that org and/or repository owners can have a choice.

Or, if that's really not feasible, could there be an option to opt out?

[tukkek]

So you're telling me that JEP 369: Migrate to GitHub, which has been delivered was not about migrating to Git Hub? Cool story. They do use a dual-setup with bridges, which has now proven to have been an extremely smart choice.

You can try to nit-pick but it won't change my actual argument: there's reasons why for every self-hosted top-project, there's 1,000 others on GH. You can read many of these reasons on the aforementioned JEP, which I'll link to again for your convenience: https://openjdk.org/jeps/369.

[robrwo]

Self-hosting is not an option for everyone.

People do not self-host for the same reason that they do not grow their own food, build their own houses, or sew their own clothes: they do not have the time, resources or even skills to do this as well as professionals.

[eli-schwartz]

So you're telling me that JEP 369: Migrate to GitHub, which has been delivered was not about migrating to Git Hub? Cool story. They do use a dual-setup with bridges, which has now proven to have been an extremely smart choice.

That is correct, you can read all about how it was not about migrating to GitHub in the section:

Motivation

The motivation for this JEP is split into two sections. First we cover why it would benefit the OpenJDK Community to make use of an external source-code hosting provider, and then we explain why GitHub is the best choice of provider at this time.

"At this time" should be a dead giveaway.

[eli-schwartz]

Self-hosting is not an option for everyone.

People do not self-host for the same reason that they do not grow their own food, build their own houses, or sew their own clothes: they do not have the time, resources or even skills to do this as well as professionals.

Cool story.

Perhaps you may have noticed that I agree with you, and the current conversation is actually about whether self-hosting is a valid option for a minority group of professionals with funding?

[Layoric]

Self-hosting is not an option for everyone.

People do not self-host for the same reason that they do not grow their own food, build their own houses, or sew their own clothes: they do not have the time, resources or even skills to do this as well as professionals.

Right, but a lot of people here do have those skills, and supporting OSS with resources and skills that others can provide or pool is perhaps a more sustainable long term than people think. Eg, Codeberg for repository hosting, and sharing compute for runners for those that have those resources, donating to help fund where able etc, skills to help people setup. Currently sharing runners is a bit cumbersome, but that could be something Codeberg or others could change. Myself and other homelabbers I'm sure would be willing to donate compute, or skills.

[shakna-israel]

Legal advice often begs and commands that software is not exposed to the untested minefield that is AI. If a worker is not allowed to expose the code to AI... It'll be a hell of a day in the office if the entire org's is suddenly fair game.

[ell1e]

https://github.com/orgs/community/discussions/148571 Also see here for the legal concerns discussion. Unsurprisingly, Github hasn't responded yet.

[derakon]

Here's the predictable result of this change: every single repository that a) is open, and b) is remotely large, is going to get DDOS'd by people submitting genAI issues against it. As a consequence, they will have to close the issue tracker, which will hurt GitHub.

I understand that y'all are being told by your superiors to add genAI everywhere, and that you need to keep your jobs. Help us keep ours as well, by giving us the tools to stem the ongoing flood.