这次我们来看一个很实际的远程编程问题电脑上装了 Codex人不在电脑前怎么用手机接着用更进一步能不能把电脑、手机、多个模型打通同一个会话在设备之间切换不丢上下文也不改工作目录这种需求在本地开发机、云主机、多设备办公场景里非常常见。Codex 是 OpenAI 的编程代理工具通过命令行和终端交互可以理解项目代码库、修改文件、执行命令相当于一个能在终端里干活的 AI 工程师。它本身不是一个必须依赖本地强显卡的重型模型而是更接近“客户端 服务端”的编程代理。所以远程化的核心不在于把显卡搬出来而是把终端会话搬到远程主机上再用手机去接管这个会话。这篇文章围绕三件事展开第一怎么在一台常开的电脑或云主机上把 Codex 跑起来第二手机怎么通过 SSH 连入同一个会话实现断线不丢任务第三怎么在 Codex 里配置多个模型服务让同一个工作目录、同一套配置在电脑和手机上互通。内容不依赖特定显卡更像一套通用部署和验证流程适合远程开发、批量代码任务、多设备办公的读者直接收藏。1. 核心能力速览能力项说明项目类型AI 编程代理工具基于命令行交互主要功能代码理解、文件修改、命令执行、多模型切换、远程会话部署方式CLI 安装 远程主机常驻会话推荐硬件普通开发机能跑本地推理场景需按模型实际测试显存占用非本地推理场景基本不占用接入本地模型时以实际测试为准支持平台Linux、macOS、WindowsWSL手机通过 SSH 客户端接入启动方式命令行启动 tmux/systemd 保持会话接口 API可通过兼容 OpenAI 接口的服务暴露需自行鉴权批量任务可通过非交互模式或任务队列循环实现适合场景多设备办公、远程调试、批量代码任务、模型对比测试从材料看Codex 最大的特点是“终端优先”。它没有把大量功能藏在 WebUI 里而是把所有操作都收敛在命令行会话中。这个特性对远程使用反而很友好终端协议成熟SSH 可以直接接管手机上的终端客户端也能胜任。远程部署的核心不是折腾图形界面而是把会话、鉴权、模型配置三件事处理好。2. 适用场景与使用边界适合场景有两类。第一类是“人不在电脑前但任务不能停”比如在家里远程看到开发机上的 Codex 正在跑批量代码修改用手机连上去查看日志、补充一条指令、调整参数。第二类是“多台设备共用同一个开发环境”办公室电脑、家用笔记本、手机都接入同一台主机工作目录一致模型配置一致上下文也一致换设备不需要重新描述需求。不适合什么如果你的需求是图形化界面、拖拽式操作、可视化配置模型参数Codex 命令行本身并不是最佳选择。如果你希望完全不维护服务器只想在浏览器里打开一个页面使用那么更适合去找在线 IDE 或云端编程服务而不是自己部署 CLI 加远程会话。还有一类需要注意的场景是公共网络不要把没有任何鉴权的 API 服务直接暴露到公网否则别人可能盗用你的密钥和计算资源。使用边界必须强调合规。Codex 会读取项目文件、执行命令、向模型服务发送代码内容。涉及公司内部代码、个人隐私数据、未公开的算法时要先确认数据是否允许发给第三方模型服务。开源项目也要看许可证约束不能随意把受限代码交给外部模型处理。涉及声音、图像、人脸等素材时同样需要先确认授权。远程部署只是技术手段不改变内容使用的合规义务。3. 环境准备与前置条件远程使用 Codex 最少需要三块东西一台常开主机、一个 SSH 通道、一个终端客户端。主机负责运行 Codex 和保持任务状态SSH 负责把手机和电脑连接到这台主机终端客户端负责交互输入。3.1 主机端要求操作系统建议选 Linux 或 macOSWindows 用户优先考虑 WSL2终端行为和类 Unix 工具链更接近服务器环境。确保主机可以长时间供电、联网休眠策略要关掉避免人不在的时候任务中断。磁盘空间按项目大小准备。Codex 本身占用不大但代码仓库、日志、模型输出会逐渐积累。如果只是远程 API 客户端主机不需要独立显卡如果后续要接本地模型再按本地模型的显存和内存要求评估。3.2 软件依赖Node.js 环境或者直接下载 Codex CLI 官方发布包具体方式以项目仓库说明为准。SSH 服务端。Linux 主机一般需要安装并启用 openssh-serverWindows 需要开启 OpenSSH Server 功能。tmux 或 screen用于保持长会话。没有这一步手机断开网络时正在运行的任务可能被直接中断。手机端准备一个支持 SSH 的终端客户端例如 Termius、JuiceSSH 等电脑端直接用系统自带终端即可。3.3 鉴权信息Codex 通常需要登录或配置 API Key。你要准备好对应的模型服务密钥并把密钥放在环境变量或配置文件中不要写进代码仓库。如果同时使用多个模型服务每个服务都有自己的密钥建议分开管理避免切换模型时串号。4. 安装部署与启动方式4.1 安装 Codex CLI下面给的是通用安装思路实际命令需要以 Codex CLI 当前版本文档为准# 检查本地 Node.js 环境 node -v npm -v # 全局安装 Codex CLI如果你使用的是 npm 发布版 npm install -g openai/codex # 或者从官方仓库的 Releases 页面下载对应平台的二进制包安装完成之后先执行版本检查确认命令能跑起来codex --version如果能输出版本号说明安装成功。如果提示找不到命令需要检查 npm 全局目录是否写入了 PATH或者二进制文件是否有可执行权限。4.2 完成认证认证方式以官方文档为准。常见方式是在主机上执行登录命令或者把 API Key 写入环境变量# 通用登录流程具体子命令以实际版本为准 codex login # 也可以通过环境变量提供密钥 export OPENAI_API_KEYyour-key-here这里要注意一个问题环境变量只在当前终端会话里生效。如果你通过 SSH 登录后再用 tmux 启动 Codex环境变量必须提前注入到 tmux 会话中否则重启 Codex 时会找不到密钥。更稳妥的做法是把密钥写入用户的 profile 文件并设置好权限。4.3 使用 tmux 保持常驻会话先启动一个 tmux 会话在会话里启动 Codex# 在远程主机上执行 tmux new -s codex # 进入 tmux 后启动 Codex codex这样做的意义是即使手机 SSH 断开、电脑休眠、网络切到别的 Wi-Fitmux 会话仍然在远程主机上运行。再次连接后只需要恢复会话tmux attach -t codex如果已经有一个 Codex 会话在跑不进入 tmux 直接再启动一个会产生混乱。建议固定使用同一个会话名例如codex并在操作前先确认当前是否已有同名会话tmux ls4.4 开机自启思路如果要让远程主机重启后自动恢复 Codex 会话可以用 systemd 服务或者 tmux 恢复脚本。systemd 服务适合当作常驻后台任务管理但 Codex 是交互式命令行工具直接放进服务里会丢失交互能力。更常见的是手动创建会话或者写一个启动脚本在重启后执行以下逻辑# 如果没有名为 codex 的会话则创建并启动 if ! tmux has-session -t codex 2/dev/null; then tmux new -s codex -d tmux send-keys -t codex codex Enter fi这种方式保留了交互界面也适合手机连接后直接 attach。5. 远程访问电脑、手机、多设备互通远程访问的核心不是给 Codex 做 Web 界面而是让不同设备通过 SSH 进入同一台主机上的同一会话。这里给出三套方案按使用场景选择。5.1 方案 A局域网直连 SSH条件手机和电脑在同一局域网内远程主机 IP 固定。手机端打开 SSH 客户端填写主机 IP、端口、用户名、密码或密钥连接成功后输入tmux attach -t codex电脑端做法一样ssh user192.168.1.100 tmux attach -t codex这个方案的优点是低延迟、不需要公网配置缺点是离开局域网就断。如果只是在家、办公室内使用优先选这个。5.2 方案 B云主机公网 SSH条件有一台公网可达的云主机或者把家里主机通过安全方式暴露到网络中。建议使用密钥登录不要长期使用密码登录# 在本地生成密钥 ssh-keygen -t ed25519 -C mobile-codex # 上传公钥到远程主机注意端口按实际配置调整 ssh-copy-id -p 2222 useryour-host之后手机和电脑都通过密钥登录ssh -p 2222 useryour-host tmux attach -t codex公网场景要格外注意安全不要使用默认的简单密码尽量禁用密码登录防火墙只放行需要的端口如果云厂商提供安全组要限制来源 IP。把 SSH 服务直接暴露在公网本身有被扫描的风险所以密钥管理和访问控制不能省。5.3 方案 C通过 SSH 隧道访问 API 服务如果你希望手机上的脚本、小工具能直接调用远程主机上的模型接口而不只是进终端输入命令可以用 SSH 隧道把远端端口映射到本地ssh -N -L 8000:127.0.0.1:8000 -p 2222 useryour-host执行后本地的http://127.0.0.1:8000会透传到远程主机的127.0.0.1:8000。手机如果不会开隧道可以先连入远程主机再用 curl 测试或者在局域网内直接配置服务监听地址并做好鉴权。这种方式适合作为内部调试通道不要把它当作没有认证的公网 API 网关。5.4 多设备会话的协作方式同一台主机上同一个 tmux 会话可以被多个设备 attach但注意这是“共享控制台”而不是“多人协作编辑器”。手机输入一条指令电脑端能看到过程电脑端敲了命令手机端也能看到输出。适合一个人在不同设备间切换不适合两个人同时往会话里输入。如果需要并行跑多个任务就拆成多个 tmux 会话tmux new -s codex-task1 tmux new -s codex-task2手机端连入时分别 attach 对应会话工作目录和任务状态互不干扰。6. 多模型接入与切换Codex 的远程价值不仅是换设备还包括换模型。同一个代码仓库可以让模型 A 做代码理解让模型 B 做代码生成再让模型 C 做审查。前提是把不同模型服务配置到 Codex 的模型提供方列表里。6.1 配置多个模型服务不同版本的 Codex 配置方式会有差异下面是一个示意结构不要直接照搬。关键是理解“默认模型”和“多个模型提供方”的关系# 示意Codex CLI 配置文件中的模型提供方列表 model your-default-model-id model_provider provider-a [model_providers.provider-a] name Provider A base_url https://api.example-a.com/v1 env_key API_KEY_A [model_providers.provider-b] name Provider B base_url https://api.example-b.com/v1 env_key API_KEY_B实际配置时要以 Codex CLI 当前版本的官方文档为准。不同服务商的base_url、请求路径、模型名称可能不同需要按各自服务说明填写。配置完成后在 Codex 交互界面里可以通过模型切换命令查看和选择可用模型具体命令可以用codex --help或者会话内的帮助命令确认。6.2 模型切换的验证思路切换模型后最简单的验证方法是让模型回答一个和当前代码库相关的简单问题比如“这个项目里入口文件在哪里”。观察返回内容是否正常再检查服务端的请求日志确认请求确实打到了对应的模型服务。不同模型对同样指令的输出差异很大不要只看是否“有输出”还要看输出是否符合预期。需要提醒的是频繁在不同上下文长度、不同能力的模型之间切换可能会导致对话状态不一致。如果切换模型后出现异常不要在同一会话里反复折腾直接退出 Codex 重启会话再切换模型。6.3 电脑、手机、多个模型互通的最终形态把远程访问和多模型配置组合起来就形成了文章标题里说的状态Codex 跑在远程主机上电脑和手机只是两个显示终端多个模型服务配置在同一个环境里按任务类型随时切换。手机连上主机后可以查看昨天的任务状态可以给 Codex 下达一条新的修改指令也可以切换到另一个模型重新处理同一个问题。因为工作目录和对话上下文都在远程主机设备切换不会造成环境分裂。7. 功能测试与效果验证不管用什么远程连接方式第一次部署结束后建议按下面顺序做一套完整测试。7.1 测试远程启动操作步骤# 手机或电脑 SSH 登录远程主机 ssh userremote-host # 启动新的 tmux 会话 tmux new -s codex # 启动 Codex codex预期结果Codex 进入交互界面可以正常输入问题。判断标准输入一句“请输出 hello”能看到模型返回结果。7.2 测试断线恢复操作步骤手机 SSH 连接后进入 tmux启动 Codex然后直接关闭手机客户端或切到飞行模式。等待十几秒后重新连接执行tmux attach -t codex预期结果Codex 界面还在历史输出还在任务没有因为断线而中断。判断标准如果之前让 Codex 执行一个长任务断线恢复后任务仍然继续而不是报错退出。7.3 测试多设备切换操作步骤手机端进入 tmux 会话并输出一条指令电脑端也 SSH 连接同一主机attach 同一会话查看手机端操作留下的输出记录。预期结果两端看到的内容一致会话状态同步。判断标准电脑端 attach 后不需要重新启动 Codex能直接看到手机端输入之前的上下文。7.4 测试模型切换操作步骤在当前 Codex 会话里查询可用模型切换到另一个模型再问同一个问题。预期结果模型可以成功切换输出结果与之前明显不同或至少能正常返回。判断标准切换后不报鉴权错误不报模型不可用不出现会话跳闪或反复加载。7.5 测试代码仓库理解操作步骤在远程主机的某个项目目录里启动 Codex输入“请分析一下这个项目的目录结构并说明入口文件在哪里”。预期结果Codex 能读取项目文件给出准确的目录和入口文件描述。判断标准返回内容能对应到真实文件而不是泛泛而谈。7.6 测试文件修改与命令执行操作步骤让 Codex 修改一个简单的函数比如把日志输出从print改为logger.info修改完成后运行测试命令。预期结果Codex 修改了文件然后执行了相关命令并在会话中报告结果。判断标准查看远程主机上的文件内容确认改动真实发生。如果以上六项都通过说明远程会话、多设备接入、多模型切换、代码操作能力都正常。后续可以按项目实际情况增加批量任务和 API 调用测试。8. 接口 API 与批量任务8.1 接口调用示例Codex 远程使用中API 调用有两种含义。一种是接入兼容模型服务通过 HTTP 请求调用模型接口另一种是把 Codex 或模型服务封装成内部接口供脚本调用。无论哪种接口请求格式都以实际服务文档为准。下面是一个通用 HTTP 调用示例需要按你的服务地址、密钥、模型名替换curl http://127.0.0.1:8000/v1/responses \ -H Authorization: Bearer your-key-here \ -H Content-Type: application/json \ -d { model: your-model-id, input: 解释一下这个项目的作用 }如果返回 JSON说明接口通路正常。如果返回 401说明鉴权信息错误如果返回 404说明请求路径不对需要核对服务文档。8.2 Python 调用示例更常见的场景是写一个 Python 脚本把多个任务批量发给模型处理import requests import time API_URL http://127.0.0.1:8000/v1/responses API_KEY your-key-here HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json, } tasks [ {name: task1, instruction: 给下面代码补注释}, {name: task2, instruction: 检查这个函数是否存在未处理异常}, ] for task in tasks: payload { model: your-model-id, input: task[instruction], } try: resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout120) resp.raise_for_status() print(f{task[name]} success: {resp.json()}) except Exception as exc: print(f{task[name]} failed: {exc}) time.sleep(2)这里强依赖具体接口路径和返回结构真正落地前先跑通单个请求再放大批任务避免一次把大量请求打爆。8.3 远程主机上的批量任务队列如果主机端已经装好 Codex CLI并且当前版本提供非交互模式可以用循环方式处理一批提示词。下面的命令是通用模板具体参数需要按 CLI 帮助信息替换for f in ./tasks/*.txt; do echo running task: $f codex exec --prompt $(cat $f) --skip-git-repo-check sleep 5 done如果当前版本不支持这类参数不要硬套改用上一小节的 HTTP 调用方式。批量任务最怕的不是慢而是失败后无法定位。建议每次都写入日志文件codex exec --prompt $(cat $f) ./logs/$(basename $f).log 218.4 接口安全要求对外提供 API 前至少要保证三点使用密钥或 Token 鉴权只在内网或 SSH 隧道内访问敏感操作前做用户确认。不要把带密钥的服务直接绑定到公网端口也不要为了图方便把 API Key 写死在手机脚本里。远程主机的日志里可能包含完整请求和响应内容日志目录的权限也要收紧。9. 资源占用与性能观察Codex 作为编程代理资源占用主要取决于“你是否接入本地模型”。如果只接入远程 API主机主要用于运行 CLI、终端会话、代码索引和文件读写负载一般不高。如果接了本地模型推理时的显存和内存占用需要重点观察。先看系统资源# 查看 CPU 和内存占用 top # 查看内存状态 free -h # 查看磁盘 df -h如果用到 GPU再看显存nvidia-smi判断思路Codex 交互卡顿时先看是不是主机 CPU 或磁盘占用过高接入本地模型生成结果慢时看显存是否打满、有没有频繁换入换出手机端输入延迟大时看网络往返和 SSH 连接质量。长会话会影响两件事一是终端输出日志不断累积占用磁盘二是对话上下文变长后每次请求的 token 数量增加接口延迟和费用都会上升。如果发现 Codex 越来越慢先尝试开一个新的会话而不是在旧会话里无限追加内容。性能优化可以这样做批量任务拆小控制在单个会话可处理的规模长项目先让 Codex 定位相关文件再进入具体文件修改避免一次性读取整个仓库远程主机保持干净关闭不需要的服务避免 CPU 被其他任务抢占。10. 常见问题与排查方法下表中列出的问题都是远程使用 Codex 过程中容易遇到的排查顺序是从外层网络逐步向内层配置推进。问题现象可能原因排查方式解决方案手机 SSH 连接不上端口未开放、IP 错误、防火墙拦截检查 ssh 端口、ping、防火墙状态放行端口修正主机地址登录后任务丢失没有使用 tmux/screen查看是否有长时间运行进程使用 tmux 保持会话Codex 提示认证失败API Key 未注入、登录过期执行 env 检查环境变量重新登录或重新导出 Key切换模型后异常模型配置字段错误查看配置文件和请求日志按官方文档修正配置接口调用返回 401鉴权头缺失或密钥错误抓取请求头、核对密钥修改 Authorization 信息接口调用返回 404请求路径错误查看服务文档、检查路由更换正确请求路径批量任务卡住请求没有超时控制查看脚本执行位置增加 timeout 和失败重试手机端显示乱码终端字符编码不对检查 SSH 客户端编码设置切换 UTF-8 编码Codex 输出很慢上下文过长或网络延迟查看请求耗时和 token 数新开会话、缩小任务范围断线后重新 attach 界面卡死多设备同时操作或终端尺寸异常检查 tmux 状态和当前宽度恢复单端操作或执行 resize 命令遇到问题建议按这个顺序检查网络能不能通登录能不能过模型配置对不对任务有没有上下文残留。不要一上来就重装 Codex很多远程问题出在 SSH 通道、防火墙、密钥权限这些外层环节。11. 最佳实践与使用建议第一远程主机上固定一个会话管理习惯。不要每次重新tmux new -s codex而是先tmux ls看有没有旧会话。长期使用后建议把常用会话名固定下来比如codex-work、codex-build避免设备多了之后忘记任务在哪个会话。第二把模型配置和密钥分开管理。配置文件可以放进用户目录密钥通过环境变量注入。不要把多个云服务的密钥写在同一份会被同步到代码仓库的文件里。可以使用chmod 600限制配置文件权限。第三批量任务要设计成“可重跑”。每个任务独立写日志失败后不能影响后续任务最好支持按任务名重试。脚本开头要记录时间、模型版本、输入文件路径这样结果出了问题还能回溯。第四涉及代码隐私。Codex 会把代码片段发送给模型服务如果是公司核心代码或未公开项目要先确认服务条款和公司数据安全要求。远程主机如果多人使用还要考虑文件权限和会话隔离。第五利用 Git 做安全网。在让 Codex 大规模修改代码前先执行一次git commit保证可以回滚。不要在没有版本控制的项目里直接让 AI 批量替换文件否则改坏了很难恢复。第六手机端只做轻量操作。手机屏幕小输入复杂 prompt 成本高适合查看任务进度、执行简单命令、恢复 tmux 会话。复杂需求可以先在电脑端准备好 prompt再让手机端触发批量任务。12. 总结与下一步先说结论这套玩法的核心不是找到一个装好的手机 App而是把 Codex 跑在一台随时能连上的主机上用 SSH、tmux 和配置文件解决“设备、会话、模型”三个问题。最值得先验证的是断线恢复只要 tmux 用起来任务就不会因为手机锁屏而中断。最容易踩的坑有两个一是没有用 tmuxSSH 一断任务就没了二是多模型配置里的字段名和请求地址照抄旧教程导致切换模型时报错。多模型互通并不是什么黑魔法本质就是把不同模型服务写进同一个配置文件在会话里按需切换。下一步可以做的事情很多给远程主机的 Codex 加一个批量任务脚本把重复的代码检查交给它跑把模型切换流程测试完整找出哪个模型适合重构、哪个模型适合解释代码再进一步可以把这套远程会话方案集成到自己的 CI 或定时任务里让 AI 编程助手变成一台真正 7x24 小时待命的远程开发队友。建议先把第一套 SSH、tmux、Codex 的最小组合跑通再往里面加模型最后再碰批量任务和接口调用。