Remote Development in Codex Desktop App

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?

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)

1. 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)

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

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

1. 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)

1. 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?

1. 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):

<img width="765" height="590" alt="Image" src="https://github.com/user-attachments/assets/09381f12-c4ca-4aa1-97ad-3ff08428d908" />

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.

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!

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!

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.

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

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

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

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

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

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?
Yes. I code on my servers that run the dev environments

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?
Remote workspace is synced with a git repository and therefore serves as single source of truth

Would you want the ability to configure multiple remote machines in Codex?
Yes. I am working with two repos in different folders on one server for development. Then am working with two servers of staging for each codebase.

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?
To me a WorkspaceName@SSHHostName is preferred or any other similar choice

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?
Yes. I currently use byobu terminal multiplexer for this purpose.

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?
Multiple machines.. SSH key based logins. However mostly am working with one laptop for development VMs. Another machine for Staging vMs

I like to add- port forwarding of app ports for browser testing and actually if we can also run e2e on local machines against port forwarded app endpoints. But do not keep punching too many holes.

I think the vast majority of people here that are interested in the SSH capability (of the Codex Desktop app) currently use VSCode and expect the Codex Desktop app to work similarly to VSCode when it opens a directory on a remote machine over SSH.

The repo lives on the remote machine, the edits are streamed there as they're made in the local vscode app running on the user's desktop computer. commits etc are happening on the remote machine via the git repo that is checked out there. I can have multiple vscode windows open, each are connected to multiple remote machines.

This is many people's, including my, normal every day workflow. It's hard to adopt working with the Codex Desktop app without this capability, and we're back to using the codex command line app inside tmux on the remote machine.

I think antigravity has already done very good job, their Agent Manager works very well for me, maybe u can refer to that one?

I strongly support adding remote development support (SSH / remote hosts) to the Codex Desktop App.

My development workflow is fully remote-first:

• I use a Mac as the client machine
• All development environments (Docker, databases, runtimes) run on remote Linux servers
• VSCode is connected via Remote SSH
• Previously, I used the Codex VSCode extension installed on the remote server

With the new Codex Desktop App, the experience is excellent — especially parallel agents and task management — but currently it only works with local projects.

This creates a major limitation:
Modern teams increasingly run development environments on remote servers, cloud VMs, or GPU machines rather than on local laptops.

Key use cases where remote support is critical:

1. Server-based development environments

Many teams run full dev environments on remote Linux servers for consistency and performance.

1. GPU / high-memory environments

AI/ML and large builds often run on remote GPU machines.

1. Secure corporate environments

Source code cannot be stored locally and must remain on secured servers.

1. Existing VSCode Remote SSH workflows

Developers already rely heavily on SSH-based editing and execution.

Suggested implementation ideas:

• Allow connecting a workspace via SSH (similar to VSCode Remote SSH)
• Or allow Codex App to attach to an existing remote agent running on a server
• Or support a “remote workspace bridge” process that syncs filesystem + command execution
• Even read-only remote browsing + command execution would already be valuable

Codex App is incredibly promising as a multi-agent development environment.
Remote development support would make it viable as a primary daily driver for professional teams.

Thank you for the amazing work — excited to see where Codex goes next.

Thanks everyone, all this feedback is super helpful. What people seem most aligned on:

1. remote workspace should be the source of truth (no required local clone/sync workaround)
2. remote should feel like local (read/write/edit + run commands on the remote host)
3. support for multiple hosts/workspaces is important
4. sessions should be reconnectable and ideally keep running remotely if the app closes
5. the preferred model is workspace/project semantics (e.g. workspace@host) with threads inheriting that context by default

Really appreciate all the concrete examples here. We’re using this to shape scope and sequencing for remote support in the app.

Thank you so much @baumann-oai

+1 too! i believe claude code just launched this feature and would really like codex to have it too!

I'm late to the party, but here are my answers:

1. Yes. Same experience as running locally
2. Yes. No local clone
3. Yes. Ability to configure multiple remote machines in Codex
4. copying the vscode or jetbrains toolbox/gateway workflows is the most reasonable choice
5. Headless running & persistence would be amazing (ideally, same as using codex inside tmux on the remote server, and returning to it). This is a big plus of ssh workflows (you can have persistent jobs/tasks on a big machine with a similar config than prod). I'm very happy to install things on the remote machine for this to work.
6. I typically work on the same machine the whole time.

This is the main feature keeping me from switching over to the codex app as my daily driver (currently using codex in terminal over ssh)

My two cents:

