Remote Development in Codex Desktop App

[pocca2048]

What feature would you like to see?

Feature Request: Remote Development Support

First of all, congratulations on the release of the Codex Desktop App.
It’s great to see Codex moving beyond the browser experience.

However, I noticed a significant limitation compared to my existing VS Code workflow.

Current Limitation

At the moment, Codex Desktop App only works with local projects.
It does not support development on remote hosts (e.g. via SSH, remote servers, or cloud machines).

In my daily workflow, I primarily develop using:

• VS Code Remote SSH
• Remote Linux servers / cloud instances
• Environments where the code does not live on my local machine

Because of this, I’m unable to use Codex Desktop App for most real-world development tasks.

Requested Feature

Support for remote development, similar to VS Code’s Remote Development features:

• SSH-based remote hosts
• Access to remote file systems
• Ability to run Codex against code that resides on a remote machine

Why This Matters

Many developers rely on remote environments for:

• Large-scale systems
• GPU / specialized hardware
• Secure or production-like setups
• Cloud-based development workflows

Without remote support, Codex Desktop App is difficult to adopt as a primary development tool.

Summary

Adding remote host support would:

• Enable Codex Desktop App to fit into existing professional workflows
• Significantly broaden its usability
• Make it a viable alternative or companion to VS Code in real-world setups

Thanks for considering this request!

Additional information

No response

[Cyfine]

Me too. Would like to see they add remote support for the app. The app feels so great comparing to CLI and VS Code Plugin.

[ht0324]

Bumping this.

I’m in a very similar situation. I regularly work with multiple remote machines and cloud instances, and today that means running separate Codex instances over SSH, usually parked inside tmux sessions on each remote host.

That setup technically works, but it’s extremely fragmented. I’m constantly jumping between tmux windows and SSH sessions just to see what each Codex instance is doing, which completely kills the experience.

The Codex Desktop App already feels like an agent manager when everything is local. But once the environment is remote, that abstraction disappears. Instead of managing agents, I’m back to manually babysitting terminals.

Remote host support (SSH + remote filesystem + remote run context) would turn this from a nice demo into something I can actually adopt.

[llkj11]

+1

Most of my projects live on my server and that's where I do most of my coding. Can't really use this app until remote through SSH is supported.

[haonan0x3a1]

Same here. Most of my work happens on remote servers via SSH (often GPU machines), so local-only projects limit adoption. Remote host or workspace support would be a significant improvement.

[Schuppenhauer]

Hi! This limitation is a real workflow blocker for me.

My setup: I develop on a remote Linux box (a small home server) via VS Code Remote SSH, so the “workspace” lives on the remote filesystem. Codex Desktop currently only works with local folders, which means I can’t use Codex on the same codebase without doing awkward sync steps (git/rsync/sshfs). That’s not just inconvenience — it breaks the tight edit/run/debug loop that Remote SSH enables.

A “cool” solution for the Codex app would be one of:
• Native support for Remote SSH / remote workspaces (similar to VS Code’s Remote extension)
• Or at least: connect to a remote agent that can read/write files + run commands on the remote host
• Or: first-class support for mounting / using remote folders reliably (with file watching, permissions, symlinks, etc.)

Even a basic MVP would help: open a remote folder, edit files, run a command remotely, and keep file watching stable.

Is remote workspace support on the roadmap? Any recommended best-practice workaround in the meantime?

[baumann-oai]

Thank you all for the feedback here! This is quickly becoming one of the most-requested features since we've launched the app.

A few questions so we can make sure we're taking this down the right path:

1. Is the ideal situation one where you can connect Codex to remote hosts but the experience of using Codex looks and feels the same as running it locally, including read/write/edit and running commands on that remote machine?

“Codex Desktop App only works with local projects.” (@pocca2048)
“Most of my projects live on my server… can’t really use this app until remote through SSH is supported.” (@llkj11)
“The ‘workspace’ lives on the remote filesystem… sync steps break the tight edit/run/debug loop.” (@Schuppenhauer)

2. Should the remote workspace be the single source of truth, meaning you should not need a local clone or any sync workaround (git/rsync/sshfs) to use Codex effectively?

“awkward sync steps (git/rsync/sshfs)… breaks the tight edit/run/debug loop.” (@Schuppenhauer)

3. Would you want the ability to configure multiple remote machines in Codex?

“I regularly work with multiple remote machines and cloud instances…” (@ht0324)

4. If yes, how would you expect that to show up in the app? Would remote machines behave more like projects you open, or like an execution option you choose per thread? I.e. Is there a folder for a given remote machine, OR is it set per-thread?

“The Codex Desktop App already feels like an agent manager when everything is local. But once the environment is remote, that abstraction disappears.” (@ht0324)

5. If you start work on a remote machine and then close the Codex app, should that work keep running remotely, and should you be able to come back later and pick up where you left off?

6. When you SSH today, do you typically work on the same machine the whole time, or do you usually connect to one machine and then start work on another machine after connecting?

If you can reply with short answers (even just “yes/no + a sentence”) that would be hugely helpful. We’re aiming to match the local experience as closely as possible while fitting into remote-first workflows. THank you!

[htahboub]

For me, the answer to 1 is yes. I think people are looking for a similar experience to what we have on vscode (and forks), zed, and others. You connect to your remote ssh server, you open a folder, and then the IDE is working as it would if that folder existed locally (albeit a bit slower).

