[Feature]: Automatically update supported provider CLIs across connected environments

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Provider management, desktop settings, T3 Connect / remote environments, and provider health checks

Problem or use case

T3 Code detects when supported provider CLIs such as Claude Code, Codex, or OpenCode have updates available and presents an Update provider action. I do not want to approve routine provider updates manually every time.

This is especially frustrating across multiple T3 Connect environments. A remote machine may require a provider update before I can continue working, forcing me to interrupt the workflow, approve the update for that machine, wait for it to finish, and reconnect.

I want to opt in once and have supported provider CLIs remain current automatically on all configured environments.

Proposed solution

Add an Automatically update provider CLIs setting.

The policy should be provider-aware and environment-aware, with a simple global option for users who want every supported CLI on every configured T3 Connect machine to remain updated.

Expected behavior

• Add an Automatically update provider CLIs setting.
• Allow the policy to apply to:
  • this environment only; or
  • all configured T3 Connect environments.
• Allow optional per-provider and per-environment overrides.
• When T3 would normally show an Update provider button, perform the update automatically when the policy permits it.
• Update only when that provider has no active session, unless the update is proven safe without interruption.
• Validate the provider after updating before reporting success.
• Show each environment and provider as current, pending until idle, updating, failed, pinned, or externally managed.
• Preserve configured provider installation paths, homes, accounts, authentication, and custom settings.
• Surface an actionable error when permissions or installation ownership prevent an unattended update.

Installation ownership and safety

T3 should only update a provider installation it can identify and manage safely.

If a provider CLI is custom, externally managed, version-pinned, installed through an unsupported package manager, or shared with another workflow, T3 should not silently replace it. Instead, it should explain why automatic updates are unavailable and provide the appropriate manual update action.

Automatic updates must not:

• terminate active provider sessions;
• overwrite custom binaries or provider-home paths;
• switch accounts or authentication state;
• silently change release channels;
• ignore explicit version pins.

Settings model

A useful settings structure could include:

• Provider automatic updates: Off / When idle / Scheduled
• Apply to: This environment / All connected environments
• Per-provider toggles
• Per-environment overrides
• Optional version pins or update holds

A simpler MVP could provide one Automatically update supported provider CLIs when idle toggle, applied per environment, plus an action to copy that preference to all connected environments.

Remote environment behavior

From any T3 client, I should be able to see whether each provider on each connected environment:

• has automatic updates enabled;
• is current;
• has an update waiting for sessions to become idle;
• is updating;
• failed and needs attention;
• cannot be managed automatically.

Notifications should identify the exact provider and environment instead of only saying that another machine requires an update.

Why this matters

Provider version drift can cause inconsistent behavior across machines and can block remote sessions at the moment I need them. Repeated manual approvals undermine the value of using T3 Code as a multi-environment remote interface.

An opt-in unattended policy would keep supported provider CLIs current while preserving active sessions and respecting custom or pinned installations.

Smallest useful scope

• One Automatically update supported provider CLIs when idle setting.
• Store the setting per environment.
• Allow applying it to all currently configured T3 Connect environments.
• Never update while the relevant provider has an active session.
• Validate the CLI after updating.
• Show clear pending, success, and failure status remotely.

Related but distinct issue

• [Feature]: Automatically update T3 Code across connected environments #5513 covers automatically updating the T3 Code application/server itself. This issue is limited to the external provider CLIs T3 Code launches and manages.

Risks or tradeoffs

• Providers use different installers, package managers, release channels, and filesystem layouts.
• A provider update may introduce breaking changes even when T3 Code itself has not changed.
• Rollback may not be equally available for every provider.
• Global settings must not override deliberate version pins or custom installations.
• Updating provider session formats may affect native resume behavior, so compatibility and validation matter.