Ghostty Deixando o GitHub: Impacto para Criadores de Ferramentas de Desenvolvedores

Em 28 de abril de 2026, Mitchell Hashimoto anunciou que Ghostty, seu emulador de terminal de código aberto, está deixando o GitHub. Ele é o usuário 1299 do GitHub. Ele ingressou em fevereiro de 2008. Ele usou a plataforma quase todos os dias por mais de 18 anos. Nada disso importou no dia em que ele escreveu a publicação; ele já havia mantido um diário de interrupções de “quase todo dia tem um X”, e uma falha do GitHub Actions no dia do anúncio bloqueou suas revisões de PR por duas horas. Seu veredito foi direto: “Este não é mais um lugar para trabalho sério se ele simplesmente te bloqueia por horas por dia, todos os dias.”

Se você desenvolve ferramentas para desenvolvedores, este é o anúncio para ler duas vezes. Hashimoto não é um usuário casual do GitHub; ele co-fundou a HashiCorp sobre o GitHub, lançou Terraform, Vagrant, Vault, Consul e Boundary através dele, e é o usuário 1299 do GitHub. Quando esse perfil de usuário se afasta da plataforma de desenvolvedores dominante na Terra, a história é maior do que um emulador de terminal escolhendo um novo lar. É um sinal sobre confiabilidade, aprisionamento e o custo de construir uma ferramenta da qual outros desenvolvedores dependem diariamente. Este artigo desvenda o que Hashimoto disse, o que isso significa para qualquer um que esteja lançando ferramentas para desenvolvedores, e os padrões que protegem sua própria pilha da mesma armadilha.

Para um contexto mais amplo sobre como as ferramentas de desenvolvedor da era da IA estão mudando o fluxo de trabalho nativo do GitHub, veja como escrever arquivos AGENTS.md e uso e API de faturamento do GitHub Copilot para equipes. Para a visão de uma equipe sobre como automatizar em torno das lacunas de confiabilidade do GitHub, veja o artigo sobre o bot de triagem Clawsweeper.

Resumo

• Mitchell Hashimoto anunciou em 28 de abril de 2026 que o Ghostty deixará o GitHub para uma forja ainda não nomeada.
• Sua razão: interrupções crônicas do GitHub Actions e da plataforma que ele documentou como “quase todo dia tem um X” em um diário pessoal. O dia do anúncio teve uma interrupção de duas horas do Actions que bloqueou as revisões de PR.
• Ele manteve um espelho somente leitura do Ghostty no GitHub e está migrando o desenvolvimento ativo incrementalmente; seus outros projetos permanecem no GitHub por enquanto.
• A história importa menos por onde o Ghostty vai parar e mais porque Hashimoto, usuário 1299 do GitHub, se afastou por motivos de confiabilidade, e não por motivos de recursos.
• Para desenvolvedores de ferramentas, a lição é que a confiabilidade supera os recursos quando sua ferramenta está no caminho crítico de alguém. O teatro da página de status e os tweets de “estamos investigando” não trazem a confiança de volta.
• Para equipes de API em particular, o manual é o desacoplamento: clientes agnósticos de provedor, dependências simuladas durante interrupções e caminhos de migração que você exercita antes de precisar deles. O Apidog é construído sobre esse padrão.

O que Hashimoto disse na publicação

A publicação do anúncio é curta, o que faz parte da mensagem. Não há manifesto, nenhuma crítica à Microsoft, nenhuma propaganda para uma forja alternativa. Hashimoto descreve a linha do tempo de forma clara: ele começou a manter um diário de interrupções do GitHub, o diário encheu mais rápido do que ele esperava, e na manhã em que escreveu a publicação, uma falha do GitHub Actions o impediu de revisar PRs por duas horas. Ele concluiu que a plataforma não é mais confiável o suficiente para o tipo de trabalho que ele faz no Ghostty.

Os números em torno do anúncio valem a pena serem destacados. 27 de abril de 2026, o dia anterior à publicação de Hashimoto, registrou uma grande interrupção do GitHub que afetou Actions, pacotes e a superfície da API. O diário que ele menciona na publicação é anterior a essa interrupção; ele tem acompanhado o padrão por meses. Ele enquadra a mudança como algo que foi planejado discretamente, não uma reação a um único dia ruim. A interrupção de 27 de abril influenciou o momento, não a decisão.