Ideally, no local clone. Multiple remote machines would be good, probably also with support for connecting to servers specified in the ~/ssh/config file. For what the experience should look like, probably also similar to other IDEs: it should list your recent connections, including the folders you had open, and give the option to connect to a new one. When you choose one, it opens it like a project. See Zed's interface for reference, which stores which folders I've connected to for each host and also lists all the other hosts in my config (you can scroll through the list, not fully visible here):

For 5, definitely would be cool for it to keep working in the background, but I don't think that's strictly necessary. Being able to pick things up where you left off is important, though. And for 6, personally, I connect to one machine and work on it, but the specific machine I'm on changes from day to day depending on what's allocated to me. The filesystem/disk is always the same though, which is what should actually matter, as is the ssh command I would use to connect to it. Most in research that I know have a similar workflow to me, but people who want SSH support for other domains might do things differently.

[dwchoo]

Hi @baumann-oai — thanks for asking these questions. Short answers below:

1. Yes. Ideal is that using Codex on a remote host feels the same as local: read/write/edit + run commands on the remote machine, with the remote filesystem as the workspace.

2. Yes. The remote workspace should be the single source of truth (no required local clone or sync workarounds like git/rsync/sshfs).

3. Yes. I’d like to configure/use multiple remote machines.

4. Prefer “project/workspace” semantics: being able to open multiple remote locations as distinct projects/workspaces (similar to VS Code Remote SSH + Dev Containers). Then, inside a project, threads default to that remote context (optionally override per-thread if needed).

5. Yes. If I close the Codex app, work should keep running remotely and I should be able to reconnect later and continue. I currently use Codex CLI inside tmux specifically to keep long-running sessions alive—having first-class background sessions + reconnect would be huge.

6. Usually I work on one machine for a while, but I do switch between multiple remotes depending on the project/environment (e.g., different servers/containers).

If you align this with VS Code’s Remote SSH + Containers model (remote host + optional containerized workspace), that would fit my workflow really well. Thanks!

[ht0324]

Hi @baumann-oai , thanks for asking these. Context first: my day-to-day workflow is remote-first. I typically have 2, 3 remote machines and I connect via VS Code Remote Explorer (Remote SSH). On each remote host I start a tmux session and run Codex there, so the work keeps going even if I close my laptop or I’m on the go. That setup works today, but it’s fragmented: I’m constantly bouncing between SSH/tmux sessions just to see what each Codex instance is doing. The desktop app feels like it’s aiming to make the human an “agent PM” (a single place to orchestrate agents), but that abstraction collapses once the environments are remote.

Answers:

1. Yes. Ideal is that connecting to a remote host feels the same as local: read/write/edit plus running commands on that remote machine, as if the project were local.

2. Yes. The remote workspace should be the single source of truth. I do not want a required local clone or any sync workaround (git/rsync/sshfs) to use Codex effectively.

3. Yes. I want to configure and use multiple remote machines in Codex (this is literally my normal setup).

4. Prefer “project/workspace” semantics.

5. Absolutely yes. If I start work on a remote machine and close the Codex app, the work should keep running remotely, and I should be able to come back later and pick up where I left off. This is exactly why I use tmux today. It’s also analogous to the ChatGPT app: if I send a request to a thinking model and switch chats or close the app, the thinking continues and I can return to the result later. Same expectation for remote Codex sessions.

6. I often connect to multiple machines and then work in parallel across them (I’m trying to fully lean into the “delegate to agents” workflow). So I do switch between remotes frequently depending on what I’m running where.

Happy to answer any other questions!

[Schuppenhauer]

Hi @baumann-oai — thanks for the questions.

Short answers from @Schuppenhauer:

1.	Yes. Ideal is that a remote host feels the same as local: read/write/edit files and run commands on the remote machine, with the remote filesystem as the workspace.

2.	Yes. The remote workspace should be the single source of truth. I don’t want to require a local clone or sync workarounds (git/rsync/sshfs) to use Codex effectively — those break the tight edit/run/debug loop.

3.	Yes. I’d like to configure/use multiple remote machines (this is my normal setup: one home server + sometimes additional boxes/instances).

4.	Prefer “project/workspace” semantics. I want to open a remote host/path as a project/workspace (similar to VS Code Remote SSH). Then threads default to that remote context, with an optional per-thread override if needed.

5.	Yes. If I start work on a remote machine and close the Codex app, the work should keep running remotely, and I should be able to reconnect later and continue. Today I use VS Code Remote SSH + tmux to keep long-running sessions alive; first-class background sessions + reconnect would be huge.

6.	Both. I usually stay on one machine for a while per project, but I do switch between remotes depending on what I’m running where (different environments/services).

Context: my day-to-day workflow is remote-first (small server as the “Cube” runtime). Codex Desktop is great locally, but the value drops hard when the workspace is remote. If you align this with VS Code’s Remote SSH mental model (remote host + remote filesystem workspace + command execution), it would fit perfectly.

[safareli]

I for example have one vm running on my mac and i do all development in it. I would love to be able to open codex app in it. just like i can with vs code, where you type this in command pallet >Remote-SSH: connect to host ... and then it show all hosts you can connect to based on your ~/.ssh/config. so a simplest implementation would have some top level menu where you can select hosts and then app will become just a frontend and everything will happen in the remote host machine. vs code for example opon first connect installs it's headless executable in the remote machine.