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

Em 28 de abril de 2026, Mitchell Hashimoto anunciou que o Ghostty, seu emulador de terminal de código aberto, deixará o GitHub. Hashimoto é o usuário 1299 do GitHub, entrou na plataforma em fevereiro de 2008 e a usou quase todos os dias por mais de 18 anos. Mesmo assim, após registrar interrupções frequentes em um diário de “quase todo dia tem um X”, uma falha do GitHub Actions no dia do anúncio bloqueou suas revisões de PR por duas horas. O 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.”

Experimente o Apidog hoje

Se você desenvolve ferramentas para desenvolvedores, vale ler esse anúncio como um estudo de caso de confiabilidade. Hashimoto não é um usuário casual: ele cofundou a HashiCorp sobre o GitHub e lançou Terraform, Vagrant, Vault, Consul e Boundary usando a plataforma. Quando um usuário desse perfil sai por motivos de confiabilidade, a discussão deixa de ser “qual forja usar” e passa a ser: sua ferramenta continua funcionando quando a infraestrutura que você não controla falha?

Para contexto sobre ferramentas de desenvolvedor na era da IA e fluxos nativos do GitHub, veja como escrever arquivos AGENTS.md e uso e API de faturamento do GitHub Copilot para equipes. Para um exemplo de automação em torno de 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.
• O motivo foi confiabilidade: interrupções recorrentes do GitHub Actions e da plataforma, registradas por ele em um diário de “quase todo dia tem um X”.
• No dia do anúncio, uma interrupção de duas horas do Actions bloqueou revisões de PR.
• O repositório do Ghostty no GitHub permanecerá como espelho somente leitura; o desenvolvimento ativo migrará de forma incremental.
• A lição principal para quem constrói ferramentas de desenvolvedor: confiabilidade supera recursos quando sua ferramenta está no caminho crítico.
• Para equipes de API, o caminho prático é desacoplar dependências: simulações, múltiplos provedores, adaptadores intercambiáveis e pipelines de fallback.
• O Apidog segue esse padrão ao permitir modelagem, testes e simulação de APIs em um fluxo único.

O que Hashimoto anunciou

A publicação de Hashimoto é curta e direta. Ele explica que começou a manter um diário de interrupções do GitHub, que esse diário cresceu mais rápido do que o esperado e que, na manhã em que escreveu o anúncio, uma falha do GitHub Actions o impediu de revisar PRs por duas horas.

A decisão não foi apresentada como reação a um único incidente. Segundo ele, o problema era o padrão: interrupções frequentes o suficiente para tornar o GitHub inadequado para o trabalho diário do Ghostty.

O escopo da mudança também foi delimitado:

• O Ghostty sairá do GitHub.
• Outros projetos de Hashimoto permanecerão no GitHub por enquanto.
• O repositório Ghostty continuará disponível como espelho somente leitura.
• Issues, pull requests e CI migrarão para uma nova forja.
• A migração será incremental.
• O destino ainda não foi anunciado.

O ponto importante: Hashimoto não citou preço, recursos, Copilot, Microsoft ou direção de produto. A queixa foi operacional: a plataforma parava de responder por horas, e isso bloqueava o trabalho.

Por que o problema central é confiabilidade

A pergunta menos útil é “para onde o Ghostty vai?”. A pergunta mais útil para equipes técnicas é:

O que acontece quando uma plataforma central para o seu fluxo de entrega deixa de ser confiável o suficiente?

Três fatores tornam esse caso relevante para desenvolvedores:

1. O usuário

Hashimoto construiu ferramentas de infraestrutura usadas em escala empresarial. Quando ele diz que uma plataforma não é confiável para trabalho sério, essa mensagem chega a pessoas que decidem onde código-fonte, CI, releases e automações corporativas vivem.

2. O motivo

Ele não saiu por uma controvérsia de produto. Saiu porque o serviço continuava falhando. Isso reduz a discussão ao critério mais importante para ferramentas de desenvolvedor:

A ferramenta funciona quando o usuário precisa dela?

3. O tom

A publicação não é um manifesto. Parece uma decisão operacional tomada depois de tentativas de continuar. Isso torna o sinal mais forte: não há exagero, apenas acúmulo de falhas.

Para quem opera uma ferramenta de desenvolvedor, esse é o pior cenário: um usuário avançado registra pequenas falhas durante meses até concluir que migrar custa menos do que continuar.

Como auditar sua própria ferramenta

Se seu produto está no caminho crítico de desenvolvedores, use o caso Ghostty como checklist.

1. Quantos usuários poderiam escrever o mesmo diário sobre você?

