O GitHub anunciou em 29 de junho que GitHub Issues passou a permitir uma restrição permanente para criação de issues somente por colaboradores com acesso de escrita. A nota no GitHub Changelog posiciona o recurso como um controle para reduzir criação indesejada de issues sem desligar completamente o fluxo de acompanhamento do projeto.
Quando a opção está ativa, pessoas sem permissão de escrita não conseguem criar issues a partir dos principais pontos da experiência do repositório, incluindo Issues, comentários, Discussions, Projects e Copilot. A mudança aproxima a política de issues da restrição já existente para abertura de pull requests por colaboradores, criando uma regra mais previsível para projetos que precisam controlar entrada de demanda.
A documentação do GitHub registra o caminho de configuração em Settings, dentro da área de Features e Issues. Em repositórios pessoais, colaborador é quem foi convidado para o repositório. Em organizações, a documentação vincula a regra a papéis com write, maintain ou admin.
Por que não é só botão anti-spam
O efeito prático da restrição depende do tipo de projeto. Em um repositório usado por uma equipe fechada, limitar GitHub Issues a colaboradores pode reduzir ruído operacional, reports duplicados e entradas fora de processo. Em um projeto open source, a mesma decisão pode cortar relatos legítimos de usuários externos, especialmente quando issues são o canal principal para bug reports e suporte.
Por isso, a configuração não deve ser tratada como substituta de triagem. Ela é um controle de entrada. Se o projeto continua querendo receber sinais públicos, pode precisar manter Discussions aberto, usar formulários externos, documentar canais de segurança ou separar repositórios de código e suporte. O post sobre issue, discussão ou tarefa ajuda a organizar essa escolha porque nem toda conversa precisa nascer no mesmo lugar.
O que muda para mantenedores
Para mantenedores, a novidade cria uma resposta mais simples a períodos de abuso, campanhas coordenadas, spam de IA ou abertura repetida de issues de baixa qualidade. Antes, o caminho mais direto podia ser desligar Issues, aplicar limites temporários de interação ou depender de triagem manual. Agora existe uma opção específica para preservar a área de trabalho dos colaboradores.
O ganho aparece principalmente em repositórios que já possuem uma fronteira clara entre equipe mantenedora e público externo. Espelhos, SDKs internos abertos por transparência, projetos com suporte pago em outro canal e repositórios de infraestrutura podem se beneficiar mais do que comunidades que dependem de contribuição ampla.
Relação com automação e Copilot
A inclusão de Copilot na lista de pontos afetados merece atenção. Se uma integração ou fluxo assistido por IA tenta transformar uma conversa em issue, a regra de permissão ainda precisa ser respeitada. Isso reforça uma tendência já vista no controle de disparo do GitHub Actions: automação útil em plataforma de desenvolvimento precisa obedecer ao mesmo modelo de permissão que vale para pessoas.
Para times que adotam agentes de código, esse detalhe evita uma armadilha comum. Uma ferramenta não deve abrir demanda, alterar escopo ou criar artefato de projeto em nome de alguém sem autorização adequada. A restrição de issues é uma pequena peça de governança, mas ajuda a deixar explícito quem pode criar trabalho novo dentro do repositório.
Quando usar a restrição
A decisão faz sentido quando o repositório sofre com volume indesejado ou quando a organização já definiu outro canal de entrada para usuários externos. Também pode funcionar em janelas críticas de release, períodos de manutenção ou projetos em que issues representam trabalho interno, não atendimento público.
Antes de ativar, vale revisar README, templates, política de segurança e canais de suporte. Usuários sem acesso de escrita precisam saber onde reportar vulnerabilidades, bugs reais ou dúvidas. Sem essa sinalização, a restrição melhora a fila de quem mantém o código, mas piora a experiência de quem tenta colaborar.
Em GitHub Issues, permissão de criação agora pode ser uma escolha explícita de governança do repositório. O ajuste é pequeno na interface, mas afeta como uma equipe define fronteira entre colaboração aberta, manutenção controlada e automação dentro do projeto.
