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
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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 ↗

4 Comments

0xdevalias · 11 months ago
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.

Is this something that could be resolved with AGENTS.md?

bhack · 11 months ago

I think it is not mature enough to just using remote tools with AGENTS.md without 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.

areslp · 10 months ago

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.

etraut-openai contributor · 9 months ago

Thanks for the feature request. This hasn't received enough upvotes or interest since it was opened, so I'm going to close it.