Faça um levantamento dos últimos 90 dias:

• incidentes públicos;
• degradações não publicadas;
• falhas parciais;
• lentidão em endpoints críticos;
• jobs de background atrasados;
• erros intermitentes em integrações.

Depois mapeie isso contra as horas de trabalho dos seus principais clientes.

Pergunta prática:

Quantas horas produtivas um usuário pesado perdeu por causa da nossa ferramenta nesta semana?

Se a resposta for “mais de zero” de forma recorrente, você tem um problema de tendência.

2. Sua confiabilidade está melhorando ou piorando?

Não olhe apenas para uptime agregado. Observe a direção.

Um serviço pode cumprir SLA e, ainda assim, estar ficando pior para usuários intensivos. O diário de Hashimoto não documentava um único evento; documentava uma tendência.

Implemente um orçamento de erro por componente:

Componente: CI
SLO: 99,9% de disponibilidade em horário comercial
Orçamento de erro mensal: 43 minutos
Responsável: Equipe de plataforma
Revisão: toda segunda-feira

Se ninguém lê esse orçamento semanalmente, ele não influencia decisões.

3. Sua página de status reduz ou aumenta a desconfiança?

Usuários criam seus próprios diários quando não confiam no sinal público.

Sua página de status deve indicar degradação real, não apenas downtime total. Publique quando:

• uma região estiver lenta;
• filas estiverem atrasadas;
• webhooks estiverem com latência elevada;
• APIs estiverem retornando 5xx acima do normal;
• CI estiver com tempo de espera elevado;
• autenticação estiver intermitente.

Se o usuário percebe falha e sua página diz “All systems operational”, você perdeu credibilidade.

4. Seu uptime mede a experiência certa?

Um uptime de 99,95% pode ser ruim se o downtime ocorrer no horário em que os desenvolvedores usam o produto.

Para ferramentas de desenvolvedor, meça disponibilidade contra a curva real de uso:

• horário de revisão de PR;
• janelas de deploy;
• horário de execução de CI;
• picos de chamadas de API;
• ciclos de release.

Duas horas de indisponibilidade durante uma sessão de revisão podem invalidar a sessão inteira.

O custo real do “sempre GitHub”

Hashimoto escreveu que, para ele, “nunca foi uma questão onde colocar meus projetos: sempre GitHub”.

Esse hábito tem custo.

Quando uma plataforma concentra repositórios, issues, PRs, CI, pacotes, releases e identidade, o lock-in não está apenas no Git. Clonar o histórico do repositório é simples. Migrar todo o resto não é.

O que costuma ficar preso:

• histórico de issues;
• discussões;
• comentários de PR;
• revisões;
• checks de CI;
• segredos;
• permissões;
• CODEOWNERS;
• GitHub Actions;
• GitHub Packages;
• automações via API;
• integrações OAuth;
• workflows internos.

O custo de migração é um iceberg: o repositório é a parte visível.

Como reduzir lock-in na prática

Se você constrói uma ferramenta de desenvolvedor integrada ao GitHub, trate o GitHub como um provedor, não como a infraestrutura inteira.

Use adaptadores

Em vez de espalhar chamadas diretas para a API do GitHub pelo código, isole-as:

interface SourceControlProvider {
  getPullRequest(id: string): Promise<PullRequest>;
  listIssues(repo: string): Promise<Issue[]>;
  createComment(targetId: string, body: string): Promise<void>;
  getChangedFiles(prId: string): Promise<FileChange[]>;
}

Depois implemente provedores:

class GitHubProvider implements SourceControlProvider {
  async getPullRequest(id: string) {
    // chamada para GitHub API
  }

  async listIssues(repo: string) {
    // chamada para GitHub Issues
  }

  async createComment(targetId: string, body: string) {
    // comentário em PR ou issue
  }

  async getChangedFiles(prId: string) {
    // arquivos alterados no PR
  }
}

No futuro, você pode adicionar:

class GitLabProvider implements SourceControlProvider {
  // mesma interface, outro backend
}

class ForgejoProvider implements SourceControlProvider {
  // mesma interface, outro backend
}

O objetivo não é migrar amanhã. É evitar que a migração exija reescrever o produto.

Separe CI da plataforma de hospedagem

Se todo o seu pipeline depende do GitHub Actions, uma interrupção do Actions bloqueia seu release.

Opções práticas:

• manter um runner auto-hospedado para caminhos críticos;
• espelhar jobs essenciais em outro CI;
• documentar release manual;
• manter artefatos reproduzíveis localmente;
• evitar que publicação de pacote dependa de uma única plataforma.