Ele também é explícito sobre os limites. O Ghostty sai; seus outros projetos permanecem no GitHub por enquanto. O repositório Ghostty permanecerá como um espelho somente leitura no URL atual; uma nova forja hospedará o desenvolvimento ativo, incluindo issues, pull requests e CI. Ele está em conversas com vários provedores, tanto comerciais quanto FOSS, e ainda não se comprometeu com um destino. A migração será implementada incrementalmente, e não como um dia de transição única.

A omissão revela tanto quanto as palavras. Hashimoto não menciona recursos, preços ou direção do produto. A queixa é que a superfície da qual ele dependia para de responder por horas seguidas, e um projeto que entrega software não pode rodar em uma base que não funciona.

Por que o ângulo da confiabilidade importa mais do que a migração

A maior parte da cobertura do anúncio está fazendo a pergunta errada. A questão interessante não é onde o Ghostty vai parar; a questão interessante é como uma plataforma com a profundidade de engenharia do GitHub chegou ao ponto em que seu segundo usuário OG mais proeminente se afastou por motivos de confiabilidade. A segunda pergunta mais interessante é o que isso diz sobre as ferramentas que o resto de nós está construindo.

Três coisas tornam este anúncio diferente da publicação usual de “Estou saindo do X”.

• O usuário. Hashimoto não é um desenvolvedor novato; ele construiu ferramentas de infraestrutura usadas por empresas da Fortune 500. Quando ele diz que o GitHub não é confiável, o público que recebe essa mensagem inclui as pessoas que decidem onde o código-fonte de suas empresas vive. As listas de e-mails de CTOs já estavam cheias da publicação na manhã de 29 de abril.
• A razão. Ele não saiu por causa do Copilot, Microsoft, treinamento de IA, contratos ICE, preços ou qualquer um dos tópicos de partida usuais. Ele saiu porque o serviço continuava quebrando. Isso resume a conversa ao único eixo que todos concordam que importa: a ferramenta funciona quando você precisa dela?
• O tom. Não há raiva. A publicação parece uma análise post-mortem escrita por alguém que se esforçou muito para ficar. A falta de drama é o que a torna mais impactante do que qualquer publicação mais barulhenta teria sido. As pessoas acreditam nele.

Para qualquer pessoa que opere uma ferramenta de desenvolvedor, essa combinação é o som do seu pior cenário. Um usuário de longa data, sem segundas intenções políticas, sem disputa pública, apenas um acúmulo silencioso de entradas de “a coisa não funcionou hoje” até que a matemática não fizesse mais sentido. Não há resposta de relações públicas para um diário.

O que isso significa se você constrói ferramentas para desenvolvedores

Se o seu produto está no caminho crítico de um desenvolvedor, o anúncio de Hashimoto é um prompt de teste de estresse. Execute-o contra o seu próprio serviço.

Primeira pergunta: que fração dos seus usuários poderia escrever o mesmo diário sobre você?

Puxe os últimos 90 dias dos incidentes da sua página de status, além das degradações não relatadas que sua equipe conhece, mas a página de status não. Mapeie-os em relação às horas de trabalho dos seus 20 principais clientes. Conte quantas dessas horas foram perdidas esperando por você. Se a resposta for “mais de zero por semana por usuário pesado”, você está na mesma trajetória.

Segunda pergunta: qual é a segunda derivada da sua confiabilidade?

A confiabilidade que está estabilizando está boa. A confiabilidade que está degradando silenciosamente é a armadilha. O diário de Hashimoto documentou um padrão, não um único evento. Se você não tiver um orçamento de erros por componente que alguém leia na segunda-feira de manhã, você não pode dizer em que direção seus números estão se movendo.

Terceira pergunta: você publica o suficiente para que os usuários não precisem de um diário?

Diários existem porque os usuários não confiam no sinal público. Sua página de status deve estar ativa, não fria. Se um recurso está degradado, marque-o. Se uma região está lenta, marque-a. Se sua fila de segundo plano está 30 minutos atrasada, marque-a. Usuários que podem ver a verdade em tempo real não começam diários.

Quarta pergunta: você é confiável para trabalho sério ou para a demonstração?

Um tempo de atividade de 99,95% que agrupa todo o tempo de inatividade nas horas de trabalho do desenvolvedor é pior do que um tempo de atividade de 99,9% distribuído uniformemente. Se sua carga de trabalho é uma sessão de revisão de PR de quatro horas, duas horas de interrupção a qualquer momento são irrelevantes; duas horas de interrupção durante essa sessão são a sessão inteira. Meça a disponibilidade em relação à curva de uso real do cliente, não à sua.

Aprisionamento e o custo de “sempre GitHub”

