Updates and nightly builds

T3 Code ships nightly builds most days. How versioning works, how to update or pin per install method, and whether to ride nightly or stay pinned.

Last reviewed 2026-07-27 · verified against the pingdotgg/t3code repo

T3 Code is early-stage software under active daily development. Version numbers are still in the 0.0.x range, and nightly builds tagged like v0.0.29-nightly.20260727.915 ship most days — sometimes several in a day.

Plan for that rather than being surprised by it.

Reading the version number#

v0.0.29-nightly.20260727.915
   │       │        │      └── build number
   │       │        └── build date (YYYYMMDD)
   │       └── channel
   └── target version

A nightly tagged 0.0.29-nightly is work heading toward 0.0.29, not a released 0.0.29. The build date tells you how fresh it is, which is usually the number you care about.

Updating, per install method#

The running server can also keep itself in sync with the published build, so a long-lived instance won't necessarily stay on the version you started.

Should you ride nightly?#

Yes, if you're using T3 Code for personal work, want the newest provider and model support, and can tolerate the occasional broken build. Fixes land fast — often the same day.

No, if T3 Code is part of a team workflow or anything resembling a documented process. Pin a version and upgrade deliberately:

npx t3@0.0.28

The repo is explicit that this is very early stage with expected bugs and breaking changes. That's a statement about the release channel, not just a disclaimer.

Pin the provider CLI too#

Half of what breaks isn't T3 Code — it's the provider CLI moving underneath it. Codex in particular changes its app-server protocol, and version skew between T3 Code and Codex produces symptoms that look like T3 Code bugs.

The clearest example: an old Codex CLI causes session startup to hang with Timed out waiting for initialize, and updating Codex fixes it outright. There's an open request to add explicit Codex version compatibility checks so this surfaces as a clear message instead of a timeout.

Practical rule: when something breaks after an update, update your provider CLI before filing a bug.

npm i -g @openai/codex@latest
codex --version

When updates themselves fail#

Provider updates from inside T3 Code can get stuck in a loop — reported as Codex updates always failing. Usually a permissions problem on the global npm prefix, or a lock file that survived a crashed update. Walkthrough →

Following along#

• Releases — every build with its changelog
• Our news digest — the changes that actually matter, in English
• Discord — where breakage gets discussed first

FAQ#

How often does T3 Code release updates?#

Nightly builds ship most days, sometimes several per day. The project is in active early development in the 0.0.x version range.

How do I update T3 Code?#

Run npx t3@latest for the npx route, winget upgrade T3Tools.T3Code on Windows, brew upgrade --cask t3-code on macOS, or yay -S t3code-bin on Arch Linux.

Can I pin T3 Code to a specific version?#

Yes. Use an explicit version with npx, such as npx t3@0.0.28, or install a specific release artifact from the GitHub releases page. Pinning is worth it for team workflows given the pace of change.

Should I update my Codex CLI when I update T3 Code?#

Yes. Version skew between T3 Code and the provider CLI is a common source of failures, including sessions that hang with "Timed out waiting for initialize". Update both together.