• I really enjoy working with Codex CLI, tried many and it's the best UX IMO.
• I always work on remote workspaces.
• I use both 1 project - one workspace and 1 workspace - multiple projects setup.
• You should steal some ideas from OpenCode Web - 1 terminal (either a web app or TUI) can connect to multiple servers, but at the same time on 1 server one can open multiple projects, and within those projects one can create multiple worktrees - it's absolute joy to work with it (despite the harness being less powerful IMO).
• Built-in worktree support is critical for efficient, parallel work (flattening all levels, just a list of sessions no matter which server/project/worktree I'm working on - there are too many navigation layers in OpenCode).

+1 on this. i run a mac mini at home and use it as a local compute node. all my actual dev environments live on it. my main machine is a laptop and i just ssh into the mini for everything. the codex desktop app feels genuinely great but it's kind of useless for me right now since none of my projects live on the laptop itself. having ssh/remote host support would mean i can use the app as the frontend on my laptop while codex actually runs against the real codebase on the mini. that's literally all I need, same experience, just pointed at a remote host. would immediately make this my daily driver.

+1 on this !

This is a must! Going back to Cursor.

A temporary fix is to load the remote desktop as a drive on the Network (/Volumes/<>) and use that as the directory. I ask Codex to append a ssh my-server to the commands it wants to run. It's been working fine (ish) for me - although I know it's not a fix. So +1 for this. Looking forward seeing native support for ssh.

My day to day workflow involves running a docker remote over an ssh remote in vscode. The codex app is terrific but that feature is needed for research centres that have ssh servers for gpu usage and docker machines to install requirements there.

A temporary fix is to load the remote desktop as a drive on the Network (/Volumes/<>) and use that as the directory. I ask Codex to append a ssh my-server to the commands it wants to run. It's been working fine (ish) for me - although I know it's not a fix. So +1 for this. Looking forward seeing native support for ssh.

Workaround that worked for me to edit remote files with Codex in VS Code

The practical workaround is to mount the remote directory as a local drive using SSHFS. This lets VS Code see the remote project as local, so Codex stays active and can read/write files.

Steps I used on Windows 11:

1. Install SSHFS-Win via PowerShell:

``powershell
winget install SSHFS-Win.SSHFS-Win
``
This installs WinFsp and SSHFS-Win so you can mount remote file systems.

1. Install SSHFS-Win Manager (GUI for SSHFS-Win) to configure and mount your server using your private SSH key. This tool lets you specify a key file for authentication and mount the remote directory as a Windows drive (e.g., Z:).

1. Once the drive is mounted and accessible in File Explorer, open that drive in VS Code (File → Open Folder). You can now edit remote files locally and Codex will continue to work.

This avoids using Remote-SSH and keeps the Codex extension fully functional while working on your remote files via SSHFS !

+1 this would be super nice to have

@fftgit @yoloyash I think mounting the remote directory as a local folder (e.g. using SSHFS) is not a complete solution here. Note that one thing we want (at least this is what I want, and reading the thread I think other users too) is the ability to run code on the remote server. For example, I may have programs installed on the remote server which are not available locally. This is also consistent with the desired "sandbox" experience.

We hit the same wall running agents on remote servers. Ended up solving it at a different layer.

Instead of trying to make each IDE tool support SSH natively, we built a coordination layer that lets agents on different machines (local, remote, whatever) work as a team through shared rooms and a message bus. Each agent stays in its own environment with its own tools, and they coordinate through the network layer.

So you can have Codex running locally and another agent on your GPU server, and they just talk to each other. Git handles the file sync, the message layer handles the coordination.

https://github.com/ThinkOffApp/ide-agent-kit

Dang. Over a month later and still not added. Very important feature for me. All the other major AI IDEs/coding platforms have this feature, including Claude Code in the Claude app. Can't use this app without SSH/remote support.

Dang. Over a month later and still not added. Very important feature for me. All the other major AI IDEs/coding platforms have this feature, including Claude Code in the Claude app. Can't use this app without SSH/remote support.

I guess the promise of building fast with AI can't yet even be achieved within OpenAI

+1 to the request, my main workflow is remote with cursor/vs code from win pc into HPC where I do most things. I really like that in opencode I can just spawn server on remote and connect to it with locally running instance or just open web interface, was surprised to see that this is not supported in the app :(

This is an alter native harness rather than Codex Desktop itself, but you get browser based remote access as well as "subagents“ (mandatory agent team definition actually).

CODEX_HOME=~/.codex npx -y dominds@latest webui --host 0.0.0.0 in your remote host, and access via http://<your-ip>:5666 from anywhere.

Optionally set DOMINDS_AUTH_KEY=xxx to fix your secret passkey, rather than randomly generated every time.

I think it's been implied a bit above, but just to state it explicitly, I would love to see this functionality also support locally hosted dev containers as well as remote servers/VMs.

I would only add that for me the lack of remote development is a dealbreaker. I haven't really tried Codex yet because of this (all my code and heavy computations live in remote servers).

Same here. Remote is really essential.

It would be great to have a remote development mode where the Mac app connects directly to the Codex pipeline on Windows. That would let users develop on Windows without needing to use the terminal or rely on SSH, which is often unreliable unless WSL is installed.

It's likely coming soon: https://x.com/ajambrosino/status/2030059146436091939

I made a Codex app server wrapper, so you can run it remotely with npx codexapp
https://github.com/friuns2/codexui

I'm also looking forward to this feature. It will allow me to move away from VS Code (While VS Code is certainly impressive, I believe that native multi-agent support is essential).

This feature is a MUST. You don't have to guess much about what buttons/UI a user must interact with. Just copy the user flow of vscode's remote ssh extension

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?

For me this is the ability to spawn subagents on anyone one of a pool of hot development environments

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?

Remote envs should start in a consistent state, but we should leave it to orchestration to coalesce concurrent agent's work.

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

Yes, or the ability to dynamically select from a preconfigured pool.

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?

Execution option.

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?

Yes. Leave the creation and destruction of agents to other solutions and keep running, even in the event of link failure. Persist results on the remote machine for later collection if immediate reporting is not available.

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

Typically working in multiple ephemeral environments.

+1

+1

We need remote to eliminate terminus and tmux.

+1

+1

+1

Not sure if @baumann-oai or team is still looking for answers, but here are mine:

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?

Yes. It should behave very similarly to the user-experience on the local host.

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?

Very much. I work on remote linux servers with the repositories on them, and never have a local copy. Large source trees.

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

Ideally. I do work with multiple machines, but rarely at the same time.

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?

For me, remote machines are all separate. Separate projects. I only need each machine to interact with itself for context. I want a project on a remote machine to behave like a project. I suppose there _could_ be multiple threads for a remote machine, but for my use case they would all be part of working in the same project.

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?

I would expect it to stop. I can see value in it being reconnectable, but that's not what I expect from applications. My history is in unix, when something closes it goes away; unless specific efforts are made to cause it to remain running.

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?

Usually one machine at a time, sometimes more than one machine; but as noted above, each is a separate development project at the time.

Any updates on ETA or if this enhancement is considered ? The OP posted it about a month ago with lot of duplicates on same topic by other folks.

Would love to have this feature shipped ASAP.

If this could work exactly like VSCode's remote SSH feature, that would be perfect.

+1

Codex App Server is awesome and perfectly suited for this. Would be cool to let the user add a remote App Server directly in the desktop app in order to create and monitor background agents.

Yes please! I run many projects directly from my server and I would love to be able to use the Codex app to work on these remotely.

I've checked this thread more times than I care to admit. We need this feature yesterday! Please prioritize, OpenAI 🙏

every morning i grab my coffee, open my computer, and this issue is my homepage. we’re just like that, kinda crazy i guess. please do this, openai folks

I agree with everyone. I live solely to ensure this function reaches Codex. Each day that passes without it is another day of life you take from me.

Hey folks! Just wanted to provide an update here.

First off, thank you ALL for your feedback -- it helps us shape what we're building. Second, our team has been working hard to make this possible and will have something exciting to share with you all soon -- I'll leave it at that ;)

大家好！这里想给大家更新一下情况。 首先，非常感谢大家的反馈——这有助于我们改进产品。其次，我们的团队一直在努力实现这个目标，很快就会和大家分享一些令人兴奋的消息——我就先说到这里吧 ;)

Looking forward to it!

Great work out there.
But OMG, why there isn't a plugging to ssh other machine. Come one this is basic, even a MVP app should support this.

Please , bring a solution ASAP.

Until then, I will keep cursor.

Up vote! My MacBook has shitty docker, even with colima, I want to do local development in remote ssh, and stop using my local MacBook resources, installation mechanisms etc, while maintaining the nice desktop app workflows, that would be king!

@baumann-oai thanks for the update. For everyone here that uses the desktop app, using mutagen with it is a workaround for now.

@demyxco Could you please explain how mutagen could be used as a workaround? Does it allow running agent remotely as if it's running locally or something like this?

@solomatov no, the agent runs locally on your machine. Mutagen just mounts and syncs the changes from local to remote just like how iCloud/Google Drive works.

I am excited about this feature. I was pleased when the Windows version of the desktop app was released (thanks!) but disappointed in the lack of remote dev options. I will wait patiently with a monitor full of terminal windows.

One more day passed and no updates on this issue. Anthropic has launched dispatch too along with remote control few days back.

Is it so difficult to ship fearures using codex ?

@demyxco Could you please explain how mutagen could be used as a workaround? Does it allow running agent remotely as if it's running locally or something like this?

You can just get codex to create an MCP that connects it to your remote server. Or if on MacOS just use SMB in Finder. Those are the workarounds I use. Both aren’t ideal though. Native integration is preferred so hopefully they release it soon.

@llkj11 agreed. Native solution would be better.

👀

<img width="1728" height="1117" alt="Image" src="https://github.com/user-attachments/assets/34332b57-aaca-4a24-a079-cd99d24e099c" />

Looking so good!! Can't wait!

Does this work if you simply want to connect to a local Docker instance?

@axeldelafosse don't tease us like that

+1 legit all projects i have are on my server
for the love of god add this

+1

Amazing application and model update really. I love both, no lie. Which is why I want this feature so badly. Super unfortunate not to have this feature, glad to see a lot of others affected by this so hopefully y'all update it very soon. I was surprised to see that Claude desktop app did support it.

