Remote Development in Codex Desktop App

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

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.

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.

+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.

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.

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?

@pocca2048

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:

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)

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)

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

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

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)

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?
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!

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.

@baumann-oai

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

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.
Yes. The remote workspace should be the single source of truth (no required local clone or sync workarounds like git/rsync/sshfs).
Yes. I’d like to configure/use multiple remote machines.
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).
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.
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!

@baumann-oai

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:

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.
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.
Yes. I want to configure and use multiple remote machines in Codex (this is literally my normal setup).
Prefer “project/workspace” semantics.
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.
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!

@baumann-oai

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.

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.

A few questions to ensure we’re on the right track:

1.) Is the ideal scenario one where you can connect Codex to remote hosts, but the user experience remains consistent with running it locally, including read/write/edit functionalities and executing commands on the remote machine?

Yes, this is essentially the core feature set of every IDE available on the market. I set up a remote host workspace, and that’s it. Even your own embedded Codex works within that environment, allowing me to use both the cursor/Codex, Windsurf/Codex, and GitHub/Codex. Notice the common Codex that acts as my built-in reviewer and centralized context, as it’s always available in each. This enables me to use my development credits and model preferences in each while maintaining Codex as the common thread. This setup works exceptionally well when using Codex as a UAT agent. Apart from the copy-paste nature of a true SDLC lifecycle between them, it’s great. (Letting my Coding Agent and UAT agent work autonomously would be a dream come true.)

2.) Should the remote workspace be the sole source of truth, eliminating the need for a local clone or any synchronization workaround (such as Git, Rsync, or SSHfs) to effectively use Codex?

Yes, it should simply work without wait states or out-of-sync conditions that arise from using a remote Git repository in any manner other than its intended purpose. Git itself provides this as its core capabilities. Don’t work around it; use it as it was designed. SSH, Git, and Shell commands in a sandbox or container provide all the necessary components for a secure and robust development environment.

3.) Would you like the ability to configure multiple remote machines within Codex?

Yes, we should be able to configure multiple remote machines as workspaces. However, it would be even better if these workspaces were organized into a single project or program space. This way, multiple agents can have their own dedicated workspace, and a common orchestration or team leader can divide the work and orchestration across each agent and their respective workspace lifecycle.

4.) If this is feasible, how would you expect it to be implemented in the app? Would remote machines behave more like projects you open, or like an execution option you choose per thread? For instance, would there be a folder for each remote machine, or would it be set per-thread?

Personally, I prefer that a Codex CLI agent be installed in each remote workspace environment, and then my Mac Codex app orchestrates the work across them. This way, I can split the work across dedicated hosts for each CLI agent, or multiple CLI’s sharing a single host, while maintaining my Mac’s performance for planning, reviews, and this orchestration. This may have been your intention with Cloud Codex, but all these solutions are only effective when you don’t care about the host you are on. For example, if you have GPU-based workloads, you are left with no options (other than the current remote SSH / devworkspace models that VS Code and its variants have mastered).

5.) If you start working on a remote machine and then close the Codex app, should the work continue running remotely, and should you be able to resume it later?

The user of the Codex app should have the option to stop or allow the agents to continue. In this case, the Codex app becomes the “dev manager” workbench. Connecting back to those remote agents and pulling down metrics, insights, updates, and other relevant information in a reviewable manner would be beneficial. Perhaps exposing Linear or Jira integration as a first-class management pane would also be helpful.

6.) When you SSH today, do you usually work on the same machine throughout the session, or do you typically connect to one machine and then switch to another after connecting?

I usually stay on one machine, but that’s just a limitation of my human context. If I could have one machine dedicated to development and another machine for testing and UAT, and both agents could work autonomously within a closed lifecycle, that would be incredible!

——

