First, thank you for supacode — it's become my daily driver for running coding agents in parallel, and the terminal + worktree orchestration is the nicest I've used.
I'd love first-class support for opening and working in git repositories that live on another machine over SSH, without cloning them locally.
Why I need it: my real dev environment — a more powerful box with local MCP servers, databases, and private tooling — lives on a remote machine, while I'm usually on a laptop. Today supacode only manages local repos, so its terminal + agent orchestration can't reach those remote repos.
Proof of concept (rough, still dogfooding): I hacked together a working fork that implements this by reusing supacode's architecture rather than bolting on a parallel path. It's a self-use build — honestly pretty rough and not production-grade — but it works end to end and I run it daily:
- SSH transport behind a single
ShellClient chokepoint — GitClient(shell: .ssh(host:)) routes every git/wt shell-out over SSH (ControlMaster multiplexing); nothing else in the stack has to change.
- Remote repos render in the sidebar as real git (a Local/Remote partition), picked from
~/.ssh/config or the host's own supacode config.
- Remote worktree create/list, HEAD polling, host-aware diff/PR.
- Agent awaiting-input + notifications bridged over in-band OSC 9 (the local Unix socket can't cross SSH), reusing the existing presence pipeline.
Fork (self-use PoC): https://github.com/lmjiang/supacode — squashed into main (85c0d18).
I'm not expecting a straight merge — it's a personal build and I know remote support is a big surface with real maintenance cost. I mostly want to (1) register the need and (2) leave a concrete reference in case you ever consider native support. Happy to discuss the design — and thanks again for building this.
First, thank you for supacode — it's become my daily driver for running coding agents in parallel, and the terminal + worktree orchestration is the nicest I've used.
I'd love first-class support for opening and working in git repositories that live on another machine over SSH, without cloning them locally.
Why I need it: my real dev environment — a more powerful box with local MCP servers, databases, and private tooling — lives on a remote machine, while I'm usually on a laptop. Today supacode only manages local repos, so its terminal + agent orchestration can't reach those remote repos.
Proof of concept (rough, still dogfooding): I hacked together a working fork that implements this by reusing supacode's architecture rather than bolting on a parallel path. It's a self-use build — honestly pretty rough and not production-grade — but it works end to end and I run it daily:
ShellClientchokepoint —GitClient(shell: .ssh(host:))routes every git/wtshell-out over SSH (ControlMaster multiplexing); nothing else in the stack has to change.~/.ssh/configor the host's own supacode config.Fork (self-use PoC): https://github.com/lmjiang/supacode — squashed into
main(85c0d18).I'm not expecting a straight merge — it's a personal build and I know remote support is a big surface with real maintenance cost. I mostly want to (1) register the need and (2) leave a concrete reference in case you ever consider native support. Happy to discuss the design — and thanks again for building this.