本地 Codex 接上远程开发环境，先把哪一份目录当作准？

共享网络出口不会自动复制工作目录

旧项目地址 codex-remote-bridge 目前跳转至 codex-remote-Skill。README 将用途写得很清楚：服务器上的 Codex CLI 借用本地可用的 HTTP 代理或网络。它没有把本地项目上传为远程工作区，也没有把两个客户端的聊天合并。准备修改代码时，应先确定项目文件实际存放的位置。

可在计划使用的终端里运行 pwd，再检查 git status --short --branch 和 git rev-parse HEAD。这里的 HEAD 只能标识提交，未提交修改还需看状态。两台机器的提交相同，不代表当前文件也相同；传输或同步项目应另选明确的方法，不能由代理隧道来推定。

pwd
git status --short --branch
git rev-parse HEAD

反向转发的监听端在服务器

OpenSSH 的 -R 选项在远端建立监听，再通过连接将数据送向本地指定目标。项目示例把服务器的 127.0.0.1:17891 转到本地 HTTP 端口；直接网络方案使用 11450，有代理软件时则采用它真实提供的 HTTP 或 mixed 端口。示例端口只是配置，不是所有设备都已具备的服务。

SSH 窗口保持打开，只能说明隧道进程还在。项目使用 ExitOnForwardFailure 检查监听是否建立，它不能验证本地代理或最终服务。核对 SSH 参数时保留主机指纹验证，并检查监听确实限于回环地址；同一服务器上的其他用户仍可能访问该回环端口。

代理文件需要由启动进程实际读取

仓库的 codex_with_proxy.py 只提取已允许的代理变量，随后用更新后的环境启动 Codex，不执行环境文件中的任意 shell 内容。它的 --check 只验证配置格式，明确不测试网络。把代理地址写入文件之后，已经运行的进程不会因此自动换用新地址。

排查时应区分代理监听与目标服务响应。HTTP CONNECT 返回已建立连接，只说明隧道协商成功；还需确认后续响应来自目标服务。账号登录和模型请求另有条件，不应把一次 curl 返回写成 Codex 已能完成开发任务。本文没有执行真实服务器上的这些检查。

试运行先使用服务器上的独立样例

连通之后，可在服务器的临时样例项目中提出一个只读请求，让 CLI 报告当前目录和可见文件。确认读的是预期目录后，再安排实际修改，并用该项目自己的测试检查结果。本地编辑器显示某份代码，不能作为远程 CLI 已读取同一文件的证据。

本次依据仓库当前文档与启动器源码解释执行位置，没有传输登录凭据，也没有完成 GPU 服务器上的端到端测试。停止使用时应按仓库说明关闭隧道，并恢复本次变更前保存的代理配置；项目文件和正在运行的训练任务不属于代理配置的清理范围。