[Bug]: Usage host fingerprint uses os.hostname(), which is unstable in containers

[AmeinEskinder]

Area

apps/server

Steps to reproduce

1. Run the T3 Code server in a Docker container, with <T3 home> on a named volume so state persists (a normal remote-environment setup).
2. Use a provider for a while so usage records accumulate, and open Usage → Limits.
3. Recreate the container — docker compose up -d --force-recreate, or any image pull, which is what a nightly deploy does.
4. Open Usage → Limits again.

Expected behavior

The environment keeps one identity across container recreates. Usage stays attributed to a single host, and the list does not grow an entry per redeploy.

Actual behavior

Every recreate produces a new host identity, so the usage list accumulates one stale entry per deploy, each labelled with a dead 12-hex container ID.

UsageService fingerprints usage records by os.hostname():

// apps/server/src/usage/UsageService.ts:473
const hostId = NodeOS.hostname();
...
fingerprint: { hostId, provider, resolvedHomePath: dir, volumeId },

Inside a container, os.hostname() defaults to the container ID, which is regenerated on every recreate. Docker only keeps a hostname stable if hostname: is set explicitly in compose, and nothing in the container docs suggests it matters.

Observed on two hosts. The IDs shown in the UI a few deploys ago (34b08f9f0350, e12c9b64fb68) no longer exist anywhere; today the same two environments report:

primary      519d29be0f28
workstation  b257a7fc38ac

Meanwhile each environment already has a stable identity that survives recreates, because it lives on the persisted volume:

/home/node/.t3/userdata/environment-id
1044d043-b1bd-4a13-8b32-03523cb35ca0   # primary
8a47e572-0500-451d-b58c-559fda9241c8   # workstation

So the durable identifier exists and is not the one used.

Two consequences beyond the clutter: usage history fragments across identities rather than accumulating per environment, and the labels are opaque — a container ID cannot be matched to a machine by looking at it, which is what led me here.

Impact

Minor bug or occasional failure

Version or commit

t3 v0.0.41-nightly.20260913.1658

Environment

Server in Docker (node:24.13.1-bookworm-slim), Debian 12, two remote Linux environments reached over a VPN. T3 home, provider credential directories, and the git worktree root are all named volumes; the container itself is disposable and recreated on every image update.

Workaround

Set hostname: explicitly in the compose service so the container keeps a stable name across recreates. That fixes the symptom but relies on every containerised deployment knowing to do it.

A fix in the server could prefer the persisted environment-id for the fingerprint's host component, fall back to os.hostname() when it is absent, or allow an explicit override (T3CODE_HOST_ID) for deployments where the hostname is not meaningful.

[juliusmarminge]

Triage

Confirmed on current main. Not a duplicate of the other open Usage/Limits issues.

What we verified

UsageService still fingerprints every source with the process hostname:

const hostId = NodeOS.hostname();
fingerprint: { hostId, provider, resolvedHomePath: dir, volumeId }

(apps/server/src/usage/UsageService.ts, packages/contracts/src/usage.ts)

That value is the Docker container ID unless compose sets hostname:. Recreating the container (image pull / force-recreate) changes it. The durable environment identity the report points at is real and already survives a named-volume recreate: {T3 home}/userdata/environment-id from ServerEnvironment / config.ts.

The 12-hex IDs on Usage → Limits are almost certainly the environment label, not the fingerprint field. Limits and the environment picker render environment.label. ServerEnvironmentLabel tries a pretty hostname, then falls back to os.hostname(). Slim images typically have no PRETTY_HOSTNAME, so the UI shows the container ID. Same root cause, different field.

What does not follow

Usage scans are live from provider transcripts. The scan cache is per file (size, mtime), not per hostId. Limits accounts key by driver:email; environments under an account key by environmentId. With a stable environment-id, the two machines should relabel after a recreate, not grow a new Limits row each deploy. The report’s “same two environments, new IDs” matches that. Transcript history on the volume should still scan as one environment.

The fingerprint still matters: usageMerge de-dupes worktree servers on one machine with hostId + path + volumeId. An unstable hostname makes the same directory look like a new host after a recreate (failed collapse / double-count across environments), and the labels stay opaque.

Not the same bug

• [Bug]: Usage double-counts a provider transcript directory shared between Windows and a WSL environment (source fingerprint cannot unify one directory across the OS boundary) #7858 — Windows/WSL cannot unify one shared transcript directory (different host + volume). Same fingerprint family, different cause.
• Usage → Limits merges two Codex subscriptions that share an email address #10835 / bug: /usage-limits counts the same subscription more than once #10701 / Usage view misreports limits with multi-account Codex routing #11515 — Limits account merging, not host identity.
• fix(server): let multiple servers on one host show distinct environment labels #7924 (closed, unmerged) — T3CODE_ENVIRONMENT_LABEL for same-host label clashes. Related to hostname-as-label only.
• No open/merged PR changes this hostId. There is no T3CODE_HOST_ID (T3CODE_HOST is the bind address).

Suggested fix

Do not blindly put environment-id in fingerprint.hostId. Two worktree servers already have different environment ids and the same hostname + provider home + volumeId; that shared hostname is what collapses them. Using environment id would double-count.

Prefer a host-stable id that stays the same across worktrees on one machine and across container recreates:

1. Persist the first-seen hostname (or a dedicated host-id) on the T3 volume and reuse it after recreate; and/or
2. Honor an explicit T3CODE_HOST_ID for container deploys.

Keep os.hostname() as fallback. Separately, stop using the container ID as the display label (pretty name or an override). Compose hostname: remains a valid workaround.

Accepting as a minor bug. Workaround stands until that ships.