Radar Dev

GitHub vai pedir login para clonar repositórios públicos? Entenda a mudança

O GitHub anunciou uma proteção que pode exigir login em alguns clones e fetches por HTTPS durante tráfego incomum. Entenda quem pode ser afetado e como autenticar com segurança.

Por Equipe Central Stack20/10/20265 minRadar Dev
GitHubGitHTTPSautenticaçãodesenvolvimento

Compartilhar

Envie este conteúdo para sua rede ou salve o link para publicar depois.

Pessoa desenvolvedora trabalhando com código em um computador e notebook.
Foto: Mikhail Fesenko / Pexels

Para quem esse aviso pode fazer diferença?

O aviso interessa a quem baixa ou atualiza repositórios públicos do GitHub por HTTPS, especialmente em scripts, máquinas novas e serviços de integração contínua. Se o comando git clone ou git fetch começou a pedir usuário e senha, a mensagem pode estar relacionada a uma proteção temporária anunciada pelo GitHub.

Isso não quer dizer que todos os repositórios públicos passaram a exigir uma conta. A mudança pode atingir operações sem autenticação quando o GitHub identifica tráfego incomum, e uma tentativa legítima também pode ser confundida com atividade automatizada.

O GitHub não tornou privados os repositórios públicos: alguns clones e fetches por HTTPS podem receber um pedido temporário de autenticação.

O que o GitHub anunciou?

Em 19 de outubro de 2026, o GitHub informou que pode exigir autenticação para alguns clones e fetches de repositórios públicos feitos por HTTPS durante períodos de tráfego fora do normal. A empresa diz que aplica a proteção de forma limitada, usando sinais de atividade anômala, para ajudar a manter o serviço disponível.

Quando a operação é afetada, o Git devolve uma mensagem dizendo que é necessário autenticar. O GitHub recomenda entrar na conta e tentar novamente ou aguardar a retirada da proteção temporária. A medida vale para repositórios no GitHub.com, em todos os planos.

A mudança não afeta operações Git autenticadas por HTTPS, conexões SSH, envios de alterações com push nem o acesso comum ao site e à API. Ela também não substitui as permissões de cada repositório: um projeto privado continua exigindo acesso autorizado.

Como tentar novamente com segurança

Primeiro confira se o endereço do repositório está correto e se ele é realmente público. Se você usa HTTPS e ainda não autenticou o GitHub CLI naquela máquina, instale o aplicativo pela documentação oficial e entre na conta pelo navegador. A sequência abaixo configura o Git para usar essa credencial e confirma qual conta ficou ativa:

Terminal
gh auth login
gh auth setup-git
gh auth status
git clone https://github.com/PROPRIETARIO/REPOSITORIO.git

Durante o login, escolha GitHub.com e HTTPS e siga a confirmação que aparecer no navegador. Troque PROPRIETARIO e REPOSITORIO pelos nomes que aparecem no endereço do projeto. O comando setup-git configura o Git para usar as credenciais guardadas pelo GitHub CLI. Já auth status mostra a conta autenticada, para você conferir se não entrou em um perfil diferente do que pretendia.

Se o repositório já está no computador, entre na pasta dele e execute git fetch para buscar as atualizações. Para baixar somente uma vez, clone pela URL SSH se você já configurou uma chave no GitHub. Não publique uma chave privada, um token ou a senha da conta em um arquivo do projeto.

Como reconhecer a causa antes de trocar a configuração

Leia a mensagem completa que aparece no terminal. Se ela diz que a autenticação é necessária e você está tentando acessar um repositório público por HTTPS, o aviso do GitHub pode explicar o bloqueio temporário. Se a mensagem diz que o repositório não foi encontrado, confira também se o endereço está correto: esse retorno pode ocorrer quando a URL está errada ou quando a conta não tem permissão para ver um projeto privado.

Compare o resultado em mais de um lugar. Se o clone funciona no seu computador, mas falha só em um servidor de build, investigue as credenciais desse servidor. Se várias máquinas sem autenticação falham ao mesmo tempo, consulte o GitHub Status e tente novamente mais tarde. Esses sinais ajudam a evitar uma mudança de protocolo ou de permissões que não corrige o problema real.

O aviso não muda a visibilidade do repositório. Uma pessoa ainda pode abrir o projeto público no navegador e, em determinados momentos, receber o pedido de autenticação ao fazer uma operação Git anônima por HTTPS. A diferença é entre consultar uma página e executar uma transferência de dados pelo protocolo Git.

  • Só um computador falha: confira o gerenciador de credenciais e a conta ativa do GitHub CLI.
  • Só a automação falha: revise como o serviço de CI fornece credenciais ao Git.
  • O endereço retorna erro em qualquer lugar: confira proprietário, nome do repositório e se ele é público.
  • A falha começou durante um período de tráfego incomum: autentique e tente uma vez ou aguarde a proteção temporária terminar.

O que muda em automações e serviços de CI?

Uma rotina automática não consegue confirmar uma janela de login no navegador. Em um workflow do GitHub Actions, prefira o GITHUB_TOKEN fornecido ao próprio job para operações com repositórios. Em outro serviço de CI, o GitHub recomenda usar um token de instalação de GitHub App; um token pessoal deve ser a última opção e precisa ficar em um gerenciador de segredos.

Se a automação só precisa ler um repositório público e não consegue autenticar, o GitHub diz que ela pode tentar de novo depois que a proteção for removida. Antes disso, confira se o job realmente recebeu a credencial e se o acesso é somente de leitura. Uma mensagem de autenticação no log não significa que você deva tornar o repositório privado ou conceder permissão de escrita.

Evite repetir o comando em um ciclo apertado: muitas tentativas idênticas podem piorar o tráfego que acionou a proteção. Prefira uma nova tentativa com intervalo razoável e registre o erro original, o horário e o tipo de conexão usado. Essas informações ajudam a equipe a distinguir uma falha de credenciais de um bloqueio temporário.

Para scripts, uma credencial de curta duração e com o acesso mínimo necessário é mais segura do que gravar um token pessoal no código.

Quando o login não resolve

Confira a página oficial de status do GitHub e veja se Git Operations está operacional. Depois confirme se o endereço usa o proprietário e o nome corretos, se sua conta tem acesso quando o projeto é privado e se o gerenciador de credenciais está usando a conta esperada. Se sua empresa usa proxy ou espelho interno, consulte a equipe de infraestrutura antes de alterar a conexão.

Se você já consegue abrir o repositório no navegador, mas o Git continua pedindo autenticação, confirme que gh auth status mostra a conta correta e que gh auth setup-git terminou sem erro. Em seguida, feche e abra o terminal e tente novamente. Isso renova a leitura da configuração local sem apagar credenciais ou criar outro token.

Uma alternativa é usar SSH quando a chave já está configurada na sua conta. Nesse caso, use o endereço SSH mostrado pelo botão Code do repositório. Não transforme uma URL HTTPS em SSH por tentativa e erro: as duas formas precisam de credenciais configuradas de maneiras diferentes.

Se ainda falhar, copie a mensagem completa do terminal, remova qualquer dado sensível e consulte a documentação do GitHub. Não desative a segurança da conta nem use credenciais recebidas de terceiros para contornar o aviso.

Fontes utilizadas