Codex App 新增 SSH 远程连接：本地界面直接调用远端 CLI

Codex 桌面应用新增 SSH 远程连接能力，开发者可以在 Windows 上用图形界面直接调用 Linux 服务器上的 Codex CLI，告别 Samba 映射和手动转义的折腾。

一个早就该有的功能，终于来了

Codex 桌面应用刚刚补上了一块拼图：SSH 远程连接。从这周开始，Windows 或 Mac 上的 Codex App 可以直接拉起远端 Linux 机器上的 Codex CLI，把整套对话、补丁、命令执行链路跑在服务器上，而界面留在本地。

这个更新被夹在 OpenAI 几天前的 Codex 大版本更新里一起推送，官方原话是「开启通过 SSH 连接远程开发机 (Devbox) 的 Alpha 测试」。听起来不起眼，但对一类用户来说，这是改善幅度最大的更新——那些代码跑在 Linux 服务器、人坐在 Windows 笔记本前的开发者。

Codex App 设置界面中的 SSH 连接配置面板

在此之前，大家是怎么凑合过来的

这事得从开发者的实际工作流说起。Codex 这套工具其实有两个形态：一个是命令行的 Codex CLI，直接在终端里跟你对话、改文件、跑测试；一个是桌面 App，带 UI、能看 diff、能管理多任务。CLI 的好处是贴近真实开发环境，能直接操作项目目录；App 的好处是看着舒服、操作直观。

问题在于，很多人的开发机其实不是本地——可能是公司机房里的 Ubuntu，可能是云上的开发实例，可能是 WSL 之外另一台专门的 Linux。代码、依赖、编译环境都在那边，本地只是一台敲键盘的终端。

在 SSH 功能上线之前，想用上 Codex App 那套漂亮界面又想跑远端代码，办法基本只有两种：

目录映射：用 Samba 或者 SSHFS 把远端目录挂到本地，让 Codex App 以为自己在操作本地文件。然后在 AGENTS.md 里塞一堆规则，说「改完代码之后请通过 SSH 跑这条命令编译」。
走 CLI：彻底放弃 App，全程 SSH 进服务器用 Codex CLI。

第一种方案有多别扭，用过的人都知道。Samba 在 Windows 下偶尔抽风，编辑器保存延迟、文件锁冲突先不说，最折磨人的是字符转义——Codex App 把生成的命令通过本地 shell 拼出来再扔给远端 SSH，引号、反斜杠、变量展开层层嵌套，跑一次报错三次。第二种方案则等于把 App 这条产品线直接放弃了。

所以这次 SSH 直连，等于官方把这个中间层做掉了：App 不再假装在操作本地文件，而是承认「真正的 Codex 进程在远端」，自己只做 UI 和编排。

新方案的工作模型

这次更新背后的架构其实很直白：Codex App 通过 SSH 通道，在远端机器上拉起一个 codex app-server 进程，这个进程负责接管所有本地 CLI 该做的事——读项目、改文件、调模型、执行 shell。App 端只是一个前端，把对话、diff、终端输出渲染出来。

这意味着几件事：

环境干净：所有依赖、Node 版本、Python venv、Docker 都在远端，本地 Windows 不需要装任何开发栈。
延迟可接受：传输的是结构化消息和文本 diff，不是文件 IO 流，体感比 Samba 顺畅一个量级。
API 配置在远端：模型调用从远端发出，本地不需要再配 key。这对走代理或者用第三方聚合 API 的用户特别重要。

配置步骤：不到十分钟

开启这个功能本身没什么门槛，但有几个细节社区已经踩过坑了，值得照着走一遍。

第一步：本地 Codex App 开启 SSH 功能

在 Windows 上编辑 C:\Users\<你的用户名>\.codex\config.toml，加入：

[features]
remote_connections = true

社区里有人发现，直接在 Codex 对话框里跟它说「帮我开启远程连接功能」，它也会自己改这个文件。改完重启 App，「设置」→「连接」里就会多出一个 SSH 配置入口。

第二步：远端 Ubuntu 安装 Codex CLI

远端机器要装好 Node 20 以上和 Codex CLI：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g @openai/codex --unsafe-perm=true

装完之后在远端跑一次 codex 命令，让它生成 ~/.codex/ 目录，里面同样需要一份 config.toml。

第三步：SSH 免密

这是必须的，App 不会弹密码框。把本地 ~/.ssh/id_rsa.pub 或者 id_ed25519.pub 的内容追加到远端的 ~/.ssh/authorized_keys，并确认权限是 600。Windows 用户记得 OpenSSH 客户端要装上，PowerShell 里能直接 ssh user@host 进得去才算合格。

第四步：远端 API 配置

这里就开始进入坑区了。Codex CLI 有两种登录方式：用 ChatGPT 账号直接登录，或者配置第三方 API 走 OpenAI 兼容协议。两种可以混用，但混用之后历史对话不互通——App 里看到的会话和 CLI 里的会话会分裂。

