›_ Codex Issues
Codex Issues / #21509

Improve Codex Desktop support for SSH remote workspaces

Open 💬 6 comments Opened May 7, 2026 by xuchenhao

Summary

I would like Codex Desktop to support SSH-based remote workspaces as a first-class workflow.

This is specifically about the Codex Desktop app, not about manually SSH-ing into a server and running Codex CLI there.

Concrete environment

  • Local client: Codex Desktop on macOS
  • Remote host: Linux server over SSH
  • Code location: on the Linux remote host
  • Desired workflow: use the macOS Codex Desktop app as the UI/client, connect to the Linux SSH host, choose a remote repository directory, and have Codex operate entirely in that remote workspace.

In this setup, the local Mac should mostly be the Desktop UI. The actual filesystem, shell commands, tests, services, and development dependencies should come from the Linux SSH host.

Desired Desktop workflow

  • Codex Desktop can add, connect to, and manage SSH hosts directly.
  • After connecting, Codex Desktop uses the remote host's filesystem and shell as the active workspace environment.
  • Users can choose a remote directory as the workspace from within Codex Desktop.
  • Codex Desktop can read and edit remote files, run commands, run tests, and start services on the remote machine.
  • Codex Desktop provides a clear remote environment initialization flow, including checking whether required components are installed on the remote host.
  • When SSH connection, authentication, permissions, remote shell configuration, bootstrap, or PATH setup fails, Codex Desktop gives clear diagnostic messages.
  • Users should not need to manually open an SSH terminal and run Codex CLI on the remote host to get this workflow.

Relation to existing issue

This is related to #10450, but this issue is intended to emphasize the Desktop-specific product experience now that remote connections exist but still feel incomplete for production remote-development workflows.

The main ask is not just generic remote development support. It is for Codex Desktop to own the SSH remote workspace flow end to end: host management, remote directory selection, remote filesystem/shell execution, environment bootstrap, and clear diagnostics.

If this issue is considered a duplicate of #10450, I hope these Desktop-specific requirements and the macOS-to-Linux remote workflow can be folded into that tracking issue.

View original on GitHub ↗

6 Comments

myweihp · 3 months ago

A smaller incremental step that would already help a lot: allow Codex Desktop to manage environment variables per session/project/profile.

For remote workflows, full Remote-SSH support would be ideal, but even basic support for project-specific execution environments would make the current Desktop + remote shell workflow much more usable.

For example, many projects need to run inside a specific conda environment, virtualenv, or module-loaded environment on a remote machine. It would be useful if a Codex Desktop profile could define things like:

CODEX_HOME=/path/to/custom/codex-home
PATH=/opt/miniconda/envs/my-project/bin:$PATH
CONDA_DEFAULT_ENV=my-project
CUDA_VISIBLE_DEVICES=0
PYTHONPATH=/path/to/project/src

The important part is not only selecting a working directory, but also making sure Codex starts with the same runtime environment that the project expects. CODEX_HOME is also useful for isolating Codex state between different hosts, projects, or remote environments.

Proxy variables such as HTTP_PROXY, HTTPS_PROXY, or NO_PROXY could be another example, but the broader request is simply session/project/profile-level environment variable overrides.

This would not replace full remote workspace support, but it would cover a large part of the practical friction for remote development.

chan-yuu · 3 months ago

Big +1 on this feature request! Wanted to share some thoughts from a user perspective.

Why this matters

I understand that implementing full SSH remote support in Codex Desktop is technically challenging since it's a standalone desktop app rather than a VS Code extension. That said, looking at how Cursor handles this — they've integrated SSH support really well, allowing users to use the local Cursor client as the UI while working on remote codebases — it would be a game-changer if Codex could achieve something similar.

For those of us who work on lightweight MacBooks but have powerful Linux servers as our actual development environments, this workflow is essential. The local machine becomes just the interface; the real work (filesystem, shell, tests, services) happens on the remote server.

Related issues for context

| Issue | Description |
|-------|-------------|
| #10450 | Main tracking issue for remote development, 170+ comments |
| #9923 | CLI-level --ssh flag support |
| #18819 | SSH Connect Timeout Configurable |
| #20128 | Remote SSH performance and reliability issues |
| #19652 | Session management across multiple SSH environments |

Really hope the team can prioritize this on the roadmap. Even basic SSH connection + remote directory selection + file read/write would be a great starting point to build upon.

mjtardos · 3 months ago

Thanks for writing this up. This matches the workflow I want as well: Codex Desktop on macOS as the client/UI, with the actual filesystem, shell, tests, dependencies, and long-running work living on a Linux SSH machine.

Two capabilities I would add to the desired workflow:

  1. Easy port forwarding from the remote workspace

It would be very useful if Codex Desktop could make remote services easy to access locally, similar to VS Code Remote SSH. For example, if Codex starts a dev server, notebook, dashboard, or local web app on the SSH host, the Desktop app should help expose that port to the local machine without requiring manual SSH tunnel setup.

  1. Native automations that run on the SSH machine

Automations should be able to target a remote SSH workspace and run there on schedule. The Mac should not need direct access to the remote filesystem beyond acting as the Codex Desktop client. For example, a daily automation could run inside the remote workspace, inspect local Codex/project state, generate a work summary, run checks, or create a report using the tools and credentials available on that SSH host.

For production remote-development workflows, these two pieces matter a lot: the remote machine is the real development environment, and Codex Desktop is just the control surface.

yeaze · 2 months ago

I also really need this feature.

jac0626 · 2 months ago

also really need this feature.

saidelike · 25 days ago

this is supported, or am I missing something?