NOTES: Your central pane Mac Codex app is the right strategy, but the idea that it’s only designed for webpages and Mac non-GPU, non IOT, non PC, & non-remote workloads makes it a non-starter for my work. You literally have all three beachheads with agents on the command line, agents in IDEs, and now a central pane to pair and orchestrate them. Even simply allowing my remote Codex CLI to pair with my Codex app and direct it would be better than what you released. Just my two cents. Great things await if you go big and don’t go home :).

I just want to work on my remote vps , as if my codex is running inside, it , full control, file system , code execution , as we do with vscode. but the cherry on top of the cake is when you add local files and git in the mix so we can use local files on remote mchines .

@htahboub

@htahboub all host codex versions are 125

If the local Codex app shows the remote Codex version as lower than 0.125.0 under Settings > Connection even though both remote and local versions are 0.125.0, try killing codex-server on the remote machine and then wait for the local Codex app to reattach automatically. This resolved the issue in my case.

You can check the PID of codex-server as following command:
ps -ef | rg 'codex app-server|openai.chatgpt.*/codex'

@mseok

@mseok This was it ! THANK YOU !

Add this to ~/.codex/config.toml:
[features]
remote_connections = true
Restart codex app, and then Settings > Connections.

Thank you for this

@mseok

@mseok this is super helpful! hope openai can fix this soon.

I'd like to know if all requests to the Codex API can be initiated from the local machine.

In my environment, remote development machine cannot directly access the Codex API, so I want to know if we can proxy all requests to the local machine and the local machine to access the API.

+1 for first-class remote development support in Codex.

My workflow often runs on remote Linux/GPU servers with Docker, private repos, simulators, and long-running QA tasks. Today the workaround is Codex CLI over SSH/tmux, but native support for persistent remote sessions, reliable reconnect/resume, mobile monitoring, git diff review, and safe checkpoint/rollback would make Codex much more practical for real engineering workflows that cannot fit inside a short-lived cloud sandbox.

SSH when?!

Whaiting for SSH.

This feature is now available in the Codex app! See this documentation for details.

I connected to a remote machine using Codex's own connection feature. It works for chat/agents—but I can't open files (I can view them, but when I attempt to open one it just says:

"Unable to load file"

I'm not sure if this is just out of the realm of possibility right now, or if this is a setting that I am missing, or what.

Similar situation, I just setup Claude on a remote machine and it's really amazing to be able to switch from laptop to phone to continue o nthe go, would be incredible to have something similar for Codex

@jeannen

@jeannen codex has already had this for a while now: link.

Navigation Menu

Repository navigation

Remote Development in Codex Desktop App #10450

What feature would you like to see?

Feature Request: Remote Development Support

Current Limitation

Requested Feature

Why This Matters

Summary

Additional information

161 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remote Development in Codex Desktop App #10450

Description

What feature would you like to see?

Feature Request: Remote Development Support

Current Limitation

Requested Feature

Why This Matters

Summary

Additional information

Activity

Cyfine commented on Feb 3, 2026

ht0324 commented on Feb 4, 2026

llkj11 commented on Feb 4, 2026

haonan0x3a1 commented on Feb 4, 2026

Schuppenhauer commented on Feb 4, 2026

baumann-oai commented on Feb 4, 2026

htahboub commented on Feb 4, 2026

dwchoo commented on Feb 4, 2026

ht0324 commented on Feb 5, 2026

Schuppenhauer commented on Feb 5, 2026

safareli commented on Feb 6, 2026

TADROSINCJT commented on Feb 6, 2026

Mrspoq commented on Feb 7, 2026

161 remaining items

MantraMedia commented on Apr 25, 2026

mseok commented on Apr 26, 2026

MantraMedia commented on Apr 26, 2026

punksinatra commented on Apr 26, 2026

timetzw commented on Apr 27, 2026

cxz66666 commented on Apr 28, 2026

howard-lynn-ye commented on May 6, 2026

demyxco commented on May 8, 2026

yshishenya commented on May 11, 2026

etraut-openai commented on May 14, 2026

drewclifton commented on Jun 6, 2026

jeannen commented on Jul 26, 2026

htahboub commented on Jul 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions