Deep link to add or open a desktop-managed SSH environment

[TurpoFIN]

Problem

Tools that provision remote development machines already work well with T3 Code's desktop-managed SSH. The machine is an alias in ~/.ssh/config, T3 Code lists it under Add environment → SSH, and starts its server there. The last step is manual: the user opens Settings → Connections → Add environment → SSH, picks the alias, then adds the project folder.

An external tool can't do that step for the user today, and that's reasonable. t3 app opens local workspace roots only, and saved environments carry safeStorage-encrypted tokens, so writing them from outside would be wrong.

Proposal

A link the desktop app handles, for example:

t3code://environments/ssh?alias=<ssh-alias>&path=<absolute remote directory>

• If no saved environment uses that alias, run the existing Add environment → SSH flow after the user confirms the alias and host in a dialog. Then add or open the project at path on that environment and focus it.
• If the environment already exists, open the project on it.
• A matching link to forget a saved SSH environment by alias, for tools that delete the machine.

It reuses the existing SSH bootstrap and pairing, adds no new auth path, and nothing connects without the user's confirmation. The exact URL shape is yours to choose.

Who it helps

SSH-based sandboxes and cloud machines that already document T3 Code (for example Docker Sandboxes' T3 Code integration), and remote-agent setups like the ones discussed in #6677. One click from the provider's CLI into the right project in T3 Code.

Disclosure: I work on Shardflux, which provisions these per-project machines for coding agents and writes the SSH alias. I'm happy to implement it (desktop URL handler, validation, confirmation dialog, tests) if the direction and shape work for you.

[freeheel]

Another provisioning tool, same gap

+1. Here's our setup, as a second real-world case alongside Shardflux.

What we run. A small CLI on the developer's Mac (agent new <name>) creates one Incus container per coding agent on a shared Linux host. Each container gets its own IP, Docker, a fresh clone of the repo on the right branch, GitHub and Claude/Codex logins, and its dev-server ports published behind an auth proxy. The agent starts in a tmux session with a task brief and runs on its own. We usually have several going at once. For example, one repo has a "product" agent writing code through issue branches and PRs, and a "pm" agent curating the tracker and planning docs. Agents are short-lived: created for a task or a lane, deleted with agent rm when the work is merged.

Where T3 Code fits. T3 Code is how we watch and steer these agents. Every container is reachable as <name>.incus through one wildcard Host *.incus block with ProxyJump to the host. T3's desktop-managed SSH already works well with this: it starts its server in the container and everything runs remotely.

The gap. For every new agent we do everything else from the CLI, then switch to T3 and click Settings → Connections → Add environment → SSH, type the alias, wait for setup, and open /home/dev/work/<repo>. When the agent is deleted, its environment stays in T3 until someone removes it by hand. With several agents a day, this is the one repeated manual step left, and stale environments pile up. The CLI can't do it for us, and shouldn't: saved environments hold safeStorage-encrypted tokens, and t3 app only opens local folders.

Why the proposed link fits. agent new would end with open "t3code://environments/ssh?alias=<name>.incus&path=/home/dev/work/<repo>", and agent rm would call the matching forget link. It reuses T3's existing setup and pairing, adds no new way to authenticate, and the confirmation dialog keeps the user in control. Nothing about it is specific to Incus: Shardflux, Docker Sandboxes and anything else that writes an SSH alias would use it the same way.

One request on the shape. Host discovery skips Host patterns, so wildcard aliases like *.incus never appear in the Add environment picker. It would help if the link accepted any alias that ssh -G <alias> resolves, not only discovered hosts. The confirmation dialog still covers the safety side.

Happy to test a build against this setup, or to help with the implementation if that's useful.