Dev instances become shareable over Tailscale
A 27 July 2026 build lets development instances be shared over Tailscale and skips browser-blocked ports — plus isolated worktree dev state the day before.
27 July 2026 — build v0.0.29-nightly.20260727.915:
- Development instances can be shared over Tailscale
- The instance picker skips browser-blocked ports
And the day's earlier build, ...914, keeps worktree dev state isolated on T3 Code dev servers.
Three changes to the same area, which usually means someone hit all three in one sitting.
Dev instances, briefly#
Running a development build alongside your daily T3 Code would normally collide on port 3773. Named instances avoid that:
T3CODE_DEV_INSTANCE=feature-xyz bun run dev:desktopEach named instance gets its own port and its own state. Configuration →
Sharing a dev instance over Tailscale#
Previously a dev instance was effectively stuck on localhost. Now it can be reached across your Tailnet like a normal remote T3 Code server.
That's genuinely useful for anyone working on T3 Code itself:
- Test a UI change on a phone without building and distributing anything
- Have a colleague look at a branch running live rather than from a screenshot
- Develop on a desktop, verify on a laptop, without pushing first
The Tailscale flags that already existed for regular servers are the relevant background:
npx t3 serve --tailscale-serve
npx t3 serve --tailscale-serve --tailscale-serve-port 8443The browser-blocked ports fix#
The smaller change is the more interesting bug.
Browsers maintain a list of ports they refuse to connect to, regardless of what's listening — a long-standing defence against cross-protocol attacks that abuse ports like 6000 or 6667. Connect a browser to one and it fails immediately, with an error that doesn't obviously say "this port is blocked by policy."
If a dev instance picked a port from that list, the result looked exactly like a crashed server: everything appears to start correctly, and the browser simply won't connect. Debugging that means knowing the blocklist exists.
Now the picker skips them. This is the kind of fix that saves an hour for whoever would have hit it next.
Isolated worktree dev state#
The day's earlier build keeps worktree dev state isolated on dev servers, so a development instance can't corrupt the worktree state your daily instance depends on.
Given that worktrees are how T3 Code isolates parallel agents, shared dev state was a real hazard — testing a change shouldn't be able to disturb work in progress.
What it signals#
Not headline features, but three fixes in one day to the seams where instances, ports and state overlap. That's a project being used heavily enough by its own developers for the edges to show, and maintained closely enough for them to get fixed the same day.
Which is roughly the state of T3 Code generally: early, fast-moving, and improving in the specific places its maintainers actually feel friction.
FAQ#
Can I share a T3 Code dev instance over Tailscale?#
Yes, since the 27 July 2026 nightly build. Development instances can be reached across your Tailnet rather than being limited to localhost.
What is a browser-blocked port?#
Browsers refuse to connect to a fixed list of ports as a security measure, regardless of what's listening. A server bound to one appears completely broken from the browser's side.
How do I run a T3 Code dev instance?#
Set T3CODE_DEV_INSTANCE=<name> before the dev command, for example T3CODE_DEV_INSTANCE=feature-xyz bun run dev:desktop. Each named instance gets its own port and isolated state.
Is it safe to share a dev instance over Tailscale?#
Only within a trusted Tailnet. A dev instance can run arbitrary commands and modify files just like a normal server, so never expose it to a public interface and treat pairing tokens as passwords.