A frase que Hashimoto usou sobre si mesmo é a mais citável na publicação: “Nunca foi uma questão para mim onde eu colocaria meus projetos: sempre GitHub.” Esse é o custo do hábito, e é o custo que a maioria dos desenvolvedores não precifica corretamente.

Quando uma única plataforma é o padrão para repositórios, issues, PRs, CI, distribuição de pacotes, releases e identidade, a área de superfície de “aprisionamento” é muito maior do que a área de superfície de “o histórico do git”. Você pode clonar um repositório git para qualquer lugar; você não pode clonar um rastreador de issues, um histórico de revisão de PR, um tópico de Discussões, o armazenamento de segredos do GitHub Actions ou o fluxo de trabalho de revisão vinculado ao CODEOWNERS com um único comando. O custo da migração tem a forma de um iceberg.Esse custo se acumula para os construtores de ferramentas. Se sua ferramenta de desenvolvedor vive dentro de um GitHub Action, distribui através do Marketplace, autentica-se contra o GitHub OAuth e lança releases via GitHub Packages, a confiabilidade de sua ferramenta é um derivado da confiabilidade do GitHub. Seu orçamento de erros é uma fração do deles. Seus clientes experimentam seu tempo de inatividade quando usam sua ferramenta, mas também experimentam seu tempo de inatividade quando o GitHub fica fora do ar e sua ferramenta para de responder. A atribuição de culpa nem sempre é precisa; a experiência do cliente é.

O trabalho de desacoplamento não é glamuroso e é o trabalho. Torne cada dependência substituível. Trate o GitHub como um provedor entre vários, não como infraestrutura. Teste o caminho alternativo trimestralmente. Migre as partes que se encaixam melhor em uma forja diferente; mantenha as partes que não se encaixam. A linha de Hashimoto sobre “migração incremental” é o formato certo para todos, não apenas para ele.

As alternativas de forja, brevemente

Os destinos candidatos para o Ghostty são de conhecimento público em forma, se não em nome. As opções credíveis a partir do final de abril de 2026:

• Forgejo. Hard fork do Gitea, totalmente FOSS, mantido pela organização sem fins lucrativos Codeberg e.V. A federação via ActivityPub está no roteiro e parcialmente lançada. A opção padrão para projetos alinhados ao FOSS.
• Codeberg. Uma instância hospedada do Forgejo operada como uma organização sem fins lucrativos. Gratuito para código aberto, ainda sem equivalente ao Actions na escala do GitHub.
• GitLab. Forte CI/CD, paridade total de recursos com o GitHub na maioria dos fluxos de trabalho, apoio comercial. Escolha controversa para a comunidade FOSS dadas as recentes mudanças de licenciamento.
• Sourcehut. Fluxo de trabalho baseado em e-mail, minimalista, rápido. Público de nicho, mas o público que o usa o adora. As políticas de Drew DeVault são um recurso ou um bug dependendo das suas prioridades.
• Forgejo ou Gitea auto-hospedado em bare metal. Controle máximo, responsabilidade operacional máxima. A opção de “ir para as sombras”.
• Radicle. Peer-to-peer, sem host central. Ainda em fase inicial, mas o argumento da federação é mais forte aqui. Provavelmente muito cedo para um projeto de face pública.

Hashimoto explicitamente não se comprometeu com uma. O sinal no silêncio é que nenhuma das opções é uma substituição óbvia para tudo o que o GitHub faz, que é o ponto: quando uma plataforma absorve toda a pilha, substituí-la de forma limpa é difícil por construção.

A lição para equipes de API

Se você constrói APIs ou ferramentas de API em vez de emuladores de terminal, o mesmo padrão se aplica com os nomes trocados. Substitua “GitHub Actions” por “a API upstream da qual seu produto depende”. Substitua “issues e PRs” por “a caixa de entrada onde seus clientes dizem que algo está errado”. A questão estrutural é a mesma: quanto do trabalho do seu cliente depende de um serviço que você não controla, e como você se mantém útil quando esse serviço falha?

Três padrões sobrevivem ao contato com a realidade.

