[Bug]: The environment label appears to come from the macOS, i will fix it self#25505

opened16d agobyJJolymmiles

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Problem The environment label appears to come from the macOS ComputerName (e.g. "User1’s MacBook Pro"). ComputerName and LocalHostName are machine-wide, so when one Mac has several user accounts (here user1 and user2), every account's T3 environment gets the same label. From the label alone there's no way to tell which account a thread runs under.

Repro

  1. On one Mac with two user accounts, run T3 under user2.
  2. scutil --set ComputerName "MacBook Pro (user1)", then restart T3.
  3. The environment label shows "MacBook Pro (user1)" while whoami in the thread returns user2.

Changing LocalHostName doesn't affect the label. Version: 0.1.3-nightly.20261026.3717, darwin arm64.

Expected / proposal

  • Allow a custom environment label that overrides ComputerName, or
  • include the OS username in the default label, e.g. "MacBook Pro · user2".

Expected behavior

Problem The environment label appears to come from the macOS ComputerName (e.g. "User1’s MacBook Pro"). ComputerName and LocalHostName are machine-wide, so when one Mac has several user accounts (here user1 and user2), every account's T3 environment gets the same label. From the label alone there's no way to tell which account a thread runs under.

Repro

  1. On one Mac with two user accounts, run T3 under user2.
  2. scutil --set ComputerName "MacBook Pro (user1)", then restart T3.
  3. The environment label shows "MacBook Pro (user1)" while whoami in the thread returns user2.

Changing LocalHostName doesn't affect the label. Version: 0.1.3-nightly.20261026.3717, darwin arm64.

Expected / proposal

  • Allow a custom environment label that overrides ComputerName, or
  • include the OS username in the default label, e.g. "MacBook Pro · user2".

Actual behavior

Problem The environment label appears to come from the macOS ComputerName (e.g. "User1’s MacBook Pro"). ComputerName and LocalHostName are machine-wide, so when one Mac has several user accounts (here user1 and user2), every account's T3 environment gets the same label. From the label alone there's no way to tell which account a thread runs under.

Repro

  1. On one Mac with two user accounts, run T3 under user2.
  2. scutil --set ComputerName "MacBook Pro (user1)", then restart T3.
  3. The environment label shows "MacBook Pro (user1)" while whoami in the thread returns user2.

Changing LocalHostName doesn't affect the label. Version: 0.1.3-nightly.20261026.3717, darwin arm64.

Expected / proposal

  • Allow a custom environment label that overrides ComputerName, or
  • include the OS username in the default label, e.g. "MacBook Pro · user2".

Impact

Blocks work completely

Version or commit

No response

Environment

No response

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

No response

Synced from GitHub

Same problem on Linux, with three user accounts on one headless server, each running its own t3 serve.

What happens All three servers report the same environment label (the machine's pretty hostname). Clients and linked environments can't tell which account an environment or thread belongs to. Settings → Connections has an Icon picker but no way to rename.

Diagnosis On Linux, resolveServerEnvironmentLabel (apps/server/src/environment/ServerEnvironmentLabel.ts, unchanged on main) takes PRETTY_HOSTNAME from /etc/machine-info, then hostnamectl --pretty, then os.hostname(). All three are machine-wide. There's no CLI flag, env var or server setting to override the label for one server, so per-account names aren't possible. The only workaround is to edit /etc/machine-info, which renames every server on the host at once.

Repro

  1. On one Linux host with PRETTY_HOSTNAME=<host> in /etc/machine-info, run t3 serve under two different user accounts.
  2. Read each server's /.well-known/t3/environment, or link one to the other with t3 environment link.
  3. Both report label: "<host>".

Environment Ubuntu 26.04.1 LTS, x64. Servers on 0.1.5-nightly.20261029.3877 and 0.1.3.

Suggested fix (same as the proposal above): a per-server label override (setting, --label flag or env var), or a default that includes the OS username when other T3 servers run on the same host. Related: #13057, discussion #23118.

Investigated and written by Claude Opus 5.5 via Claude Code, following the T3 Code triage playbook.

Synced from GitHub

Another report of the same problem on macOS: two user accounts on one Mac, each running its own t3 serve as a separate launchd daemon (ports 3773 and 3774).

What happens: Both servers report the same label, the machine-wide macOS ComputerName (in this case <ComputerName> (2)). In Settings → Environments the two entries can only be told apart by port, and the port isn't part of the name. The row's actions menu has Icon, Routes, Copy MCP URL and Remove, but no Rename.

Confirmed in source: At v0.1.6, resolveServerEnvironmentLabel (apps/server/src/environment/ServerEnvironmentLabel.ts) returns scutil --get ComputerName, then falls back to os.hostname(), then to the cwd basename. There is no env var, flag or setting to override it. The file has not changed on main since 2026-10-09.

Would help: A per-server label override, through a setting or a t3 serve --label flag or env var. Or make the default user@machine when other accounts on the host are also running a server.

Environment: T3 Code server 0.1.6 on both accounts (CLI archive install, shared runtime), macOS 27.2 (darwin arm64), connecting from the web client.

Investigated with t3 triage by Claude Code (Claude Opus 5.5).

Synced from GitHub

Same problem here: Linux, two user accounts on one machine, each with its own T3 server. In the desktop app both environments show the same name in every place, so I can't tell which account a thread runs under. The only difference is the icon.

#32333 (T3CODE_ENVIRONMENT_LABEL) would fix this for my setup. A Rename… item in the environment menu (as in #25512) would also be good for desktop users who don't set environment variables.