[osmocomet]

What Changed

Adds an optional T3CODE_ENVIRONMENT_LABEL environment variable that overrides the environment name shown to connected clients.

The value is trimmed before use. Missing, empty, or whitespace-only values preserve the existing automatic label detection.

This only changes startup-time server configuration.

Why

Multiple T3 environments running on the same machine can resolve to the same host-derived label, making them difficult to distinguish in connected clients.

This provides a small declarative override for environments where the server process is configured externally.

This is intentionally narrower than #7267, which tackles the broader interactive renaming experience across clients and persistence.

This PR only covers the declarative startup-time case. I hope it can be useful as a small complementary option for headless or externally managed environments.

Related: #5623

Verification

• ServerEnvironmentLabel.test.ts: 10/10 passed
• Targeted lint passed
• Server typecheck passed
• git diff --check passed
• Built server bundle manually verified with T3CODE_ENVIRONMENT_LABEL="Development VM" and /.well-known/t3/environment

Checklist

• This PR is small and focused
• I explained what changed and why

Summary by CodeRabbit

• New Features

  • Server administrators can set a custom environment label displayed to connected clients.
  • Labels are trimmed before display; empty or whitespace-only values continue using the automatically detected label.

• Documentation

  • Added installation documentation for configuring the custom environment label.

[macroscopeapp]

Approvability

Verdict: Approved at 00a3f6a

Macroscope's review found this PR approvable — This adds a small opt-in server environment variable that trims and overrides only the existing environment label while preserving automatic detection for unset or blank values. The runtime change is isolated to startup label resolution and is covered by focused tests, with documentation added separately.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 62fdd5ad-8c50-481a-8228-5bf8cd70c16f

📥 Commits

Reviewing files that changed from the base of the PR and between 7a326c2 and 00a3f6a.

📒 Files selected for processing (3)

• apps/server/src/environment/ServerEnvironmentLabel.test.ts
• apps/server/src/environment/ServerEnvironmentLabel.ts
• docs/user/install.md

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The server now supports T3CODE_ENVIRONMENT_LABEL. Non-empty values are trimmed and used as the server label. Empty values use the existing hostname fallback. Tests and installation documentation cover this behavior.

Changes

Environment label override

Layer / File(s)	Summary
Configured label resolution apps/server/src/environment/ServerEnvironmentLabel.ts	resolveServerEnvironmentLabel reads and normalizes T3CODE_ENVIRONMENT_LABEL before using the existing fallback chain.
Override validation and documentation apps/server/src/environment/ServerEnvironmentLabel.test.ts, docs/user/install.md	Tests cover trimmed labels, empty values, whitespace-only values, and fallback behavior. Installation documentation describes the variable and its usage.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Suggested reviewers: juliusmarminge

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding a server environment label override.
Description check	✅ Passed	The description explains what changed, why it changed, scope limitations, verification results, and checklist status. The omitted UI Changes section is not applicable because this PR does not change t…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}

[christhomas]

Another use case for this, from a slightly different angle: multiple Claude Code accounts on a single server.

I run two t3 serve instances on one machine, each with its own T3CODE_HOME and its own CLAUDE_CONFIG_DIR, so each environment is signed into a different Claude account. It works well — but both are derived from the same hostname, so they appear identically in the clients and there is no way to tell which one I am about to open.

T3CODE_ENVIRONMENT_LABEL as proposed here would solve that cleanly for this setup. Both instances are systemd units, so the label becomes one more Environment= line: declarative, no UI step, and it survives a rebuild. That is a real advantage over a UI-only rename for anyone running headless.

Two things I would add:

1. Icon override too. environmentIcon is currently only settable from inside the app, and both of mine defaulted to server — so the name and the icon are identical. If the label is overridable at startup, the icon should be as well. Otherwise a headless setup still has nothing to differentiate on.

2. First-class Claude profiles. Today, getting two Claude accounts onto one machine means hand-rolling it in the terminal: a separate CLAUDE_CONFIG_DIR per service, plus a script to symlink the shared parts (projects, sessions, session-env, plugins, settings.json) back to a single backend so that only credentials and per-account state stay separate. That pattern works extremely well, and it would be far more powerful as a feature than as something everyone reinvents.

Concretely, it would be useful to:

• create and manage multiple Claude profiles from the app rather than the terminal
• choose, per profile, whether sessions and workspaces are shared across profiles (one backend, different credentials) or kept as fully separate accounts

The shared-backend-with-separate-credentials case is the interesting one. Plenty of people run more than one Claude account simply for more usage headroom, and in that situation you do not want two disconnected worlds — you want one set of projects and sessions, with the ability to switch which credential is doing the work.

Happy to test this branch against a two-environment headless setup if that would help.

Dismissing prior approval to re-evaluate 00a3f6a

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Hi! We are cleaning up open PRs, and this one does not say which model or harness was used to create it. If this change is really important, we recommend rebuilding the PR with a newer model and noting the model and harness in the PR description.