Running commands in a remote environment (SSH/Kubernetes) and persisting the target across sessions
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_
4 Comments
Is this something that could be resolved with
AGENTS.md?I think it is not mature enough to just using remote tools with
AGENTS.mdwithout failures and slowdown parsing issue as it has a lot of assumption to work locally.So probably the best solution is to find a way to communicate directly with (its own subagent?) installed and running inside the remote env.
I’m running into a similar issue. In my setup, I have a remote development machine with a GPU already configured. My typical workflow is to edit files locally and use watchexec + rsync to sync them to the remote GPU machine for debugging.
I’ve already set up SSH access through my ~/.ssh/config, and I can manually SSH into the GPU server without problems. However, Codex doesn’t seem to recognize or use my SSH configuration — it can’t execute commands on the remote GPU machine directly.
Thanks for the feature request. This hasn't received enough upvotes or interest since it was opened, so I'm going to close it.