如果用第三方聚合服务（比如通过一个 Key 调多家模型），统一把 model_provider 设成同一个值，会话才能对齐。社区里推荐的做法是用 ccs 这种 CLI 配置切换工具统一管理，统一打成 codex provider。

两个真实的坑

这次更新刚推到稳定渠道，linux.do 上已经有人贴出了完整的踩坑记录，挑两个最典型的说一下。

坑一：model_provider 不一致导致历史割裂

现象是：用 CLI 跑了几轮对话，切到 App 里连同一台机器，发现历史是空的，或者只有一部分。原因就是 CLI 端和 App 端拉起来的 app-server 用的 provider 名字不一样，Codex 把不同 provider 的会话分文件夹存了。

解决办法是统一 provider 字段，最简单粗暴的就是全部走第三方聚合，provider 名都写成 codex，会话就能并到一起。

坑二：切换 API 后 App 没生效

这个更隐蔽。你在远端用 ccs 切换了 API，再用 codex 命令直接调用，确认已经走的是新 API。但回到 App 这边一发消息，请求还是发到旧的 endpoint。

原因是 Codex App 通过 SSH 拉起的 app-server 是常驻进程，启动时读了一次配置之后就缓存了，你后面改 config.toml 它不知道。解决办法是把旧的 app-server 杀掉，让 App 下次连接时重新启动一个：

#!/usr/bin/env bash
set -euo pipefail
echo "[1/4] Killing Codex app-server processes..."
APP_PIDS="$(pgrep -f 'codex.*app-server' || true)"
if [ -n "$APP_PIDS" ]; then
    echo "$APP_PIDS" | while read -r pid; do
        [ "$pid" = "$$" ] && continue
        [ "$pid" = "$PPID" ] && continue
        kill "$pid" 2>/dev/null || true
    done
fi
echo "[done] 下次 Codex App 连接时会重新拉起 app-server"

把这个脚本扔到远端，每次切 API 之后跑一下，比手动 ps | grep | kill 省心。

终端中执行 app-server 重启脚本的截图

横向看，这一步意味着什么

Codex 这次大更新里塞了一堆功能：Computer Use、内置浏览器、记忆、自动化、跨天唤醒任务、90 多个插件。SSH 在所有这些 feature 里显得「土」，但它解决的是一个最基础的问题——Codex 到底在哪台机器上跑。

之前的答案有点尴尬。Web 版跑在 OpenAI 的云沙箱里，干净但隔离；本地 CLI 跑在你电脑上，灵活但要装环境；桌面 App 也跑在本地，加了 UI 但没解决环境问题。这三种形态都假设「代码和算力在同一台机器」。

但现实是大量开发者的代码不在自己手边。有人用 MacBook 但项目跑在 Linux GPU 机；有人 Windows 写代码但部署是 Docker 容器；有人一台薄本搭多台云开发实例分项目。SSH 直连补的就是这块——让 Codex 跟开发者的真实拓扑对齐。

这其实也是 Cursor、Windsurf、Continue 这些竞品的弱项。它们大多假设你在本地 VS Code 里开发，远程开发要靠 VS Code Remote 那套。Codex App 把 SSH 做成一等公民，对那部分「键盘在 Windows、编译在 Linux」的用户来说是直接的产品力差距。

顺带说一句，远端跑 Codex CLI 涉及到 API 路由的，如果你不想反复折腾 ChatGPT 登录、不想被官方账号区域限制卡住，可以考虑在远端走 OpenAI Hub 这类聚合服务——一个 Key 调 GPT、Claude、Gemini、DeepSeek，OpenAI 格式兼容，Codex CLI 直接当成 model_provider 配进去就行，国内服务器直连也省心。

一些遗留的小问题

这毕竟是 Alpha 版本，几个明显的粗糙之处：

连接断开后，远端 app-server 不会自动清理，长时间下来会留一堆僵尸进程；
多窗口同时连同一台远端机的行为还没明确，会话隔离做得不好；
Windows 端对 SSH 配置的依赖比较硬，OpenSSH 客户端版本太老的话会连不上，建议用 Windows Terminal 自带的那个版本；
AGENTS.md 的解析在远端跟本地一致，但路径相关的规则要写远端绝对路径，别套本地的。

这些问题大概率会在后续几个版本里收敛。但 SSH 这个能力本身值得现在就接上——尤其是过去用 Samba 凑合的那批人，迁移成本接近零，体验提升肉眼可见。

参考来源

linux.do：codex app 通过 ssh 连接 linux 上的 codex cli 开发 —— 社区里最早的实操贴，两个核心坑和重启脚本都来自这里
Reddit：允许您在远程 SSH 中使用 codex cli 的脚本 —— Codex CLI 在远端登录授权的解决方案
GitHub：codex-remote-web —— 第三方开源的手机控制本机 Codex 项目，可以作为 SSH 方案之外的另一种思路参考

Codex App 接入 SSH：本地界面直连远端 CLI