• Simule tudo o que você depende. Seus clientes devem ser capazes de continuar desenvolvendo quando a API upstream estiver fora do ar. Isso significa que o conjunto de testes, o ciclo de desenvolvimento local e o pipeline de CI precisam de um servidor simulado que retorne respostas realistas sem uma chamada de rede. O Apidog oferece isso como um recurso de primeira classe; as mesmas definições de dados que você usa para testar a API real geram a simulação. O padrão é direto e o custo é pago uma vez. Veja a comparação com o ecossistema no formato OpenAI em como usar a API GPT-5.5 para ver como uma história de simulação multi-provedor se parece na prática.
• Teste contra múltiplos provedores. OpenAI, Anthropic, Mistral, DeepSeek, Google e xAI expõem endpoints de conclusão de chat com formatos sobrepostos. Se seu produto envolve qualquer um deles, a diferença entre “estamos fora do ar porque a OpenAI está fora do ar” e “direcionamos transparentemente para um provedor de backup” são dois dias de trabalho de integração. Execute seu conjunto de testes contra todos os provedores que você suporta, não apenas o principal. As variáveis de ambiente do Apidog tornam a troca uma alteração de configuração de uma linha.
• Desacople seu pipeline de lançamento da sua plataforma de hospedagem. Se seu CI vive inteiramente no GitHub Actions e o GitHub Actions tem uma tarde ruim, seu lançamento não vai a lugar nenhum. Espelhar o CI para um segundo executor, ou auto-hospedar pelo menos os caminhos críticos, remove o ponto único de falha. O custo é real; a alternativa é ser incapaz de entregar enquanto a página de status do seu provedor primário muda de cor.

Como um fluxo de trabalho estilo Apidog se parece para um trabalho de API resiliente

Concretamente, aqui está o padrão que a maioria das equipes usa para se proteger de interrupções de provedores upstream.

1. Baixe o Apidog e crie um projeto para cada superfície de API upstream da qual você depende.
2. Defina os esquemas de requisição e resposta uma vez. O Apidog gera um servidor simulado a partir do esquema para que o ciclo de desenvolvimento nunca seja bloqueado pelo serviço upstream.
3. Armazene as credenciais como segredos com escopo de ambiente. O mesmo formato de requisição é executado contra dev (simulado), staging (sandbox) e prod (ao vivo), simplesmente trocando o ambiente.
4. Escreva testes de contrato que são executados em cada lançamento; os mesmos testes são executados contra todos os provedores que você suporta, então uma regressão no Provedor A aparece antes que os clientes a vejam.
5. Quando uma API upstream está degradada, mude o ambiente para simulação e continue. O produto ainda é lançado mesmo que o upstream não esteja.

Este padrão não é específico do Ghostty ou da IA; é o padrão de API resiliente que tem valido a pena para todas as equipes que o adotaram antes de precisarem dele. A publicação de Hashimoto é o mais recente lembrete de que você o adota antes de precisar, não depois.

O que os desenvolvedores estão tirando do anúncio

As reações nas primeiras 48 horas se enquadram em algumas categorias.

• O grupo “bem feito para ele”. Usuários avançados de longa data do GitHub que estavam silenciosamente frustrados por meses e viram a publicação como uma permissão para tornar públicas suas próprias queixas. Muitos deles já espelham para uma segunda forja; a publicação os inclinou a tornar o espelho primário.
• Os céticos do “isto é uma única interrupção”. Pessoas apontando que o tempo de atividade geral do GitHub é competitivo com as normas da indústria e que qualquer plataforma grande tem dias ruins. Eles não estão errados no número macro, mas estão perdendo o ponto da segunda derivada: a tendência, não o número absoluto, foi o que acionou Hashimoto.
• Os pragmáticos do “sair da plataforma é difícil, nos vemos em seis meses”. Engenheiros que realizaram uma migração de forja e sabem que o rastreador de issues, o histórico de PRs e a área de superfície do CI são onde o custo da migração reside. Eles estão corretos, e o plano de Hashimoto de “incremental, com um espelho somente leitura” é o formato certo para essa restrição.
• Os preocupados com “e meus repositórios?”. Mantenedores menores se perguntando se seus projetos estão expostos ao mesmo risco. A resposta é sim em forma, não em escala; uma interrupção que faria Hashimoto perder um dia faturável na HashiCorp é um inconveniente menor para um projeto de fim de semana. Seu cálculo de migração é diferente.

As reações que importam não estão nas redes sociais. Elas estão dentro das organizações de engenharia que escolheram o GitHub como substrato para tudo o que entregam. As conversas estão acontecendo no Slack agora: como reduzimos esse risco, como é nossa política interna de espelhamento em segunda forja e qual é o plano de saída?

Principais lições práticas para sua própria pilha

Uma lista de verificação curta e com opiniões:

