Ghostty Is Leaving GitHub: What It Means for Developer-Tool Builders

On April 28, 2026, Mitchell Hashimoto announced that Ghostty, his open-source terminal emulator, is leaving GitHub. He is GitHub user 1299. He joined in February 2008. He has used the platform almost every day for over 18 years. None of that mattered the day he wrote the post; he had already kept a journal of “almost every day has an X” outages, and a GitHub Actions failure on the announcement day blocked his PR reviews for two hours. His verdict was direct: “This is no longer a place for serious work if it just blocks you out for hours per day, every day.”

If you build developer tools, this is the announcement to read twice. Hashimoto is not a casual GitHub user; he co-founded HashiCorp on top of GitHub, has shipped Terraform, Vagrant, Vault, Consul, and Boundary through it, and is GitHub user 1299. When that profile of user walks away from the dominant developer platform on Earth, the story is bigger than one terminal emulator picking a new home. It is a signal about reliability, lock-in, and what it costs to build a tool that other developers depend on every day. This article unpacks what Hashimoto said, what it means for anyone shipping developer tools, and the patterns that protect your own stack from the same trap.

For the broader context on how AI-era developer tools are changing the GitHub-native workflow, see how to write AGENTS.md files and GitHub Copilot usage and billing API for teams. For one team’s take on automating around GitHub’s reliability gaps, see the Clawsweeper triage bot writeup.

TL;DR

• Mitchell Hashimoto announced on April 28, 2026 that Ghostty will leave GitHub for an as-yet-unnamed forge.
• His reason: chronic GitHub Actions and platform outages that he documented as “almost every day has an X” in a personal journal. The announcement day saw a two-hour Actions outage that blocked PR reviews.
• He kept a read-only Ghostty mirror on GitHub and is migrating active development incrementally; his other projects stay on GitHub for now.
• The story matters less because of where Ghostty lands and more because Hashimoto, GitHub user 1299, walked away on reliability grounds, not feature grounds.
• For developer-tool builders, the lesson is that reliability eats features once your tool sits on someone’s critical path. Status-page theater and “we’re investigating” tweets do not buy you the trust back.
• For API teams in particular, the playbook is decoupling: provider-agnostic clients, mocked dependencies during outages, and migration paths that you exercise before you need them. Apidog is built on that pattern.

What Hashimoto said in the post

The announcement post is short, which is part of the message. There is no manifesto, no jab at Microsoft, no plug for an alternative forge. Hashimoto walks through the timeline plainly: he started keeping a journal of GitHub outages, the journal filled up faster than he expected, and on the morning he wrote the post a GitHub Actions failure prevented him from reviewing PRs for two hours. He concluded that the platform is no longer reliable enough for the kind of work he does on Ghostty.

The numbers around the announcement are worth pinning down. April 27, 2026, the day before Hashimoto’s post, saw a major GitHub outage that affected Actions, packages, and the API surface. The journal he references in the post predates that outage; he has been tracking the pattern for months. He frames the move as something that has been quietly planned, not a reaction to a single bad day. The April 27 outage tipped the timing, not the decision.

He is also explicit about the boundaries. Ghostty leaves; his other projects stay on GitHub for now. The Ghostty repository will remain as a read-only mirror at the current URL; a new forge will host active development, including issues, pull requests, and CI. He is in conversations with multiple providers, both commercial and FOSS, and has not committed to a destination yet. The migration will roll out incrementally, not as a flag day.

The omission tells you as much as the words. Hashimoto does not mention features, pricing, or product direction. The complaint is that the surface he depended on stops responding for hours at a time, and a project that ships software cannot run on a substrate that does not run.

Why the reliability angle matters more than the migration

Most coverage of the announcement is asking the wrong question. The interesting question is not where Ghostty lands; the interesting question is how a platform with the engineering depth of GitHub got to the point where its second-most-prominent OG user walked away on reliability grounds. The second-most-interesting question is what that says about the tools the rest of us are building.

Three things make this announcement different from the usual “I am leaving X” post.