Exemplo de checklist mínimo:

[ ] Consigo gerar build localmente?
[ ] Consigo rodar testes sem GitHub Actions?
[ ] Consigo publicar release se o GitHub estiver fora?
[ ] Consigo reconstruir artefatos a partir de tag assinada?
[ ] Existe runbook para release manual?

Espelhe antes de precisar

Espelhamento semanal para uma segunda forja já reduz risco.

Exemplo simples de mirror com Git:

git clone --mirror [e-mail]:org/projeto.git
cd projeto.git
git remote add backup [e-mail]:org/projeto.git
git push --mirror backup

Automatize isso em CI ou em um job agendado fora do GitHub.

Alternativas de forja

Hashimoto não anunciou o destino do Ghostty. As opções plausíveis incluem:

• Forgejo: fork FOSS do Gitea, mantido pela Codeberg e.V.; opção comum para projetos alinhados ao ecossistema FOSS.
• Codeberg: instância hospedada do Forgejo, operada como organização sem fins lucrativos.
• GitLab: CI/CD forte e ampla cobertura de recursos, com suporte comercial.
• Sourcehut: fluxo baseado em e-mail, minimalista e rápido.
• Forgejo ou Gitea auto-hospedado: controle máximo, maior responsabilidade operacional.
• Radicle: abordagem peer-to-peer, ainda mais inicial para projetos públicos de grande visibilidade.

Nenhuma substitui o GitHub perfeitamente em todos os fluxos. Esse é justamente o problema: quando uma plataforma absorve toda a pilha, sair dela exige planejamento incremental.

A lição para equipes de API

Para equipes que constroem APIs ou ferramentas de API, substitua:

GitHub Actions

por:

API upstream da qual seu produto depende

A questão estrutural é a mesma:

Quanto do trabalho do cliente depende de um serviço que você não controla?

Três práticas reduzem esse risco.

1. Simule tudo que você depende

Se a API upstream cair, o desenvolvimento local e os testes não devem parar.

Você precisa de mocks realistas para:

• desenvolvimento local;
• testes automatizados;
• CI;
• demos;
• validação de contrato;
• cenários de erro.

Exemplo de resposta simulada para uma API de chat:

{
  "id": "chatcmpl_mock_123",
  "object": "chat.completion",
  "created": 1714300000,
  "model": "mock-model",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Resposta simulada para ambiente de desenvolvimento."
      },
      "finish_reason": "stop"
    }
  ]
}

Com o Apidog, você define os esquemas de request/response e gera um servidor simulado a partir dessas definições. Isso permite continuar desenvolvendo mesmo quando o provedor real está indisponível.

Veja também como usar a API GPT-5.5 para um exemplo de fluxo multi-provedor no formato OpenAI.

2. Teste contra múltiplos provedores

Se seu produto depende de provedores como OpenAI, Anthropic, Mistral, DeepSeek, Google ou xAI, evite acoplar a lógica de negócio a apenas um deles.

Use variáveis de ambiente:

API_PROVIDER=openai
API_BASE_URL=https://api.openai.com/v1
API_KEY=...

Para alternar:

API_PROVIDER=backup
API_BASE_URL=https://api.backup-provider.example/v1
API_KEY=...

O teste deve validar o contrato comum:

describe("chat completion provider", () => {
  it("returns a message with content", async () => {
    const response = await client.createChatCompletion({
      messages: [{ role: "user", content: "Olá" }]
    });

    expect(response.choices[0].message.content).toBeTruthy();
  });
});

A diferença entre “estamos fora porque o provedor caiu” e “roteamos para um fallback” costuma ser arquitetura, não milagre.

3. Desacople release da hospedagem

Se CI, artefatos e publicação dependem de uma única plataforma, a falha dessa plataforma bloqueia entrega.

Tenha pelo menos um caminho alternativo para:

• build;
• testes críticos;
• assinatura;
• publicação;
• rollback.

Um runbook mínimo deve responder:

Se o CI primário estiver indisponível por 4 horas, como lançamos uma correção crítica?

Se a resposta não estiver documentada, a resposta real é: não lançamos.

Um fluxo resiliente com Apidog

Um fluxo prático para equipes de API:

1. Baixe o Apidog e crie um projeto para cada API upstream crítica.
2. Defina schemas de request e response uma vez.
3. Gere um servidor mock a partir desses schemas.
4. Configure ambientes como dev, staging e prod.
5. Guarde credenciais como segredos por ambiente.
6. Rode os mesmos testes de contrato contra mocks, sandbox e produção.
7. Quando o upstream estiver degradado, alterne para o mock e continue desenvolvendo.
8. Quando houver múltiplos provedores, rode a mesma suíte contra todos.

Exemplo de separação por ambiente:

dev      -> servidor mock
staging  -> sandbox do provedor
prod     -> API real
backup   -> provedor alternativo

Esse padrão não é específico de IA, GitHub ou Ghostty. É uma forma geral de manter desenvolvimento, testes e release funcionando mesmo quando dependências externas falham.

O que os desenvolvedores estão concluindo

As reações ao anúncio tendem a cair em quatro grupos.

“Finalmente alguém disse”

Usuários avançados do GitHub que já estavam frustrados viram a publicação como validação. Muitos já mantinham mirrors e agora consideram promovê-los.

“Foi só uma interrupção”

Alguns apontam que o uptime geral do GitHub continua competitivo. O argumento faz sentido no agregado, mas perde o ponto principal: Hashimoto reagiu a uma tendência, não a um único incidente.

“Migrar é caro”

Esse grupo está certo. Issues, PRs, CI e automações tornam migração difícil. Por isso a abordagem incremental com espelho somente leitura é mais realista do que uma troca abrupta.

“Isso também me afeta?”

Depende da criticidade. Para um projeto de fim de semana, uma interrupção de algumas horas pode ser aceitável. Para uma ferramenta usada diariamente por equipes pagantes, pode ser bloqueante.

Checklist prático para sua stack

Use esta lista como auditoria rápida:

• [ ] Repositórios ativos são espelhados para uma segunda forja?
• [ ] O mirror é testado periodicamente?
• [ ] Issues e PRs críticos têm estratégia de exportação?
• [ ] GitHub API está isolada atrás de uma interface?
• [ ] Existe adaptador para outro provedor ou plano para criá-lo?
• [ ] CI crítico roda fora do GitHub Actions se necessário?
• [ ] Existe release manual documentado?
• [ ] Dependências externas críticas estão listadas?
• [ ] Para cada dependência, há resposta para “e se cair por 4 horas?”
• [ ] APIs upstream têm mocks realistas?
• [ ] Testes de contrato rodam contra mock e produção?
• [ ] Métricas de confiabilidade são revisadas semanalmente?
• [ ] A página de status reflete degradações parciais?
• [ ] A equipe monitora tendência de incidentes, não apenas SLA?

Para um exemplo aplicado a APIs, veja como construir fluxos de trabalho duráveis que sobrevivem a interrupções de provedores, usando DeepSeek e OpenAI como exemplo de provedor duplo.

Perguntas frequentes

Para onde o Ghostty está se mudando?

Hashimoto não anunciou o destino. Ele afirmou que está conversando com vários provedores, comerciais e FOSS, e que a migração será incremental. O repositório atual no GitHub continuará como espelho somente leitura.

O GitHub é realmente tão pouco confiável?

Os números agregados de uptime do GitHub seguem competitivos com plataformas similares. A crítica de Hashimoto é sobre a recorrência de interrupções parciais e o impacto acumulado em trabalho real, especialmente em Actions, Packages e API.

Devo mover meus repositórios para fora do GitHub agora?

Para a maioria das equipes, espelhar vale a pena imediatamente. Tornar outra forja primária depende do custo de migrar issues, PRs, CI e integrações. Comece por reduzir dependência antes de precisar sair.

Isso afeta GitHub Copilot ou GitHub Actions?

A publicação não foi sobre Copilot. O gatilho imediato citado foi uma interrupção do GitHub Actions. Para equipes que usam Copilot, mudanças relacionadas a faturamento estão documentadas em uso e API de faturamento do GitHub Copilot para equipes.

O que isso significa para ferramentas de IA que dependem da API do GitHub?

Bots de revisão, triagem de issues, servidores MCP e automações similares herdam a confiabilidade do GitHub. Mitigue com cache, fallback, filas resilientes e mocks de upstream. O artigo sobre o bot de triagem Clawsweeper mostra um exemplo funcional.

Isso é uma tendência de saída do GitHub?

Provavelmente será lenta. Migrar projetos grandes é caro. O sinal importante é que um dos usuários mais antigos da plataforma concluiu que o custo de continuar superou o custo de migrar.

O que significa “ferramenta de desenvolvedor” aqui?

Qualquer software usado por desenvolvedores no fluxo diário de trabalho: terminais, editores, CI, clientes de API, monitoramento, registros de pacotes, bots de revisão e assistentes de IA. Se sua ferramenta fica entre o desenvolvedor e a entrega, confiabilidade é parte central do produto.