[Feature Request] Native SSH support for running workspaces/sessions on remote machines

[adamatan]

Problem / use case

I run Claude on a few always-on machines: two Raspberry Pis at home and an EC2 instance on AWS. Right now the only way to work with those sessions from Termic is to SSH in manually from a plain terminal outside the app, so none of Termic's workspace UI (tabs, file tree, diff pane, sidebar, sandboxing) applies to that work. Every terminal in Termic (shell, agent CLI, custom command) spawns a local PTY via portable-pty on the machine running Termic itself, and there's no way to point a workspace at a remote host instead.

Concretely: I want to keep Termic's workspace UI on my laptop, but have the actual git worktree, agent process, and shell live on one of these remote boxes over SSH, the way e.g. VS Code Remote-SSH or Tailscale-backed dev environments do.

Current behavior

• All PTYs are spawned locally (src-tauri/src/lib.rs, via portable-pty); there's no remote-host concept anywhere in Workspace/Project types.
• ~/.ssh shows up only as a sandbox secrets path to deny/allow (src-tauri/src/sandbox.rs, docs/sandbox.md) — unrelated to remote execution.
• The only "SSH" workflow today is typing ssh <host> as an arbitrary custom command in a locally-spawned terminal (CustomCommandDialog.tsx), which doesn't extend to file tree, diff pane, or worktree creation against the remote filesystem.

Proposed solution

Add native remote-workspace support over SSH:

1. A Project can be an SSH host + repo combo, not just a local repo path: host, user, identity file / agent-forwarding, and a repo path on that host. Every workspace (worktree) created under that project lives on the remote host, inheriting its connection config, so remote-vs-local is decided once per project rather than fiddled with per workspace.
2. PTY spawn over SSH instead of local portable-pty for any workspace under a remote project (e.g. shell out to ssh with a PTY, or use a Rust SSH client crate directly for tighter control over env/signals).
3. Remote file/git operations: file tree reads, diff pane, and worktree creation (git worktree add etc.) need to operate against the remote filesystem, likely via SFTP or ssh <host> git ... rather than local std::fs/git2.
4. Sandbox interaction: decide how (or whether) the existing sandbox-exec model applies when the process itself is remote — likely sandboxing happens on the remote host's side, if at all.
5. Auth: rely on the user's existing ~/.ssh config/agent rather than storing credentials in Termic.

Scope / open questions

• Do we shell out to the system ssh/scp binaries (simplest, reuses user's existing config/known_hosts) or use a Rust SSH library for more control?
• How much of the file tree / diff / editor experience needs to work remotely for a first cut vs. just remote terminals (shell + agent) with local-only file browsing disabled?
• Latency/perf: xterm.js output over a real network hop is a different perf profile than a local PTY, worth prototyping before committing to UI changes.
• Per-project key override: do we let a project specify its own identity file (e.g. a dedicated key for the EC2 box vs. the Pis), overriding whatever ~/.ssh/config would normally pick for that host, or always defer to the user's existing SSH config?

Happy to scope this down to a v1 (remote shell + agent terminal only, no remote file tree) if that's a better starting point.