GSoC 2026: VSCode remote-ssh like feature in neovim

[Br41ni4c]

Hi all,

I'd like to start contributing to Neovim project as a part of GSoC 2026, specifically working on the native remote development experience referenced in #21635.

I'm aware of existing plugins like @inhesrom/remote-ssh.nvim that have covered significant ground here, and @siddhantdev's prior GSoC work on the :connect command (#34257, #34586) which already landed the ability for a TUI to detach and reattach to a different server. But compared to VS Code's Remote SSH, there's still a meaningful gap — particularly around having this as a cohesive, dependency-light experience built into Neovim itself. I intend to build on that existing foundation rather than start from scratch.

I'd like to approach this in three phases:

Phase 1: Remote-first bootstrap (MVP)

The core ask of this issue. A single command (e.g. :RemoteUI user@host) that:

• SSHs into the remote machine
• Checks for (and optionally auto-installs) nvim
• Starts a headless Neovim server on the remote
• Sets up an SSH tunnel and attaches the local TUI via --remote-ui

This gives us a working PoC for low-latency connections where remote-UI feels native. I've personally felt the pain of working with Neovim over SSH, so even this baseline would be a real improvement.

Building on existing work: The merged :connect command (#34586) already handles the TUI detach/reattach mechanics. This phase would wire up the SSH bootstrap flow that feeds into :connect — automating what's currently a manual process. The approach aligns with what @siddhantdev explored in #35510 (SSH tunneling for :connect ssh://address), addressing the tunnel lifecycle challenges discussed there.

Config/plugin sync: Following @theHamsta's suggestion in #21635 about "virtually adding local rtp to remote environment," this phase would include syncing the user's config and plugin modules to the remote. Three modes: upload init.lua (or a dedicated remote-init.lua), stream the full plugin tree (using nvim_paste into buffers or a zip+chunk approach as @justinmk suggested in #36822), or --clean mode for quick edits. Delegating as much as possible to ssh itself rather than parsing ~/.ssh/config directly, per @justinmk's guidance in #34257.

Session management: Building on #5035 (native detach/reattach, targeted for 0.13), the plan includes session listing, detach/reattach across connections, and reconnection with backoff on network disruption — so remote editing sessions survive transient disconnects.

Latency guidance: Addressing @jdrouhard's concern from #21635 that remote-UI becomes laggy on high-latency connections — on connect, the system probes round-trip latency and advises users when they'd be better served by the VFS approach in Phase 2.

Phase 2: Local-first editing via persistent RPC (VFS mode)

For higher-latency connections where remote-UI becomes laggy, an alternative model: Neovim runs locally with zero-latency editing, while file I/O, LSP, search, and file watching are delegated to a headless Neovim on the remote via a persistent RPC channel.

The initial plan is to use nvim_exec_lua for all remote operations — as @justinmk validated in #36822, "you can of course send entire scripts via nvim_exec_lua." This avoids any C code changes and keeps the prototype lean. The nvim_exec_lua approach also naturally supports the "offloading heavy processing" pattern discussed in #36822 — the same infrastructure that proxies file I/O could let plugins offload compute-intensive work (git operations, large file parsing) to a secondary Neovim instance.

If profiling reveals overhead concerns with shipping Lua source over the wire on every call, there's a clean upgrade path: #32117 (targeted for 0.13) would allow pre-registering named RPC method handlers on the remote, so operations become rpcrequest(chan, 'remote_read_file', path) instead of sending Lua strings each time. Native C APIs (nvim_workspace_*) remain a further optimization, but only if profiling justifies the maintenance burden.

Phase 3: Integration with remote-ssh.nvim

Rather than rebuilding all the UX polish from scratch, the idea is to enable remote-ssh.nvim to use the native vim.remote infrastructure as a backend. The plugin already has mature features — tree browser, session management, multi-terminal, statusline — that represent significant investment. Pairing that with an optimized, dependency-free transport layer (no more per-operation SSH/SCP spawning, no Python LSP proxy) could give us the best of both worlds.

This would be a separate effort coordinated with the plugin maintainer, not a core Neovim change.

---

I'll be making an official submission covering the technical details more extensively — including the auto-deploy cross-platform matrix (glibc/musl, macOS Intel/ARM, FreeBSD), the SSH tunnel lifecycle, security model (all traffic over SSH, direct TCP for local dev only), and container/devpod support (which falls out naturally from the SSH transport). But if there are any suggestions, concerns, or feedback on this direction, I'd really appreciate hearing them — it'll be instrumental in shaping the proposal to align with the community's vision.

Related issues/discussions for context:

• remote-ssh plugin (like vscode) #21635 — The original remote SSH tracking issue
• :connect to another Nvim server (dynamic detach/reattach, like screen/tmux) #5035 — Native detach/reattach (:connect, session persistence)
• Gsoc: Remote SSH Plan #34257 — @siddhantdev's GSoC remote SSH plan (closed/completed)
• feat(ui): :connect command #34586 — The merged :connect command PR
• GSoC: Neovim over SSH #35510 — SSH tunneling discussion for :connect ssh://
• headless neovim as custom "remote command handler" #36822 — nvim_exec_lua for remote command execution, config streaming
• RPC: plugins can handle incoming RPC requests #32117 — RPC method handlers for plugins (future optimization path)

[ramonsoarezcavalcante]

I’ve been using Zed editor recently and its built-in SSH remote development is exactly the kind of experience I wish Neovim had. You just do zed ssh://user@host/path (or via the menu) and it instantly gives you a full local-feeling editor with remote LSP, terminal, file tree, Git, etc. All while being extremely lightweight and fast.
Neovim already has a lot of the foundational pieces (:connect, --remote-ui, improved RPC, etc.). Turning this into a first-class, zero-dependency native feature similar to Zed (or VS Code Remote-SSH) would be a game-changer for many developers who work on remote servers, containers, or edge devices.
Huge thanks for putting together this detailed GSoC proposal, this is one of the features I’m most excited about for Neovim’s future. Count me in as a tester if it moves forward!

[justinmk]

Neovim already has a lot of the foundational pieces (:connect, --remote-ui, improved RPC,

indeed... ;)

the tracking issue is here:

• remote-ssh plugin (like vscode) #21635