Configuration and ports

The ports T3 Code uses, what settings exist, how dev instances get isolated ports, and the environment details that decide whether your provider CLI is found.

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

There isn't much to configure — most of T3 Code's behaviour comes from the provider CLI and your git repository. What does matter is ports and environment.

Ports#

Both 3773 and 9234 matter when things break. A conflict on 9234 belongs to Codex, not T3 Code, which is why the error message tends not to mention T3 Code at all.

# who has the port
lsof -ti:3773                          # macOS / Linux
netstat -ano | findstr :3773           # Windows

# take it back
lsof -ti:3773 | xargs kill -9

Full port-conflict guide →

Binding#

Where the server listens is set at launch, not in a config file:

npx t3 serve --host 127.0.0.1                 # loopback only
npx t3 serve --host "$(tailscale ip -4)"      # Tailnet only
npx t3 serve --host 0.0.0.0                   # every interface — be careful

Treat this as a security setting rather than a convenience one. See remote access.

Settings in the app#

The desktop app's Settings panel covers, among others:

• Connections — network access toggle, pairing links, remote environments over SSH
• Providers — which agents are configured, and provider update behaviour
• Appearance — theme and preview colour scheme controls
• Keybindings — customisable shortcuts

Recent nightlies have added preview colour scheme controls, improved light-mode contrast on message bubbles, and made the diff panel's collapse behaviour configurable.

Dev instances#

Running a development build alongside your normal one would normally collide on port 3773. Named instances avoid that:

T3CODE_DEV_INSTANCE=feature-xyz bun run dev:desktop

Each named instance gets its own port and isolated state, including isolated worktree dev state in recent builds. Recent nightlies also let dev instances be shared over Tailscale and skip browser-blocked ports when choosing one — browsers refuse to connect to certain ports outright, and picking one produces a failure that looks like a server crash.

The environment that actually matters#

More configuration problems come from environment than from settings. T3 Code spawns your provider CLI as a subprocess, so it needs to find it:

• PATH — must include your provider CLI. GUI-launched apps on macOS and Windows often have a narrower PATH than your shell. Symptoms and fixes →
• Node.js — the npx route uses your system Node. Remote environments require ^22.16 || ^23.11 || >=24.10
• Version managers — Volta, asdf, mise, fnm, nodenv and nvm are searched for remote environments, but locally the GUI just inherits whatever PATH it was given
• systemd — user units get a minimal environment; set PATH= explicitly in the unit file

Data locations#

Project configuration, thread history and pairing credentials are stored per user by the app. Exact paths follow platform conventions and have moved between builds, so rather than hardcoding a path, check your build's documentation before scripting against it. Nothing is stored server-side by T3 — this is all local.

FAQ#

What port does T3 Code run on?#

Port 3773 by default, serving both the web UI over HTTP and agent sessions over WebSocket at ws://localhost:3773.

Can I change the T3 Code port?#

Binding is controlled by launch flags such as --host rather than a config file, and dev instances get their own ports via T3CODE_DEV_INSTANCE. Check npx t3 serve --help on your build for the port options it exposes.

What is port 9234 used for?#

It's a loopback port used by the Codex CLI for remote connections, not by T3 Code itself. If another process holds it, Codex app-server bootstrap can fail.

Where does T3 Code store its configuration?#

Locally on your machine, in per-user application data following platform conventions. Nothing is stored on a T3-operated server.