The user. Hashimoto is not a brand new developer; he has built infrastructure tools used by Fortune 500 companies. When he says GitHub is unreliable, the audience receiving that message includes the people who decide where their company’s source code lives. The CTO mailing lists were already full of the post by the morning of April 29.

The reason. He did not leave over Copilot, Microsoft, AI training, ICE contracts, pricing, or any of the usual departure topics. He left because the service kept breaking. That collapses the conversation to the one axis that everyone agrees matters: does the tool work when you need it?

The tone. There is no rage. The post reads like a postmortem written by someone who tried hard to stay. The lack of drama is what makes it land harder than any louder post would have. People believe him.

For anyone running a developer tool, that combination is the sound of your worst-case scenario. A long-tenured user, no political axe to grind, no public spat, only a quiet accumulation of “the thing did not work today” entries until the math no longer made sense. There is no PR response to a journal.

What this means if you build developer tools

If your product sits on a developer’s critical path, the Hashimoto announcement is a stress test prompt. Run it against your own service.

Question one: what fraction of your users could write the same journal about you?

Pull the last 90 days of your status page incidents, plus the unreported degradations your team knows about but the status page does not. Map them against your top 20 customers’ work hours. Count how many of those hours were burned waiting for you. If the answer is “more than zero per week per heavy user,” you are on the same trajectory.

Question two: what is the second-derivative of your reliability?

Reliability that is plateauing is fine. Reliability that is silently degrading is the trap. Hashimoto’s journal documented a pattern, not a single event. If you do not have a per-component error budget that someone reads on Monday morning, you cannot tell which direction your numbers are moving.

Question three: do you publish enough that users do not need a journal?

Journals exist because users do not trust the public signal. Your status page should run hot, not cold. If a feature is degraded, mark it. If a region is slow, mark it. If your background queue is 30 minutes behind, mark it. Users who can see the truth in real time do not start journals.

Question four: are you reliable for serious work or for the demo?

A 99.95% uptime that bunches all the downtime into developer working hours is worse than 99.9% uptime spread evenly. If your workload is a four-hour PR-review session, two hours of any-time outage is irrelevant; two hours of outage during that session is the whole session. Measure availability against the customer’s real usage curve, not yours.

Lock-in and the cost of “always GitHub”

The phrase Hashimoto used about himself is the most quotable line in the post: “It’s never been a question for me where I’d put my projects: always GitHub.” That is the cost of habit, and it is the cost most developers do not price properly.

When a single platform is the default for repos, issues, PRs, CI, package distribution, releases, and identity, the surface area of “lock-in” is much larger than the surface area of “the git history.” You can clone a git repo to anywhere; you cannot clone an issue tracker, a PR review history, a Discussions thread, the GitHub Actions secrets store, or the CODEOWNERS-tied review workflow with a single command. The migration cost is shaped like an iceberg.

That cost compounds for tool builders. If your developer tool lives inside a GitHub Action, distributes through the Marketplace, authenticates against GitHub OAuth, and ships releases via GitHub Packages, your tool’s reliability is a derivative of GitHub’s reliability. Your error budget is a fraction of theirs. Your customers experience your downtime when they hit your tool, but they also experience your downtime when GitHub goes down and your tool stops responding. The blame attribution is not always accurate; the customer experience is.

The decoupling work is unglamorous and it is the work. Make every dependency replaceable. Treat GitHub as one provider among several, not as infrastructure. Test the alternative path quarterly. Migrate the parts that fit a different forge better; keep the parts that do not. Hashimoto’s “incremental migration” line is the right shape for everyone, not him alone.

The forge alternatives, briefly

The candidate destinations for Ghostty are public knowledge in shape if not in name. The credible options as of late April 2026:

• Forgejo. Hard fork of Gitea, fully FOSS, maintained by the Codeberg e.V. nonprofit. Federation via ActivityPub is on the roadmap and partially shipped. The default option for FOSS-aligned projects.
• Codeberg. A hosted Forgejo instance run as a nonprofit. Free for open source, no Actions equivalent at GitHub scale yet.
• GitLab. Strong CI/CD, full feature parity with GitHub on most workflows, commercial backing. Controversial choice for the FOSS crowd given recent licensing moves.
• Sourcehut. Email-driven workflow, minimalist, fast. Niche audience, but the audience that uses it loves it. Drew DeVault’s politics are a feature or a bug depending on your priors.
• Self-hosted Forgejo or Gitea on bare metal. Maximum control, maximum operational responsibility. The “go dark” option.
• Radicle. Peer-to-peer, no central host. Early but the federation argument is strongest here. Probably too early for a public-facing project.

Hashimoto explicitly did not commit to one. The signal in the silence is that none of the options are an obvious drop-in for everything GitHub does, which is the point: when one platform absorbs the whole stack, replacing it cleanly is hard by construction.

The lesson for API teams

If you build APIs or API tools instead of terminal emulators, the same pattern applies with the names changed. Replace “GitHub Actions” with “the upstream API your product depends on.” Replace “issues and PRs” with “the inbox where your customers tell you something is wrong.” The structural question is the same: how much of your customer’s work depends on a service you do not control, and how do you stay useful when that service breaks?

Three patterns survive contact with reality.

Mock everything you depend on. Your customers should be able to keep building when the upstream API is down. That means the test suite, the local dev loop, and the CI pipeline all need a mock server that returns realistic responses without a network call. Apidog ships this as a first-class feature; the same data definitions you use to test the live API generate the mock. The pattern is straightforward and the cost is paid once. See the comparison with the OpenAI-shape ecosystem in how to use the GPT-5.5 API for what a multi-provider mocking story looks like in practice.

Test against multiple providers. OpenAI, Anthropic, Mistral, DeepSeek, Google, and xAI all expose chat-completion endpoints with overlapping shapes. If your product wraps any one of them, the difference between “we are down because OpenAI is down” and “we transparently routed to a backup provider” is two days of integration work. Run your test suite against every provider you support, not only the primary. Apidog’s environment variables make the swap a one-line config change.

Decouple your release pipeline from your hosting platform. If your CI lives entirely on GitHub Actions and GitHub Actions has a bad afternoon, your release goes nowhere. Mirroring CI to a second runner, or self-hosting at least the critical paths, removes the single point of failure. The cost is real; the alternative is being unable to ship while your primary provider’s status page changes color.

What an Apidog-style workflow looks like for resilient API work

Concretely, here is the pattern most teams use to insulate themselves from upstream provider outages.

1. Download Apidog and create one project per upstream API surface you depend on.
2. Define the request and response schemas once. Apidog generates a mock server from the schema so the dev loop never blocks on the upstream service.
3. Store credentials as environment-scoped secrets. The same request shape runs against dev (mock), staging (sandbox), and prod (live) by switching environment.
4. Write contract tests that run on every release; the same tests run against every provider you support, so a regression on Provider A surfaces before customers see it.
5. When an upstream API is degraded, flip the environment to mock and keep moving. The product still ships even if the upstream doesn’t.

This pattern is not Ghostty-specific or AI-specific; it is the resilient API pattern that has paid off for every team that adopted it before they needed it. Hashimoto’s post is the latest reminder that you adopt it before you need it, not after.

What developers are reading from the announcement

The reactions in the first 48 hours fall into a few buckets.

The “good for him” camp. Long-time GitHub power users who have been quietly frustrated for months and saw the post as permission to publicize their own gripes. Many of them already mirror to a second forge; the post tipped them toward making the mirror primary.

The “this is one outage” skeptics. People pointing out that GitHub’s overall uptime is competitive with industry norms and that any large platform has bad days. They are not wrong on the macro number, but they are missing the second-derivative point: the trend, not the absolute number, is what triggered Hashimoto.

The “platform exit is hard, see you in six months” pragmatists. Engineers who have run a forge migration and know the issue tracker, PR history, and CI surface area is where the migration cost lives. They are correct, and Hashimoto’s “incremental, with a read-only mirror” plan is the right shape for that constraint.

