Run providers locally against a remote VM workspace

[roerohan]

Before submitting

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

Area

Remote environments and providers

Problem or use case

I want to run projects inside ephemeral VMs while keeping my provider CLIs and personal configuration on my local machine.

Today, when T3 Code runs against a remote environment, the provider also runs there. Every VM needs provider CLIs, authentication, skills, MCPs, and Git credentials. This adds setup time and leaves sensitive configuration on machines that should be disposable.

Proposed solution

Allow a project to use a local provider with a remote workspace.

The local machine would run T3 Code, provider CLIs, skills, MCPs, and authentication. The VM would own project files, shell commands, builds, tests, Git operations, and checkpoints.

From the agent's point of view, the VM should be the workspace. Project commands must run in the VM and should never silently fall back to the local machine.

This could work over SSH or through a lightweight T3 worker inside the VM. Git authentication and commit signing could use SSH agent forwarding, so private keys remain local.

Why this matters

This would let VMs remain truly disposable.

• Provider credentials would not need to enter the VM.
• New VMs would require much less setup.
• Skills and MCPs would only need to be configured once.
• Switching providers would not require installing another CLI in the VM.
• Provider updates would happen once on the local machine.
• Several VMs could share the same local agent setup.
• Git keys could remain inside the local SSH agent.

Smallest useful scope

Start with one remote VM per project and one compatible provider.

The first version would need remote filesystem access, shell execution, Git operations, and T3 checkpoints. It should also show clear connection and failure states.

Alternatives considered

Running the full T3 backend and provider inside the VM works today, but it requires installing providers and storing their authentication and configuration in every VM.

SSHFS or repository mirroring may help with files, but commands, Git state, processes, and checkpoints can still run on the wrong machine or become inconsistent.

Risks or tradeoffs

Most provider CLIs execute their own filesystem and shell tools. T3 Code would need to redirect those operations to the VM, so support may need to be added provider by provider.

Disconnects, cancellation, remote path validation, attachments, and MCPs that need project access would also need clear behavior.

Examples or references

• Architecture proposal: first-class remote backend targets (with WSL as the first implementation) #671 covers first-class remote backend targets.
• [Feature]: Project-scoped SSH sessions for persistent remote development #1414 covers project-scoped SSH development.
• Reference fork: multi-host Codex source mirroring and remote parity #559 explores multi-host Codex support.

Those proposals run the provider in the remote environment. This request keeps the provider local while project tools run remotely.

Contribution

• I would be open to helping implement this.