Extend the server-update notice pattern to remote provider updates

[vitalyiegorov]

Before submitting

• I searched existing issues and Ideas discussions.
• This describes a concrete use case.

Area

Providers, Connections, chat composer (web and desktop).

Problem or use case

When Claude Code or Codex has a newer release on my local machine, T3 Code tells me at launch and offers a one-click update. When the same CLI is outdated on a remote environment (SSH, relay, or T3 Connect), nothing tells me. I find out when the agent misbehaves, or when I open Settings → Providers, pick the right connection, pick the right instance, and notice the small update arrow.

With several always-on machines and several Claude instances per machine, this is a daily chore. The T3 server on those same machines already has the good version of this: a notice above the composer with an Update server button.

Proposed solution

Show a provider update notice above the composer for the remote environment that owns the open thread, in the same stack as the server update notice.

• Copy: "Claude Code v2.1.270 is available on Mac Studio", with Update and Dismiss.
• Update runs the existing server.updateProvider request for that environment and instance. The notice shows running and failed states from the updateState the server already publishes per provider, and offers Retry on failure.
• The notice appears only when the server can run the update itself. Installs it cannot prove ownership of keep the manual command in Settings, as today.
• Dismiss remembers environment, provider, instance, and target version, so the notice returns only for a newer release.
• Local environments keep the launch toast and never get the notice, so nothing is shown twice.

No automatic updates. The click stays with the user.

Why this matters

Remote environments are core to T3 Code. Users on T3 Connect or Tailscale drive agents on machines they never look at directly. Today those machines silently fall behind on provider CLIs, and the fix is three clicks deep in Settings. #3598 solved the same problem for the T3 server with a one-click notice. This extends that pattern to provider CLIs.

Smallest useful scope

Web and desktop only. One notice for the active thread's environment, driven by data the client already receives (versionAdvisory and updateState on each environment's provider snapshot) and the existing server.updateProvider request. No new wire contract, no server changes, no polling changes. Mobile has no provider update UI yet and can follow later.

Alternatives considered

• Extend the launch toast to remote environments. Smaller diff, but it pops for every connection at launch and prompts about machines the user is not working on.
• Automatic provider updates across environments ([Feature]: Automatically update supported provider CLIs across connected environments #6893). In [Feature]: Update providers without asking #2993 the maintainers stated provider updates stay user-controlled, citing enterprise-managed installs from [Feature]: Disable provider update for enterprise users with managed updates #2818. This proposal keeps the click.
• Badge on Settings → Connections only. Still requires the user to go looking.

Risks or tradeoffs

• The notice does not check for running turns. Clicking it mid-turn is the same as clicking Update now in Settings today.
• Installer detection has had several recent fixes (mise, pnpm, Chocolatey, Homebrew). The notice reuses that logic unchanged.
• On a badly outdated machine the server notice and the provider notice can stack. The server notice keeps priority.

Examples or references

• Add one-click update for remote environment version drift #3598 one-click update for remote server version drift (shipped via fix(web): align remote server update action #4731, fix(web): show server update progress through reconnect #4903, fix(server): make remote updates rollback-safe #5181)
• [Feature]: Update providers without asking #2993 automatic provider updates, closed: "Provider updates will remain user-controlled"
• [Feature]: Automatically update supported provider CLIs across connected environments #6893 automatically update provider CLIs across environments (open)
• Clear provider update actions while updating #4676 clear provider update actions while updating
• fix(web): refine server update notice #9744 refine server update notice

Contribution

• I would be open to helping implement this.

[vitalyiegorov]

Implemented in #10343 with screenshots and a short video of the flow.

[vitalyiegorov]

Update: I closed #10343 for now. The gap is still real on main (the launch popover excludes remote targets and nothing updates providers automatically), but the remote CLIs on my machines have mostly kept themselves current via their own installers, so the daily chore shrank. Reopenable if others hit it.