Running commands in a remote environment (SSH/Kubernetes) and persisting the target across sessions

Resolved 💬 4 comments Opened Aug 28, 2025 by bhack Closed Nov 28, 2025

What feature would you like to see?

I couldn’t find a clear way in the docs to have commands execute in a remote environment while developing locally (considering also the your new VScode extension).
This is a common workflow (e.g., skaffold dev, remote over SSH, or kubectl exec) where code is edited locally but runs on a remote host/cluster automatically synced in realtime.

What I tried / current behavior

Prefixing commands with ssh user@host ... or using kubectl exec ... as a workaround.

Storing the target (host/cluster) in session state.

These approaches feel ad-hoc and don’t persist well—every new session seems to forget the target, and I don’t see a standard, documented way to set or rehydrate this.

What I expected
Either:

Documentation with best practices/recipes for remote execution, including:

SSH targets (auth, agent/keys, multiplexing, timeouts).

Kubernetes targets (kubectl exec, contexts/namespaces, port-forwarding).

How to persist the chosen target across sessions.

Security considerations (credential handling, auditing).

or

Feature support to set a first-class execution target for a session—e.g., an option to bind a session to ssh://user@host or to a Kubernetes context/namespace—so subsequent commands run there without manual prefixes, and this configuration survives new sessions.

Why this matters
Remote execution is a very typical setup for modern dev loops (e.g., skaffold dev and similar), and first-class guidance or support would reduce friction and prevent brittle workarounds.

Questions

Is there an existing, recommended way to do this that I missed in the docs?

If not, would you consider documenting an approach or treating this as a feature request?

Are you interested in implementing this feature?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