Codex 正在一个接一个地拆除开发者工作流中的边界。最新的 Handoff 功能瞄准了本地与远程之间的那堵墙：你在笔记本上让 Codex 重构代码写到一半，需要出门——一条自然语言指令就能把整个线程连同 Git 状态迁移到远程服务器，回家后再拉回来。不需要手动 stash、不需要写迁移脚本、不需要在两台机器之间同步状态——模型替你处理了所有的中间步骤。
这背后有一个违反直觉的逻辑：当你让模型坐上驾驶位，你反而需要更少的基础设施。 过去，跨设备开发意味着搭建 CI/CD pipeline、配置同步工具、编写部署脚本。现在，Codex 把 worktree 创建、状态传输、运行位置切换全部内化为 Agent 的能力——开发者只需要说一句话。截至 2026 年 6 月，Codex 已拥有超过 500 万周活跃用户，其中 20% 是非开发者。Handoff 的上线标志着 OpenAI 把 Codex 从代码工具推向了开发工作流操作系统。
Handoff 是什么：不是云同步，是线程级状态迁移
Handoff 的核心机制可以用一句话概括：将一个正在运行的 Codex 线程及其完整 Git 状态（未提交改动、当前分支、worktree 上下文）从一台设备迁移到另一台设备。
与传统的 git stash + push + 远程 pull 工作流不同，Handoff 传输的不只是代码变更，而是整个 Agent 会话状态——对话历史、执行上下文、中间产物全部保留。过去完成同样的事情，开发者需要：手动 stash 未提交改动、push 到远程仓库、SSH 登录远程主机、pull 代码、恢复工作环境、重新向 AI 解释上下文。Handoff 把这六步压缩成一句自然语言指令。这就是"模型驾驶"的含义：复杂度没有消失，但从开发者的肩膀转移到了 Agent 身上。
根据 OpenAI 官方文档，Handoff 的技术流程分四步：
第一步，Codex 在目标主机上创建或复用一个 Git worktree。Worktree 是 Git 的原生特性，允许在同一仓库下维护多个独立的工作目录，共享 .git 元数据但互不干扰。Codex 利用这一特性确保迁移不会覆盖目标主机上已有的工作。
第二步，传输线程状态和 Git 状态。这包括未提交的改动（staged 和 unstaged）、当前分支信息、以及 Codex 线程的完整对话上下文。
第三步，切换线程的运行位置。原设备上的线程停止活动，目标主机接管执行。如果线程正在运行中，Handoff 会先中断当前响应再进行传输。
第四步，用户在目标主机上继续工作。所有后续操作（文件读写、命令执行、测试运行）都发生在远程主机上。
值得注意的是，被 .gitignore 忽略的文件默认不会随 Handoff 迁移，除非 Codex 通过 .worktreeinclude 机制将其显式纳入。这意味着 node_modules 或 .env 等文件需要在远程主机上单独配置。
配置前提：一次性搭桥，之后全交给模型
Handoff 的设计哲学是"前置投入换持续自动化"。初始配置需要四个条件，但一旦完成，之后每次跨设备迁移都是零手动操作——模型自己处理 worktree 创建、状态序列化、传输和恢复。
SSH 连接配置——在 Codex App 的 Settings > Connections 中添加远程主机。Codex 读取本地 ~/.ssh/config 中的 Host 别名并通过 OpenSSH 解析。远程主机必须能通过 ssh hostname 直接连接，不支持交互式密码登录，建议使用 Ed25519 密钥认证。
远程安装 Codex 并认证——远程主机必须安装 Codex 并完成登录，且 codex 命令在远程用户的登录 shell PATH 中可用。Codex App 通过 SSH 启动远程的 app server。两台设备必须登录同一个 ChatGPT 账户。
同一仓库的克隆——远程主机上必须有与本地相同 Git 仓库的克隆，并且在 Codex 中保存为项目。如果本地项目是仓库子目录，远程也必须配置完全一致的子目录路径。Codex 只会显示匹配的目标项目作为 Handoff 可选目的地。
Git 远程仓库访问——如果是私有仓库，远程主机需要提前配置好 SSH Key 或其他认证信息，确保能访问同一个 Git 远程仓库（例如 GitHub、GitLab）。
安全层面，OpenAI 文档明确强调：远程连接使用 SSH 端口转发配合本地 WebSocket 监听器，不要将 app-server 直接暴露在公共网络上。如果远程主机不在当前网络内，应使用 VPN 或 Tailscale 等 mesh 网络工具。
两种触发方式：UI 操作 vs 自然语言
Handoff 可以通过两种方式触发。
第一种是 UI 操作：打开 Codex App 中的线程，在底部选择当前运行位置，切换到目标主机，确认目标和分支后点击"Hand off"。要把远程线程拉回本地，选择"This computer"即可。
第二种是自然语言指令：在另一个线程中用自然语言告诉 Codex 进行迁移。例如："把我正在跑的 feature-auth 线程迁移到 devbox 上继续运行。"Codex 会识别线程名称和目标主机，自动完成整个流程。需要注意的是，Codex 不能迁移发出请求的线程本身——你必须从另一个线程发起 Handoff 指令。
此外，Handoff 目前不支持迁移到 Codex Cloud 环境，仅限本地设备与 SSH 远程主机之间的双向迁移。
典型使用场景：通勤不再是代码的断点
Handoff 解决的核心场景是**"AI 正在改代码，但我得走了"**。以下是三个典型工作流：
场景一：办公室到家的无缝衔接。 下午5点，Codex 正在本地执行一次大规模重构任务。你需要离开办公室。通过 Handoff 将线程迁移到家中的开发服务器，Codex 在远程继续运行。到家后，打开 Codex App 查看进度，确认结果后将线程拉回本地笔记本的 IDE 环境。
场景二：笔记本到高性能工作站的算力切换。 你在笔记本上启动了一个涉及大量测试的任务，但笔记本的 CPU 和内存不够用。Handoff 到配置更高的远程工作站，让测试在那里跑完，再把结果拉回来。
场景三：多设备协作下的任务监控。 通过 ChatGPT 移动端的 Codex 远程控制功能（已支持 iOS、Android），你可以在手机上监控 Handoff 到远程的线程进度，发送后续指令、批准命令、查看 diff 和测试结果。通勤路上也能保持对任务的掌控。
竞品对比：Codex Handoff vs Claude Code Remote Control
Anthropic 的 Claude Code 在 2026 年 2 月发布了 Remote Control 功能，同样解决"离开桌面后继续编程"的问题，但技术路径和能力范围有显著差异。
架构差异。 Claude Code Remote Control 的核心是远程监控和指令发送——会话始终运行在本地机器上，手机端通过 Anthropic API 中继 TLS 加密连接来控制本地会话。代码和 MCP 服务器不离开本地。Codex Handoff 则是真正的状态迁移——线程和 Git 状态物理转移到另一台主机上运行，本地设备可以完全关机。
适用场景差异。 Claude Code Remote Control 更适合"离开桌面但笔记本保持开机"的场景——你走开了，但机器还在跑，手机只是遥控器。Codex Handoff 更适合"需要关机或切换设备"的场景——合上笔记本盖子，任务在另一台机器上活着。
配置复杂度差异。 Claude Code Remote Control 的使用极其简单：在终端运行 /rc 命令，扫描 QR 码，手机即可接管。不需要配置 SSH、不需要远程安装 Claude Code、不需要同步仓库。Codex Handoff 的前置配置要求更高（SSH + 远程安装 + 同仓库 + 同账户），但换来的是真正的跨设备、跨网络能力。
能力边界差异。 Claude Code Remote Control 不能将任务从一台机器迁移到另一台机器——它是"远程遥控"而非"远程迁移"。如果本地机器断电或断网，会话就中断了。Codex Handoff 在迁移完成后，原设备可以完全离线。不过，Claude Code 支持 1M token 上下文窗口（Claude Opus 4.7 / Sonnet 4.6），而 Codex 使用 GPT-5.2-Codex 的 200K 上下文窗口。
从市场数据看，Claude Code 在 npm 月下载量上以 4630 万对 Codex 的 1400 万保持 3.3 倍优势，但 Codex 的周活用户增长更快——从 3 月的 200 万增长到 6 月的 500 万。两者的竞争焦点正从"谁写代码更好"转向"谁的工作流生态更完整"，而 Handoff 和 Remote Control 正是这场生态战的典型交锋。
Handoff 的当前限制
仅限 Codex App，CLI 暂不完整支持。 虽然 CLI 有 /app 命令可以将线程移交到 Codex Desktop，但完整的远程 Handoff 流程目前主要在 Codex App 中体验最佳。CLI 到远程主机的直接 Handoff 仍处于 alpha 阶段。
.gitignore 文件不随迁。 Handoff 依赖 Git 操作传输状态，因此被 .gitignore 排除的文件（环境变量、依赖目录、本地配置）不会自动迁移。开发者需要在远程主机上预先配置好这些依赖，或者使用 .worktreeinclude 显式指定。
不支持迁移到 Codex Cloud。 Handoff 目前仅支持本地设备和 SSH 远程主机之间的迁移，不能将线程迁移到 Codex 的云沙箱环境。这限制了不拥有远程服务器的个人开发者的使用场景。
SSH 配置是唯一的人工门槛。 对于不熟悉 SSH 的开发者，前置设置（密钥管理、SSH config、远程 PATH 配置）可能构成上手障碍。但这是一次性投入：完成后，所有后续的跨设备迁移都由模型自动处理。相比之下，Claude Code Remote Control 的 /rc + 扫码体验在初次使用上更轻量，但它解决的是"遥控"而非"迁移"——两者的配置成本差异反映的是能力边界的差异。
alpha 阶段的稳定性风险。 OpenAI 文档明确标注 SSH 远程连接为 alpha 功能，可能随时变更。依赖 Handoff 构建关键生产工作流存在风险。
更深的信号：模型驾驶，基础设施反而变少了
Handoff 表面上是一个跨设备迁移功能，但它代表的趋势比功能本身重要得多：当模型成为工作流的驾驶者，开发者需要维护的基础设施反而减少了。
回想一下"前 Agent 时代"的跨设备开发：你需要搭建 CI/CD pipeline 来自动化构建和部署，需要配置 dotfiles 同步工具来保持多台机器的环境一致，需要写 Makefile 或 shell 脚本来标准化开发流程，需要维护 Docker 镜像来确保环境可复现。这些基础设施的存在，本质上是因为人类需要一个可预测的、标准化的环境来减少认知负担。
但当 Agent 坐上驾驶位，情况变了。Codex 不需要你的 dotfiles 同步——它自己知道如何在新 worktree 中设置环境。它不需要你的迁移脚本——它理解 Git 状态的语义并自动处理传输。它不需要你的部署 pipeline——它能直接在远程主机上执行任务。每一层被模型接管的操作，都是一层你不再需要手动搭建和维护的基础设施。
对于独立开发者来说，这意味着一个人也能拥有以前只有配备 DevOps 工程师的团队才有的跨设备工作流：在咖啡厅启动任务，在地铁上用手机监控进度，到家后在高性能主机上查看结果——中间没有任何手动操作。
对于小型团队来说，Handoff 与 Codex 的 worktree 并行能力结合后，可以实现"多任务并发"——一个线程跑测试、一个线程做重构、一个线程处理 PR review，分布在不同设备上，通过 Codex App 统一监控。过去做到这一点需要 Kubernetes 或至少一套自定义的任务调度系统；现在需要的只是一个 SSH 配置和一句自然语言。
当然，前提是你完成了那次一次性的 SSH + 远程安装配置。这不是开箱即用的功能，目前仍处于 alpha 阶段。但方向已经清晰：AI 编程工具的竞争终局，不是比谁的代码补全更准，而是比谁能让开发者用更少的基础设施做更多的事。Removing boundaries one at a time.
