[Feature Request] Add remote and server ssh controls

[JushBJJ]

Problem

Whenever I go outside like on a car, library, or plane, I want to keep working with my agents on-the-go. Right now I just spin up a terminal, which can be painfully slow and high-latency when typing , scrolling to read agent outputs, switching zellij tabs, etc.

Solution

ComputerA (Outside) <---> ssh connection <---> Computer B (Gooey-pi server)

By having a way to say have a ssh server running on my main computer, then opening up gooey-pi installed on my macbook for example, I can quickly start getting to work fast without having the hassle of dealing with UX lag that GUIs dont suffer as much with. The experience of developing would be much smoother compared to in the terminal. Whenever I need to review or edit code manually of my agents, I would open up Zed on my macbook and immediately start working because its GUI-based, i dont have to wait 5 seconds for neovim to scroll up the next set of lines just because im not at home.

[am-will]

thank you. yeah i'm going to do this.

[devin-ai-integration]

Thank you, @JushBJJ, for writing this up so clearly. The concrete scenario (harnesses running on your home machine, GUI on the laptop, plain SSH terminals being too laggy for typing and scrolling) is exactly the kind of detail that makes a request actionable, and it lines up well with what GooeyPi is meant to be: one place to drive local and remote agents. I did a full viability review of the idea against the current codebase, and I want to share the outcome honestly.

Outcome: deferred, not rejected. The goal is a good one and we want it. It is just much larger than it looks, so it is out of scope for the current milestone.

Why it is bigger than it looks

The whole backend assumes the harness, the project directory, and the app all live on the same machine:

• Harness runtimes are spawned locally (electron/main/agent-rpc/runtime.ts:138), and the comment just above notes that pi depends on the process cwd being the authorized directory. Terminals are local node-pty (electron/main/terminal.ts:7), git runs local executables (electron/main/git.ts), and session transcripts are read straight from disk (electron/main/sessions/*).
• Project grants are pinned by filesystem fingerprints (dev, ino, birthtimeNs in electron/main/projects.ts:105-122). Inode identity means nothing across an SSH boundary or through sshfs, so the project authority model itself has to become host-aware.
• Prime follow-ups go through a local unix socket and verify the socket owner matches the current uid (electron/main/agent-daemon.ts:13-22), which cannot cross hosts.
• Agent capabilities (session collaboration tools, schedules, terminal read, the agent browser) are HTTP brokers bound to 127.0.0.1 with a per-runtime token in the child env (electron/main/lib/capability-bridge.ts:69,79). A harness on a remote host would silently lose all of those tools unless the brokers move to the remote side too. This is the least obvious consequence and the most security-sensitive one.

Because of the above, the tempting shortcut ("just prefix every spawn with ssh host ...") does not actually work: the child would run remotely while cwd checks, inode grants, the daemon socket, and the loopback brokers all stay on the laptop.

The direction that would work

The good news is there is a clean seam. Every IPC handler dispatches through the Services interface in electron/main/ipc.ts:21-48, and the renderer only ever sees the preload bridge. The right shape is the VS Code Remote-SSH model: a small headless gooeypi-remote Node agent installed on the home machine, reached by spawning the system ssh with an argv array and speaking the existing JSONL RPC framing over stdio, with RemoteSessionService, RemoteAgentRpcManager, and friends plugging in behind Services while local mode stays untouched. Inherently local members (browser, voice, updates, pets, menu and theme) stay local. It would land in phases: first remote session reads plus start/prompt/steer/stop of a remote harness (which alone fixes the lag you described), then remote terminal and git, then the capability brokers on the remote side.

What would be needed to pick this up

A short design note (docs/remote-hosts.md) covering the trust model and ssh argv hardening, then phase 1 behind a settings flag with tests for the transport handshake and the service proxies. If you are interested in helping shape that design note, your real-world setup would be very useful input.

Thanks again for raising this. It is staying open as a tracked feature request, and I will link the design work here when it starts.