• Espelhe seus repositórios ativos para uma segunda forja semanalmente. Forgejo e Codeberg são gratuitos para código aberto. O custo é um trabalho de CI; o valor é dormir tranquilamente durante a próxima interrupção de quatro horas.
• Fixe a dependência. Se você entrega uma ferramenta de desenvolvedor que chama APIs do GitHub, trate o cliente GitHub como um adaptador intercambiável, não uma importação fixa. Adicione um adaptador Forgejo ou GitLab por trás da mesma interface.
• Documente o fallback manual. Quando o pipeline de lançamento automatizado não pode ser executado, qual é o caminho manual? Se não estiver documentado, a resposta é “não podemos lançar”, e essa resposta é inaceitável para qualquer ferramenta com clientes pagantes.
• Audite o que você depende. Liste cada serviço externo no caminho crítico. Para cada um, anote a resposta para “o que fazemos se isso ficar fora do ar por quatro horas?” Apresente as lacunas à liderança.
• Observe a segunda derivada. Se a frequência de incidentes está aumentando mês a mês, mesmo em um serviço que ainda cumpre seu SLA, planeje a migração antes que ela seja forçada.

Para um exemplo prático específico de ferramentas de API, a publicação sobre como construir fluxos de trabalho duráveis que sobrevivem a interrupções de provedores detalha o mesmo padrão com código, usando DeepSeek e OpenAI como exemplo de provedor duplo. As formas mudam; o princípio não.

Perguntas Frequentes

• Para onde o Ghostty está se mudando? Hashimoto não se comprometeu com um destino na publicação do anúncio. Ele disse que as discussões estão em andamento com vários provedores, tanto comerciais quanto FOSS, e que a migração será incremental, não uma mudança única. O repositório atual do Ghostty no GitHub permanecerá como um espelho somente leitura para que clones, links e referências existentes continuem funcionando.
• O GitHub é tão pouco confiável assim? Os números de tempo de atividade divulgados pelo GitHub são competitivos com plataformas similares, mas a plataforma teve várias interrupções estendidas em 2025 e 2026 que afetaram Actions, Packages e a superfície da API. A queixa de Hashimoto é que o padrão de interrupções parciais, mesmo quando cada uma é curta, acumula-se em várias horas de trabalho perdidas por semana para usuários no caminho crítico.
• Devo mover meus repositórios para fora do GitHub agora? Espelhar quase certamente vale a pena. Um trabalho de CI semanal que envia para uma segunda forja não custa essencialmente nada e oferece um backup funcional da próxima vez que o GitHub Actions estiver fora do ar por algumas horas. Se você torna a segunda forja primária depende da sua tolerância ao custo de migração em issues, histórico de PR e configuração de CI; para a maioria das equipes, esse custo ainda não se justifica pela lacuna de confiabilidade.
• Isso afeta meu uso do GitHub Copilot ou GitHub Actions? A publicação de Hashimoto não menciona especificamente nenhum dos produtos, embora a interrupção do Actions no dia da publicação tenha sido o gatilho imediato. O Copilot é uma superfície de produto separada da plataforma; sua confiabilidade é rastreada separadamente. Se sua equipe usa o GitHub Copilot, as mudanças de faturamento relacionadas estão documentadas em uso e API de faturamento do GitHub Copilot para equipes.
• O que isso significa para ferramentas de desenvolvedor da era da IA que dependem de APIs do GitHub? Ferramentas que envolvem a API do GitHub (bots de revisão, triagem de issues, servidores MCP) herdam o perfil de confiabilidade do GitHub por construção. A mitigação é a mesma para qualquer dependência de terceiros: cache agressivamente, falhe aberto e simule o upstream em seu conjunto de testes. O padrão de servidor simulado do Apidog é uma maneira barata de fazer isso; o artigo sobre o bot de triagem Clawsweeper cobre um exemplo funcional.
• Isso é uma tendência de “deixar o GitHub” ou um caso isolado? Provavelmente o início de uma tendência, mas lenta. Migrar qualquer projeto não trivial para fora do GitHub é um projeto de várias semanas; poucas equipes fazem isso por diversão. O sinal na publicação de Hashimoto é que a relação custo-benefício mudou o suficiente para que um dos usuários mais antigos da plataforma decidisse que o custo da migração vale a pena. Outros projetos de alto perfil provavelmente seguirão o exemplo nos próximos 12 meses.
• O que significa “desenvolvedor de ferramentas” neste contexto? Qualquer pessoa que entrega software que outros desenvolvedores usam como parte de seu fluxo de trabalho diário. Isso inclui casos óbvios como terminais, editores e executores de CI; também inclui clientes de API, ferramentas de monitoramento, registros de pacotes e assistentes de codificação de IA. Se seu cliente é um desenvolvedor e sua ferramenta se posiciona entre eles e a entrega, você é um desenvolvedor de ferramentas, e as lições de confiabilidade da publicação de Hashimoto se aplicam diretamente.