Repository navigation
Description
Symptom
After decommissioning a server that was linked via t3 connect, its environment stays in every client's Remote environments list forever (showing e.g. "Available · Relay offline"), and no client offers a way to remove it.
Corrected diagnosis (edit)
An earlier version of this issue claimed the relay has no DELETE route — that was wrong, apologies. After reading the relay handler and SQL: the owner-scoped delete already exists end-to-end (DELETE /v1/client/environment-links/:environmentId, packages/contracts/src/relay.ts, behind RelayClientAuth; handler → EnvironmentLinks.revokeForUser, a soft revoke that never contacts the environment — so it works fine for a dead server, and listForUser filters revoked rows immediately). ManagedRelayClient.unlinkEnvironment is already a client method.
The actual gap: nothing user-reachable ever calls it for a foreign/dead environment.
t3 connect unlinkis self-targeted (needs the machine's own OAuth token + local environment id file).- Web's
unlinkPrimaryEnvironmentFromCloudcalls the environment's own/api/connect/unlinkfirst — useless when the server is gone. - Mobile's "Remove environment?" is device-local only (no HTTP), and the row returns via discovery.
- Desktop/web relay rows (
CloudEnvironmentConnectList.tsx) render no Remove control (Allow failed remote environments to be removed #4084's Remove only covers backend rows). - No stale eviction either (
relay_environment_linkshas no lastSeen/expiry column; the only relay cron touches DPoP proofs and terminal activity).
How we removed ours (only worked by luck)
The decommissioned server still existed powered off, so we attached a temp IP, booted it, and ran t3 connect unlink ("Revoked the relay-side environment record") — not possible when a server is truly destroyed, which is the normal decommission case.
Suggestion
Expose the existing endpoint in the clients: a remove(environmentId) on the relay environment discovery service plus a Remove button on unsaved relay rows. We have a small validated patch for exactly this (4 files incl. tests; client-runtime 510/510, apps/web 1747/1747, typecheck/lint clean) and are happy to open it as a PR if the approach sounds acceptable. Relay-side stale eviction would be a separate, infra-touching change and doesn't seem required.
Related: #4084, #5129/#5132, #5130/#5133.
🤖 Generated with Claude Code
Activity
pplytas commentedon Aug 8, 2026
Confirming this on macOS with T3 Code
0.0.33-nightly.20260808.1031.In my case, I renamed the current Mac. T3 Connect then showed the renamed machine as a new environment while retaining the previous environment record,
Panagiotis’s MacBook Pro, asAvailable · Relay offline. The stale row only offers Connect; there is no account-side Remove or Unlink action.This is the same physical Mac, not a deliberately decommissioned remote server, so renaming or re-registering a machine is another path that can create an orphaned relay record. Running
t3 connect unlinklocally is not a safe workaround because it targets the current environment ID rather than the stale record.PR #5494 appears to provide the UI behavior I need.
fix(web): keep a first untimed sub-agent section under its parent