Please bring this feature

What ever happened to agentic development replacing human engineers? Couldn't this feature have been vibe coded in 15 minutes?

What ever happened to agentic development replacing human engineers? Couldn't this feature have been vibe coded in 15 minutes?

I've auto programmed a few agents using the codex subscription to solve this for me, and I got them to make a Codex electron app bundle for linux in the process. I guess it is about testing and security? Then again why isn't that automated as well with a strong red team? I'm as surprised as anyone on this

Getting close!!! 😍

快到了！！！😍

How long will we wait?

Can you release this before the 28? My Macbook Neo return window closes and I need to know if I can rely on my desktop PC for it's compute with Codex lol

Can you release this before the 28? My Macbook Neo return window closes and I need to know if I can rely on my desktop PC for it's compute with Codex lol

hahaha

hey openai, this is super urgent. my bro @nkasco need to return mecbook neo. you have three days. pls ship. bye

While you're at it name it "Nate Mode"

If Tesla will give Joe "Joe Mode" I want my glory too!

Hi OpenAi. Please release this feature before the 28th. My client Nate has purchased a MacBook Neo at full retail price. Under the premise that remote development would be available for testing. Thank you for your prompt attention to this matter!

This is taking way too long. For those looking for a temporary workaround, I have had a great experience using mutagen, where I simply mount remote dir as local dir.

This is taking way too long. For those looking for a temporary workaround, I have had a great experience using mutagen, where I simply mount remote dir as local dir.

I have used that too, but it's a little confusing when Codex doesn't know when/if the files change. When I need to have it ssh to the remote system to run tests, but it's operating on a local file. With guidance, it is able to figure it out, but when it's not in control of the contents of the remote file it's testing directly, it's never going to work _well_.

Supportive

Using codex on your local environment is a big security risk, it would be great to use the app on a VPS

It's taking surprisingly long for basic feature that was expected to be in day 1.

You guys should see their setup on Windows codex desktop app to use WSL, it's just so bad, probably needs a large refactor involving that too.

My mac codex desktop app is so freaking good, and working out of the box and what not. But windows... Damn, 7 days trying to configure it without success.

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!

Your progress is too slow

> 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! Your progress is too slow

I guess you guys should just throw this whole issue in gpt-5.5 or whatever edge model only available internally and get this live, shouldn't be hard, with AI coding. Is there any good open source codex desktop app alternative?

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?

Yes. VSCode SSH remoting is a great model and well-tested by now, so I would strongly recommend using that as a primary source of inspiration and only deviating when you have a good justification to do that.

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?

Absolutely. I don't want Codex to touch my local system in any way at all unless I explicitly say otherwise. For all purposes it should behave exactly as Codex TUI running remotely.

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

Yes, although in many cases it would be fine if each window was connected to just one machine (but make it easy & convenient to have multiple windows that connect to different ones if so!).

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?

They should behave in a way similar to projects but orthogonal to them. That is, a given project may involve multiple VMs or containers. An execution option per thread sounds sensible, but it would be even better if this could be switched in the middle of the thread (or perhaps when thread gets forked).

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?

Yes, but this should be made very clear, and I should get an option to keep things running or to terminate them when closing.

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?

I usually connect to several different machines from my primary desktop. All actual dev work happens on those machines.

<img width="650" height="787" alt="Image" src="https://github.com/user-attachments/assets/53396346-aa76-47cb-be76-e0174e663bb9" />

<img width="963" height="820" alt="Image" src="https://github.com/user-attachments/assets/82da167c-e6a3-40bb-b5a1-34601dd0a201" />

The remote development feature is developing...

<img alt="Image" width="650" height="787" src="https://private-user-images.githubusercontent.com/224722889/571688551-53396346-aa76-47cb-be76-e0174e663bb9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NTUxLTUzMzk2MzQ2LWFhNzYtNDdjYi1iZTc2LWUwMTc0ZTY2M2JiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05NzAyNzk4NzI4ZDNlOTNhZGQ1ZWZjNTA5OWVmZDJhNWVhMmZiYmE2MDY3MmUzZTM0MTZiMGNhYmE5YWIwODk5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.WG2Z7TmDdVqOOS3daO0ozFndtIlbFqP7BktkCDv2la8"> <img alt="Image" width="963" height="820" src="https://private-user-images.githubusercontent.com/224722889/571688614-82da167c-e6a3-40bb-b5a1-34601dd0a201.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NjE0LTgyZGExNjdjLWU2YTMtNDBiYi1iNWExLTM0NjAxZGQwYTIwMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMWMyYjQ1MDVkM2Y3NGE2YmI1NTRhN2RhOWQxMzM1NWYyOTI4ZDc2NmYwNzMzNTgxZTRlZDdmMjIyOGViNTAwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.NY2Ye_JY_LTE16GFhLmNr80IoEsot9onfSKcCZdEpiA"> The remote development feature is developing...

So there's a new Connections tab in settings on the way? Guess that explains the delay. Trying to package into a new wider feature?

<img alt="Image" width="650" height="787" src="https://private-user-images.githubusercontent.com/224722889/571688551-53396346-aa76-47cb-be76-e0174e663bb9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzQyMjksIm5iZiI6MTc3NDkzMzkyOSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NTUxLTUzMzk2MzQ2LWFhNzYtNDdjYi1iZTc2LWUwMTc0ZTY2M2JiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTEyMDlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yMDFkMzVlMGUyOTA1MzU5Mjg2MTU5NWY3MzQ3YmM0ZDFlMDkzNmI0OWM5MzA1MjQzMWRmODA2YjFmZjllOWFiJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.-at1mFJBEYJdX0iNkxb8duuBoNoJpAldSxA9EYar8WI"> <img alt="Image" width="963" height="820" src="https://private-user-images.githubusercontent.com/224722889/571688614-82da167c-e6a3-40bb-b5a1-34601dd0a201.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzQyMjksIm5iZiI6MTc3NDkzMzkyOSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NjE0LTgyZGExNjdjLWU2YTMtNDBiYi1iNWExLTM0NjAxZGQwYTIwMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTEyMDlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05MThkNDRmZGRlZTFjMjg4OGViZjM1ZGRhODhjM2ZmNDJjYWMzMDZmNWEzY2I0NjgzZjFjOWU1MDFjYWQ2MjAxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.vgpf-Tyvuj_srUCtNDS8C8qIIqd0ZGuCJj0QVYc9OGQ"> The remote development feature is developing...

How long is it expected to take?

> <img alt="Image" width="650" height="787" src="https://private-user-images.githubusercontent.com/224722889/571688551-53396346-aa76-47cb-be76-e0174e663bb9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NTUxLTUzMzk2MzQ2LWFhNzYtNDdjYi1iZTc2LWUwMTc0ZTY2M2JiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05NzAyNzk4NzI4ZDNlOTNhZGQ1ZWZjNTA5OWVmZDJhNWVhMmZiYmE2MDY3MmUzZTM0MTZiMGNhYmE5YWIwODk5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.WG2Z7TmDdVqOOS3daO0ozFndtIlbFqP7BktkCDv2la8"> <img alt="Image" width="963" height="820" src="https://private-user-images.githubusercontent.com/224722889/571688614-82da167c-e6a3-40bb-b5a1-34601dd0a201.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NjE0LTgyZGExNjdjLWU2YTMtNDBiYi1iNWExLTM0NjAxZGQwYTIwMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMWMyYjQ1MDVkM2Y3NGE2YmI1NTRhN2RhOWQxMzM1NWYyOTI4ZDc2NmYwNzMzNTgxZTRlZDdmMjIyOGViNTAwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.NY2Ye_JY_LTE16GFhLmNr80IoEsot9onfSKcCZdEpiA"> > The remote development feature is developing... So there's a new Connections tab in settings on the way? Guess that explains the delay. Trying to package into a new wider feature?