The “what about my repos” worriers. Smaller maintainers wondering whether their projects are exposed to the same risk. The answer is yes in shape, no in scale; an outage that would lose Hashimoto a billable day at HashiCorp is a minor inconvenience for a weekend project. Your migration calculus is different.

The reactions that matter are not on social media. They are inside the engineering organizations that picked GitHub as a substrate for everything they ship. The conversations are happening on Slack right now: how do we de-risk this, what does our internal policy look like on second-forge mirroring, and what is the exit playbook?

Practical takeaways for your own stack

A short, opinionated checklist:

• Mirror your active repositories to a second forge weekly. Forgejo and Codeberg are free for open source. The cost is one CI job; the value is sleeping through the next four-hour outage.
• Pin the dependency. If you ship a developer tool that calls GitHub APIs, treat the GitHub client as a swappable adapter, not a hard import. Add a Forgejo or GitLab adapter behind the same interface.
• Document the manual fallback. When the automated release pipeline cannot run, what is the manual path? If it is undocumented, the answer is “we cannot release,” and that answer is unacceptable for any tool with paying customers.
• Audit what you depend on. List every external service in the critical path. For each one, write down the answer to “what do we do if this is down for four hours?” Surface the gaps to leadership.
• Watch the second-derivative. If incident frequency is increasing month over month even on a service that still meets its SLA, plan the migration before it is forced.

For an API-tooling-specific worked example, the post on building durable workflows that survive provider outages walks through the same pattern with code, using DeepSeek and OpenAI as the dual-provider example. The shapes change; the principle does not.

FAQ

Where is Ghostty moving to?Hashimoto did not commit to a destination in the announcement post. He said discussions are ongoing with multiple providers, both commercial and FOSS, and that the migration will be incremental, not a single switch. The current Ghostty GitHub repository will remain as a read-only mirror so existing clones, links, and references continue to work.

Is GitHub that unreliable?GitHub’s headline uptime numbers are competitive with peer platforms, but the platform has had several extended outages in 2025 and 2026 that affected Actions, Packages, and the API surface. Hashimoto’s complaint is that the pattern of partial outages, even when each one is short, accumulates into multiple lost work hours per week for users on the critical path.

Should I move my repos off GitHub now?Mirroring is almost certainly worth it. A weekly CI job that pushes to a second forge costs essentially nothing and gives you a working backup the next time GitHub Actions is down for a few hours. Whether you make the second forge primary depends on your tolerance for the migration cost on issues, PR history, and CI configuration; for most teams that cost is not yet justified by the reliability gap.

Does this affect my GitHub Copilot or GitHub Actions usage?Hashimoto’s post does not call out either product specifically, though the Actions outage on the day of the post was the immediate trigger. Copilot is a separate product surface from the platform; its reliability is tracked separately. If your team is on GitHub Copilot, the related billing changes are documented in GitHub Copilot usage and billing API for teams.

What does this mean for AI-era developer tools that depend on GitHub APIs?Tools that wrap the GitHub API (review bots, issue triage, MCP servers) inherit GitHub’s reliability profile by construction. The mitigation is the same as for any third-party dependency: cache aggressively, fail open, and mock the upstream in your test suite. The Apidog mock server pattern is one cheap way to do this; the Clawsweeper triage bot writeup covers a working example.

Is this a “leave GitHub” trend or a one-off?Probably the start of a trend, but a slow one. Migrating any non-trivial project off GitHub is a multi-week project; few teams do it for fun. The signal in the Hashimoto post is that the tradeoff has shifted enough that one of the platform’s longest-tenured users decided the migration cost is worth paying. Other high-profile projects are likely to follow over the next 12 months.

What does “developer-tool builder” mean in this context?Anyone shipping software that other developers use as part of their daily workflow. That includes obvious cases like terminals, editors, and CI runners; it also includes API clients, monitoring tools, package registries, and AI coding assistants. If your customer is a developer and your tool sits between them and shipping, you are a developer-tool builder, and the reliability lessons from the Hashimoto post apply directly.