By recompiling the Codex app, the entry point becomes visible, but the functionality is still not fully complete.

> > <img alt="Image" width="650" height="787" src="https://private-user-images.githubusercontent.com/224722889/571688551-53396346-aa76-47cb-be76-e0174e663bb9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NTUxLTUzMzk2MzQ2LWFhNzYtNDdjYi1iZTc2LWUwMTc0ZTY2M2JiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05NzAyNzk4NzI4ZDNlOTNhZGQ1ZWZjNTA5OWVmZDJhNWVhMmZiYmE2MDY3MmUzZTM0MTZiMGNhYmE5YWIwODk5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.WG2Z7TmDdVqOOS3daO0ozFndtIlbFqP7BktkCDv2la8"> <img alt="Image" width="963" height="820" src="https://private-user-images.githubusercontent.com/224722889/571688614-82da167c-e6a3-40bb-b5a1-34601dd0a201.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ5MzM5OTksIm5iZiI6MTc3NDkzMzY5OSwicGF0aCI6Ii8yMjQ3MjI4ODkvNTcxNjg4NjE0LTgyZGExNjdjLWU2YTMtNDBiYi1iNWExLTM0NjAxZGQwYTIwMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzMxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMzMVQwNTA4MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMWMyYjQ1MDVkM2Y3NGE2YmI1NTRhN2RhOWQxMzM1NWYyOTI4ZDc2NmYwNzMzNTgxZTRlZDdmMjIyOGViNTAwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.NY2Ye_JY_LTE16GFhLmNr80IoEsot9onfSKcCZdEpiA"> > > The remote development feature is developing... > > > So there's a new Connections tab in settings on the way? Guess that explains the delay. Trying to package into a new wider feature? By recompiling the Codex app, the entry point becomes visible, but the functionality is still not fully complete.

There are some path issues which I noticed in windows -> linux aswell but these are easily fixable by a certain AI coding tool ;) Works like a charm now

when?

Hopefully this feature is released sometime this month.

+1
I want to train models on RunPod with Codex app.

for those craving alternatives, you can check this one out—it’s super lightweight, performant, and you can host it locally and manage it via the web. https://github.com/friuns2/codexUI

We need same capability in app as cli have with --remote cli option.

I did use appserver on my tailscale, so it would be cool to connect also via desktopp app

for those craving alternatives - I'm connecting to a remote using vscode and use codex extension in it

I’ve been trying to use the Mac Codex App with a contained backend using Docker containers instead of giving the app broad direct access to my personal Mac host.

What I’m attempting:

• Keep using the Codex App as the frontend
• Run Codex CLI itself in an isolated Docker container
• Expose that backend through codex app-server / SSH-style transport
• Use the same code/worktree from the container, so the app is driving a contained environment rather than my host machine
• Ideally also move supporting browser/MCP tooling into containers over time, so the whole execution path is more contained, not just the Codex CLI process

Why:

• The Codex App is by far the nicest Codex UI I’ve used
• But running agents directly on a personal laptop with broad host access feels risky
• I want the safety/isolation of Docker or a remote backend, while keeping the same UX

What I found:

• The backend architecture itself works
• I was able to get another client (VS Code Codex UI) talking successfully to the same Docker-backed Codex backend
• So the “Codex in a contained backend” part is viable
• The blocker is specifically on the Codex App side

What I’ve been able to do in the Codex App so far:

• My current build discovers the SSH-style backend alias from SSH config
• It seems to have remote/backend plumbing internally, including SSH-style remote connection handling
• It also looks like there may be a separate remote-control / remote environment path in the app internals
• I tried setting the app state/config directly to select and auto-connect to the discovered backend, and also tried seeding a managed remote connection entry manually
• In both cases, the app kept overriding those settings back to its own discovered state on restart
• So it wasn’t just a matter of not finding a visible UI path; the app seemed to reject/pave over the manual connection state as well
• Even though the app can discover the backend alias, I could not get it to actually connect and persist a usable remote/backend session
• In practice it still behaves like local-project development is the only supported path

So from my testing, the need here is not just “remote hosts for convenience,” but also “remote/contained backends for safety.” A lot of us would like to keep the Codex App UX, but run Codex somewhere isolated: Docker, SSH host, VM, remote dev box, etc.

If the Codex App gained proper remote/backend support, it would make it much more viable as a daily driver for people who want containment and lower host risk, not just for people doing cloud dev.

Good Idea, btw, cursor 3.0 has the similar feature.

<img width="876" height="544" alt="Image" src="https://github.com/user-attachments/assets/ff3f29c4-3f4b-4cc0-a007-a9ae7402c4d8" />

for those craving alternatives - I'm connecting to a remote using vscode and use codex extension in it

But such a session would die when you disconnect. The ideal feature would be to be able to have persistent sessions on the remote.

I’ve been trying to use the Mac Codex App with a contained backend using Docker containers instead of giving the app broad direct access to my personal Mac host. What I’m attempting: Keep using the Codex App as the frontend Run Codex CLI itself in an isolated Docker container Expose that backend through codex app-server / SSH-style transport Use the same code/worktree from the container, so the app is driving a contained environment rather than my host machine Ideally also move supporting browser/MCP tooling into containers over time, so the whole execution path is more contained, not just the Codex CLI process Why: The Codex App is by far the nicest Codex UI I’ve used But running agents directly on a personal laptop with broad host access feels risky I want the safety/isolation of Docker or a remote backend, while keeping the same UX What I found: The backend architecture itself works I was able to get another client (VS Code Codex UI) talking successfully to the same Docker-backed Codex backend So the “Codex in a contained backend” part is viable The blocker is specifically on the Codex App side What I’ve been able to do in the Codex App so far: My current build discovers the SSH-style backend alias from SSH config It seems to have remote/backend plumbing internally, including SSH-style remote connection handling It also looks like there may be a separate remote-control / remote environment path in the app internals I tried setting the app state/config directly to select and auto-connect to the discovered backend, and also tried seeding a managed remote connection entry manually In both cases, the app kept overriding those settings back to its own discovered state on restart So it wasn’t just a matter of not finding a visible UI path; the app seemed to reject/pave over the manual connection state as well Even though the app can discover the backend alias, I could not get it to actually connect and persist a usable remote/backend session In practice it still behaves like local-project development is the only supported path So from my testing, the need here is not just “remote hosts for convenience,” but also “remote/contained backends for safety.” A lot of us would like to keep the Codex App UX, but run Codex somewhere isolated: Docker, SSH host, VM, remote dev box, etc. If the Codex App gained proper remote/backend support, it would make it much more viable as a daily driver for people who want containment and lower host risk, not just for people doing cloud dev.

The remote backend support is there and works perfectly... The feature is also in the frontend but disabled. I've been using the codex desktop app for weeks now (after I asked codex to make some alterations to it to enable this feature).

Can anyone confirm whether building the project locally allows us to use Codex App on a remote instance?

Some people reported issues in the past, so I'd like to double check

Hey codex team you guys are killing it with the updates 😄 , just wondering any progress on this issue - at the moment using vscode codex ext. (which is not bad) , but after trying this feature on the beta codex app it's pretty a game changer

thank you!

Any updates?

To anyone monitoring this, you can download the beta version at https://persistent.oaistatic.com/codex-app-beta/appcast.xml which has this feature already enabled! It has some rough edges still but it does the job.

Also, you only need to use the beta version once to actually add your connections and then you can continue using them in stable

@zilleste thanks for sharing! Do you know any docs for working with these connections? What am I ssh-ing into?

Just stating the obvious to save a few folks

Do not click any links on this thread, they're trying to phish you

Just stating the obvious to save a few folks Do not click any links on this thread, they're trying to phish you

Sorry but could you specify the phish? This link seems to be the oai static storage. I have installed the app and it actually works.

Just stating the obvious to save a few folks Do not click any links on this thread, they're trying to phish you

thanks for making me aware - but I used some time to check oaistatic.com is the official openAI domain they serve static content from. So I considered a low chance of this being malware. Of course this is beta and we shouldn't build something on top of it.

Can you share why you think it is a phishing attempt?

@aviggiano The skepticism is of course warranted! I, too, got that link from somewhere online, but there are three things that make me pretty confident it's an official build:

1. the domain is listed under https://help.openai.com/en/articles/9247338-network-recommendations-for-chatgpt-errors-on-web-and-apps
2. the app is properly notarized (as evidenced by the fact that you can open it without doing the Privacy and Security dance needed for self-signed apps)
3. you can inspect the signature using spctl -a -vv --type exec /path/to/Codex.app, which shows an OpenAI Developer ID

To anyone monitoring this, you can download the beta version at https://persistent.oaistatic.com/codex-app-beta/appcast.xml which has this feature already enabled! It has some rough edges still but it does the job. Also, you only need to use the beta version once to actually add your connections and then you can continue using them in stable

This works. Tested on April 15, 2026 with Codex (Beta) 26.413.11637 on macOS, connecting to remote Ubuntu 22.04 x86_64 hosts over SSH.

What I verified:

• The beta build exposes remote connections in the UI under Settings > Connections.
• SSH aliases from ~/.ssh/config were discovered by the app.
• I was able to connect successfully to multiple remote hosts, including hosts reached through ProxyJump.
• After setup, both remotes showed Connected in the desktop app.

What initially failed:

• The app discovered the hosts and brought up the SSH tunnel, but the connection failed before ready with read ECONNRESET / websocket close 1006.

Root cause:

• This turned out not to be an app-side SSH/tunnel problem.
• The desktop app bootstraps the remote backend through a login interactive shell (... -ilc ...).
• On my remote hosts, ~/.bash_profile sourced ~/.bashrc, and ~/.bashrc had an unconditional exec zsh -l.
• That shell handoff broke the app’s scripted remote bootstrap path.

Fix:

• I changed the remote shell init to avoid switching to zsh when bash was launched with -c, e.g.

```bash
if [ -x "$(command -v zsh)" ] && [ -z "${BASH_EXECUTION_STRING:-}" ]; then
exec zsh -l
fi

Result:

 - After that change, the exact same beta build connected successfully and the remote sessions were usable from Codex Desktop.

So from my testing: the remote/backend feature in the linked beta does work, but host shell-init can break the bootstrap path in a way that looks like a generic connection failure.

The remote backend support is there and works perfectly... The feature is also in the frontend but disabled. I've been using the codex desktop app for weeks now (after I asked codex to make some alterations to it to enable this feature).

@DaanVT86 can you point to the exact place you can find this in the app then? And what version? I see some people here are referring to a Beta version, is that what you're using? Im using version Version 26.409.20454 (1462).

As per my original post, I've looked myself, and had codex pick apart the app itself. It's found certain references to remote capabilities, but nothing exposed in the UI to be able to use.

I'm hesitant to use an unofficial beta, on important enterprise level work, that doesn't clearly state what is still beta or unstable about it. The fact they dont have an official page stating its a beta we can use makes it sound more like its for internal use and not ready for public release.

Same here. Without SSH remote support, the Desktop App is not usable for my daily workflow. Would love to see this prioritized.

Here's the Sparkle appcast.xml URL for the Beta app- https://persistent.oaistatic.com/codex-app-beta/appcast.xml

Ask your agent to get the latest version from here, download it, unzip it and move to /Applications/ (for MacOS)

Why is this taking so long for an official release? Claude desktop app can even SSH for a long while now.

Today we announced alpha support for remote devboxes over SSH! See this blog post for details.

Today we announced alpha support for remote devboxes over SSH! See this blog post for details.

OMG FINALLY

I don't get it , remote access also blocked for EU ?

I updated to the latest app Version 26.415.20818 (1727) but I don't see a way to add a remote SSH connection. I'm in the US.

Canada with Pro and I don't have the Connections menu in settings either; also on 1727

Thank you so much

Add this to ~/.codex/config.toml:

[features]
remote_connections = true

Restart codex app, and then Settings > Connections.

Add this to ~/.codex/config.toml: `` [features] remote_connections = true ``

That worked!

You really have to make sure that you are running the latest 0.121.0 codex on the remote server, otherwise you can not recover the connection from this

The SSH connection output is working, but I can't enter a username and password. Identity file (optional)
Should I enter the settings here? Where is this file?

Here's the Sparkle appcast.xml URL for the Beta app- https://persistent.oaistatic.com/codex-app-beta/appcast.xml Ask your agent to get the latest version from here, download it, unzip it and move to /Applications/ (for MacOS)

<img width="2976" height="1616" alt="Image" src="https://github.com/user-attachments/assets/1c8c17ab-56a9-47a2-9e5e-e8f7e51d5f2e" />

<img width="2214" height="1520" alt="Image" src="https://github.com/user-attachments/assets/7b149263-f97f-4579-91d7-b639f1a3f4a1" />

<img width="782" height="219" alt="Image" src="https://github.com/user-attachments/assets/8258cb38-b0e7-41b9-b5d3-eb3316d56771" />

I got connected fine, was already pre filled with my connection which was nice. Having an issue finding any files, just returns no results. I have been using codex inside of cursor for weeks and that has worked perfectly fine.

It seems that the remote connection does not use the proxy settings on the remote server.
I configured the HTTP/HTTPS proxy in ~/.codex/.env on my remote server, and the proxy works correctly when I start Codex directly.
However, when I use the Codex desktop app on my local machine to connect to that remote server, it gets stuck in a reconnecting state.

Today we announced alpha support for remote devboxes over SSH! See this blog post for details.

How can I use my mobile phone for remote programming？

> Today we announced alpha support for remote devboxes over SSH! See this blog post for details. How can I use my mobile phone for remote programming？

This is another feature. Seems they are still testing it. You can see related commits in the main branch.

The new remote feature is amazing! This might slowly get me to switch from the terminal to the app.

Howevever, I'm still struggling with two aspects:

1. Port forwarding seems to not work or work much worse than with vscode remote sessions
2. The remote codex session and the one in the app can get out of sync. If I'm starting a task in the codex app and then open the same codex session through the terminal, then I'm not seeing the same progress. The same is true the otherway around. It would be great if I could switch back and forth between the terminal and app but this seems very hard right now.

2. The remote codex session and the one in the app can get out of sync. If I'm starting a task in the codex app and then open the same codex session through the terminal, then I'm not seeing the same progress. The same is true the otherway around. It would be great if I could switch back and forth between the terminal and app but this seems very hard right now.

I'm not sure this is reasonable. I can see that it would be good, but I think you are better thinking of those approaches as separate. The "remote session" support I have used in apps, and want in Codex is "drive a session on a remote server". If I want a session on that remote server myself, that is fine, but it shouldn't/can't be the _same_ session.

When you're driving a car, you can't have two people driving the same car. You can drive two cars, but you should only have one driver per car. If they added the support to _watch_ the remote session from the terminal on that host, that I'm sure is doable, but I'm not sure it's reasonable to want to have a second driver for the same session on the same server.

This isn't yet available in the Windows version right? 🤔

This isn't yet available in the Windows version right? 🤔

It is on windows. I downloaded the latest version this morning (download from the website and update). Use the step from this to enable it: https://github.com/openai/codex/issues/10450#issuecomment-4262658098

Key on windows that killed me: make sure your Agent Environment under General settings is set to Windows native. Took me an hour to figure that out. Once I turned that on and restarted the app all most ssh config hosts showed up under Connections automatically.

> 2. The remote codex session and the one in the app can get out of sync. If I'm starting a task in the codex app and then open the same codex session through the terminal, then I'm not seeing the same progress. The same is true the otherway around. It would be great if I could switch back and forth between the terminal and app but this seems very hard right now. I'm not sure this is reasonable. I can see that it would be good, but I think you are better thinking of those approaches as separate. The "remote session" support I have used in apps, and want in Codex is "drive a session on a remote server". If I want a session on that remote server myself, that is fine, but it shouldn't/can't be the _same_ session. When you're driving a car, you can't have two people driving the same car. You can drive two cars, but you should only have one driver per car. If they added the support to _watch_ the remote session from the terminal on that host, that I'm sure is doable, but I'm not sure it's reasonable to want to have a second driver for the same session on the same server.

But it is already the same session id and I can resume a session in the app that I started on the remote machine. The state just seems quite delayed at the moment but it doesn't seem far away from the current state. One example that I'm unsure about at the moment is me lining up messages in the app and then closing my laptop. I would hope that those messages will still get executed eventually on my cloud machines over night. A running indicator would also be nice, so that I know if I should message a session or if something else already has the session running.

I would like to know whether the current SSH functionality can be used for offline remote servers (unable to connect to the OpenAI API), meaning requests are initiated from the local client rather than the remote server. Alternatively, is there another way to address such scenarios?

A few note to use ssh remote feature:

1. add this section to /.codex/config.toml

[features]
remote_connections = true

1. Match ssh remote codex version with local desktop codex version.

Remote was on 0.121.0 and desktop keep complaining socket hang up even tho I can ssh hostname directly. Fixed by upgrading remote host codex cli to 0.122.0-alpha.10. (log path is /Users/YOUR_USERNAME/Library/Logs/com.openai.codex/2026/04/18/codex-desktop-05eed683-4a44-4a04-8456-3167b31c318b-94277-t0-i1-200516-0.log, which will show local codex version [AppServerConnection] Current reported app-server version: currentVersion=0.122.0-alpha.1 hostId=local)

1. Make sure your sshd accepts multi-line input

Codex will run this multi-line command to setup codex app-server bash-3.2$ ssh -o BatchMode=yes -o ConnectTimeout=10 -o ServerAliveInterval=15 -o ServerAliveCountMax=4 MagicBox "sh -c 'if [ -z \"\$SHELL\" ] || [ ! -x \"\$SHELL\" ]; then echo \"Codex remote SSH requires SHELL to point to an executable login shell\" >&2; exit 127; fi; exec \"\$SHELL\" -ilc '\''if command -v codex >/dev/null 2>&1; then exit 0; fi; exit 86'\'''"

My previous setup use windows sshd to forward ssh command to WSL, which broke multiple line command. Fixed by using mirrored network config and connect to openssh-server inside WSL.

1. Enjoy

<img width="519" height="128" alt="Image" src="https://github.com/user-attachments/assets/1e2aaa39-3d33-4379-978f-b5af1b6f2083" />

The Desktop App's "All files" panel appears to use local filesystem APIs directly rather than routing through the app-server's JSON-RPC filesystem methods (fs/readDirectory, etc.). This causes it to look for files on the local machine instead of the remote host.

Note: This part of the codebase appears to be in the closed-source Codex App (Electron), not the open-source codex-rs repository.

Is this a known issue?

<img width="770" height="376" alt="Image" src="https://github.com/user-attachments/assets/59a97170-cd22-4412-98c7-22f17f556c80" />

> To anyone monitoring this, you can download the beta version at https://persistent.oaistatic.com/codex-app-beta/appcast.xml which has this feature already enabled! It has some rough edges still but it does the job. > Also, you only need to use the beta version once to actually add your connections and then you can continue using them in stable This works. Tested on April 15, 2026 with Codex (Beta) 26.413.11637 on macOS, connecting to remote Ubuntu 22.04 x86_64 hosts over SSH. What I verified: The beta build exposes remote connections in the UI under Settings > Connections. SSH aliases from ~/.ssh/config were discovered by the app. I was able to connect successfully to multiple remote hosts, including hosts reached through ProxyJump. After setup, both remotes showed Connected in the desktop app. What initially failed: The app discovered the hosts and brought up the SSH tunnel, but the connection failed before ready with read ECONNRESET / websocket close 1006. Root cause: This turned out not to be an app-side SSH/tunnel problem. The desktop app bootstraps the remote backend through a login interactive shell (... -ilc ...). On my remote hosts, ~/.bash_profile sourced ~/.bashrc, and ~/.bashrc had an unconditional exec zsh -l. That shell handoff broke the app’s scripted remote bootstrap path. Fix: I changed the remote shell init to avoid switching to zsh when bash was launched with -c, e.g. if [ -x "$(command -v zsh)" ] && [ -z "${BASH_EXECUTION_STRING:-}" ]; then exec zsh -l fi Result: * After that change, the exact same beta build connected successfully and the remote sessions were usable from Codex Desktop. So from my testing: the remote/backend feature in the linked beta does work, but host shell-init can break the bootstrap path in a way that looks like a generic connection failure.

My setup is very similar to the one described in that reply. I had already put in some safeguards before (though I wasn’t handling the -c case), so it wasn’t blindly switching to zsh. However, even after adding the -c-related condition mentioned in that reply, Codex still showed read ECONNRESET.

So I modified my .bash_profile to log the startup arguments, for example adding these lines to somewhere of my .bash_profile:

{
    echo "==== $(date) ===="
    echo "PID: $$"
    echo "PPID: $PPID"
    echo "argv0 ($0): $0"
    echo "BASH_EXECUTION_STRING: $BASH_EXECUTION_STRING"
    echo "flags ($-): $-"
    echo "is_login_shell: $(shopt -q login_shell && echo yes || echo no)"
    echo "SSH_CONNECTION: $SSH_CONNECTION"
    echo "SSH_TTY: $SSH_TTY"
    echo "whoami: $(whoami)"
    echo
} >> /tmp/bash_profile_debug.log 2>&1

From that, I could see the exact command Codex was using at startup (the BASH_EXECUTION_STRING line). It redirects the program’s output to a file under /tmp. I checked that file and found that node was not in the PATH.

In my usual setup, nvm is configured in .zshrc, but it wasn’t being initialized in .bash_profile. After adding the nvm setup to .bash_profile, Codex was able to connect successfully.

> > To anyone monitoring this, you can download the beta version at https://persistent.oaistatic.com/codex-app-beta/appcast.xml which has this feature already enabled! It has some rough edges still but it does the job. > > Also, you only need to use the beta version once to actually add your connections and then you can continue using them in stable > > > This works. Tested on April 15, 2026 with Codex (Beta) 26.413.11637 on macOS, connecting to remote Ubuntu 22.04 x86_64 hosts over SSH. > What I verified: > > The beta build exposes remote connections in the UI under Settings > Connections. > SSH aliases from ~/.ssh/config were discovered by the app. > I was able to connect successfully to multiple remote hosts, including hosts reached through ProxyJump. > After setup, both remotes showed Connected in the desktop app. > > What initially failed: > > The app discovered the hosts and brought up the SSH tunnel, but the connection failed before ready with read ECONNRESET / websocket close 1006. > > Root cause: > > This turned out not to be an app-side SSH/tunnel problem. > The desktop app bootstraps the remote backend through a login interactive shell (... -ilc ...). > On my remote hosts, ~/.bash_profile sourced ~/.bashrc, and ~/.bashrc had an unconditional exec zsh -l. > That shell handoff broke the app’s scripted remote bootstrap path. > > Fix: > > I changed the remote shell init to avoid switching to zsh when bash was launched with -c, e.g. > > if [ -x "$(command -v zsh)" ] && [ -z "${BASH_EXECUTION_STRING:-}" ]; then > exec zsh -l > fi > Result: > > * After that change, the exact same beta build connected successfully and the remote sessions were usable from Codex Desktop. > > So from my testing: the remote/backend feature in the linked beta does work, but host shell-init can break the bootstrap path in a way that looks like a generic connection failure. My setup is very similar to the one described in that reply. I had already put in some safeguards before (though I wasn’t handling the -c case), so it wasn’t blindly switching to zsh. However, even after adding the -c-related condition mentioned in that reply, Codex still showed read ECONNRESET. So I modified my .bash_profile to log the startup arguments, for example adding these lines to somewhere of my .bash_profile: { echo "==== $(date) ====" echo "PID: $$" echo "PPID: $PPID" echo "argv0 ($0): $0" echo "BASH_EXECUTION_STRING: $BASH_EXECUTION_STRING" echo "flags ($-): $-" echo "is_login_shell: $(shopt -q login_shell && echo yes || echo no)" echo "SSH_CONNECTION: $SSH_CONNECTION" echo "SSH_TTY: $SSH_TTY" echo "whoami: $(whoami)" echo } >> /tmp/bash_profile_debug.log 2>&1 From that, I could see the exact command Codex was using at startup (the BASH_EXECUTION_STRING line). It redirects the program’s output to a file under /tmp. I checked that file and found that node was not in the PATH. In my usual setup, nvm is configured in .zshrc, but it wasn’t being initialized in .bash_profile. After adding the nvm setup to .bash_profile, Codex was able to connect successfully.

I'm running into this same problem. This seems kind of silly -- Cursor brings along its own installer on SSH connect and doesn't require me to have node or codex installed or in $PATH.

A few note to use ssh remote feature: 1. add this section to /.codex/config.toml `` [features] remote_connections = true ` 2. Match ssh remote codex version with local desktop codex version. Remote was on 0.121.0 and desktop keep complaining socket hang up even tho I can ssh hostname directly. Fixed by upgrading remote host codex cli to 0.122.0-alpha.10. (log path is /Users/YOUR_USERNAME/Library/Logs/com.openai.codex/2026/04/18/codex-desktop-05eed683-4a44-4a04-8456-3167b31c318b-94277-t0-i1-200516-0.log, which will show local codex version [AppServerConnection] Current reported app-server version: currentVersion=0.122.0-alpha.1 hostId=local) 3. Make sure your sshd accepts multi-line input Codex will run this multi-line command to setup codex app-server bash-3.2$ ssh -o BatchMode=yes -o ConnectTimeout=10 -o ServerAliveInterval=15 -o ServerAliveCountMax=4 MagicBox "sh -c 'if [ -z \"\$SHELL\" ] || [ ! -x \"\$SHELL\" ]; then echo \"Codex remote SSH requires SHELL to point to an executable login shell\" >&2; exit 127; fi; exec \"\$SHELL\" -ilc '\''if command -v codex >/dev/null 2>&1; then exit 0; fi; exit 86'\'''" My previous setup use windows sshd to forward ssh command to WSL, which broke multiple line command. Fixed by using mirrored network config and connect to openssh-server` inside WSL. 4. Enjoy <img alt="Image" width="519" height="128" src="https://private-user-images.githubusercontent.com/2713366/580499068-1e2aaa39-3d33-4379-978f-b5af1b6f2083.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzY4MDk1ODMsIm5iZiI6MTc3NjgwOTI4MywicGF0aCI6Ii8yNzEzMzY2LzU4MDQ5OTA2OC0xZTJhYWEzOS0zZDMzLTQzNzktOTc4Zi1iNWFmMWI2ZjIwODMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDQyMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA0MjFUMjIwODAzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTgzMWYxNzU5MDFhNzk2ZDMwMTdiMTUyMzc0YzMzMTQzNzBiZjI3MWM5MWM2MWZmNDk5ODBlZDhiNzg2YzFiYiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.8_tLajjrm3cWUdI3FNIniUcki_s667pdkJ0I8ozgGrM">

Currently in the same situation, I am updated to the latest alpha versions but still getting the socket hang up error. Connecting from mac to Windows. ssh works otherwise and bash is the default shell where sh is available.

UPDATE - I couldn't get it to work when initiated from the mac, but if I manually start the app-server on Windows on port 9234 it seems to connect from the mac. So in my case, ssh was working fine but it couldn't start the app server once connected. codex app-server --listen ws://127.0.0.1:9234

So, I can't figure out how to make this work. I tried using the Codex (Beta) app on my Mac, and I can add a new host to Connections. But, when I turn it on, it just tells me that it failed.
Where do I go to see what the underlying problem is? If it's something else as has been described above I can work to resolve it, but without anything other than a button saying "Failed", I don't know where to go next.....
I have codex-cli 0.122.0 on my Linux server, but I've no idea how to compare that to the version of the Codex app on my Mac (versions 26.something). So now sure how that works.

Hello Codex team,

Please add this as a native feature. SSH connection with all the perks working flawless is mandatory so I can switch everything to it.

So, I can't figure out how to make this work. I tried using the Codex (Beta) app on my Mac, and I can add a new host to Connections. But, when I turn it on, it just tells me that it failed. Where do I go to see what the underlying problem is? If it's something else as has been described above I can work to resolve it, but without anything other than a button saying "Failed", I don't know where to go next..... I have codex-cli 0.122.0 on my Linux server, but I've no idea how to compare that to the version of the Codex app on my Mac (versions 26.something). So now sure how that works.

You get the reason it failed if you hover over the red error indicator. E.g.:

<img width="629" height="412" alt="Image" src="https://github.com/user-attachments/assets/86d82b58-36de-46a8-867e-8846f666dbf9" />

You get the reason it failed if you hover over the red error indicator. E.g.:

Thanks! Interestingly, it was connecting successfully when I tried this morning, so, I'll remember that for next time. :-)

Okay, next time happened soon. Now I am seeing it fail, showing:

<img width="334" height="73" alt="Image" src="https://github.com/user-attachments/assets/34a8184f-5ab5-428b-8e1d-35fb923eed9c" />

I thought it might be an address-family-mixing problem, but I think not. This host is dual-stack, so I edited the connection and specified the hostname as the IPv4 address of the server. I end up with the same error just with the IPv4 address displayed in the error above.

What could be causing the local tunnel to not be ready?

@cross-cisco looks like the connection is reaching your server but being dropped, so probably an issue on that end. Maybe check the auth logs (probably /var/log/auth.log or /var/log/secure) if you have access?

Hi, Is there any methods that can let the Codex app connect to the remote server with ForwardAgent? I want to use local keys to login other remote servers from the target remote server that is running the codex session.

I found the solution: Zed ( I ssh to linux from windows) There's codex cli support

I can't see UI under Settings > Connections

<img width="644" height="897" alt="Image" src="https://github.com/user-attachments/assets/a1f479bc-6b03-4b29-b061-d7d0ce4e8898" />

I can't see UI under Settings > Connections <img alt="Image" width="644" height="897" src="https://private-user-images.githubusercontent.com/37021767/583072098-a1f479bc-6b03-4b29-b061-d7d0ce4e8898.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcwMDA0MTEsIm5iZiI6MTc3NzAwMDExMSwicGF0aCI6Ii8zNzAyMTc2Ny81ODMwNzIwOTgtYTFmNDc5YmMtNmIwMy00YjI5LWIwNjEtZDdkMGNlNGU4ODk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDI0VDAzMDgzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY5M2Y3YjY4ODYzYjhlZWFmMGUyODZhYzRmNWVkM2I5MjgzMzE4YTgzMzNiMmIxOWU4YjE0NWJiYWJlYjE1ZDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.qyfW1ClhDZ2UhWmDEHTNhNSs18HUuZhjN3zTvEKoMMQ">

You can enable it in ~/.codex/config.toml

[features]
remote_control = true

> I can't see UI under Settings > Connections > <img alt="Image" width="644" height="897" src="https://private-user-images.githubusercontent.com/37021767/583072098-a1f479bc-6b03-4b29-b061-d7d0ce4e8898.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcwMDA0MTEsIm5iZiI6MTc3NzAwMDExMSwicGF0aCI6Ii8zNzAyMTc2Ny81ODMwNzIwOTgtYTFmNDc5YmMtNmIwMy00YjI5LWIwNjEtZDdkMGNlNGU4ODk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDI0VDAzMDgzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY5M2Y3YjY4ODYzYjhlZWFmMGUyODZhYzRmNWVkM2I5MjgzMzE4YTgzMzNiMmIxOWU4YjE0NWJiYWJlYjE1ZDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.qyfW1ClhDZ2UhWmDEHTNhNSs18HUuZhjN3zTvEKoMMQ"> You can enable it in ~/.codex/config.toml `` [features] remote_control = true ``

GPT 5.5 doesn't seem to work through it currently though. The model only shows when I have a local repo selected.

> I can't see UI under Settings > Connections > <img alt="Image" width="644" height="897" src="https://private-user-images.githubusercontent.com/37021767/583072098-a1f479bc-6b03-4b29-b061-d7d0ce4e8898.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcwMDA0MTEsIm5iZiI6MTc3NzAwMDExMSwicGF0aCI6Ii8zNzAyMTc2Ny81ODMwNzIwOTgtYTFmNDc5YmMtNmIwMy00YjI5LWIwNjEtZDdkMGNlNGU4ODk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDI0VDAzMDgzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY5M2Y3YjY4ODYzYjhlZWFmMGUyODZhYzRmNWVkM2I5MjgzMzE4YTgzMzNiMmIxOWU4YjE0NWJiYWJlYjE1ZDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.qyfW1ClhDZ2UhWmDEHTNhNSs18HUuZhjN3zTvEKoMMQ"> You can enable it in ~/.codex/config.toml `` [features] remote_control = true ``

Doesn't work though. config.toml has been setup with remote_control = true. And it still doesn't show anything in Desktop App. I'm on Windows by the way. But my mac doesn't work either.

For anyone who is in the similar position, here is the work around: It should be remote_connections not remote_control at your local PC toml. (confirmed for mac & windows, at latest version of codex app)

[features]
remote_connections = true

GPT 5.5 doesn't seem to work through it currently though. The model only shows when I have a local repo selected.

+1, @baumann-oai is there an ETA on when to expect 5.5 to be available here?

> > I can't see UI under Settings > Connections > > <img alt="Image" width="644" height="897" src="https://private-user-images.githubusercontent.com/37021767/583072098-a1f479bc-6b03-4b29-b061-d7d0ce4e8898.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcwMDA0MTEsIm5iZiI6MTc3NzAwMDExMSwicGF0aCI6Ii8zNzAyMTc2Ny81ODMwNzIwOTgtYTFmNDc5YmMtNmIwMy00YjI5LWIwNjEtZDdkMGNlNGU4ODk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDI0VDAzMDgzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY5M2Y3YjY4ODYzYjhlZWFmMGUyODZhYzRmNWVkM2I5MjgzMzE4YTgzMzNiMmIxOWU4YjE0NWJiYWJlYjE1ZDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.qyfW1ClhDZ2UhWmDEHTNhNSs18HUuZhjN3zTvEKoMMQ"> > > > You can enable it in ~/.codex/config.toml > `` > [features] > remote_control = true > `` Doesn't work though. config.toml has been setup with remote_control = true. And it still doesn't show anything in Desktop App. I'm on Windows by the way. But my mac doesn't work either. For anyone who is in the similar position, here is the work around: It should be remote_connections not remote_control at your local PC toml. (confirmed for mac & windows, at latest version of codex app) [features] remote_connections = true

Great thanks, this typo fix made the 'Connections' subheading appear in Settings, even in the non Beta version of the app. I'm using Version 26.422.21637 (2056).
Now to start looking at how we can leverage it for better workflows :D

Sometimes I see, MCP fetchTool failed (Unable to load folder contents: Timed out waiting for MCP response to fs/getMetadata while listing directories/files.) Also can you give us a text input box to navigate to specific directory? Right now it defaults to my /users/<> directory?

> GPT 5.5 doesn't seem to work through it currently though. The model only shows when I have a local repo selected. +1, @baumann-oai is there an ETA on when to expect 5.5 to be available here?

Fixed it by wiping codex cli from my remote and deleting and reinstalling the app on my Macbook. It's showing now

<img width="767" height="179" alt="Image" src="https://github.com/user-attachments/assets/5a81c6d6-536a-44ea-9513-43af14eba72e" />

I can make remote prompts within a project, terminal launches, and I can see files. Other than that though, nothing really seems to work yet. I can't view files and it can't seem to identify the diff files. Am I missing anything obvious?

How can I refresh the codex version?

None of the connections I have is correct.

Clicking refresh as well as logging out / logging in doesnt help

<img width="267" height="49" alt="Image" src="https://github.com/user-attachments/assets/0fef8013-f77d-4b73-88d9-8f663d9fb6e2" />

@MantraMedia you have to actually update it on the host machine.

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