Codex 远程控制实战：多设备连接配置与三个真实场景

先说结论：远程控制不是把手机变成开发机，而是把手机变成任务控制台。

想通这一点，配置方式和用法都会变简单。

配置：三步

1. 在被控机器上开启远程访问，并生成一个一次性配对码
2. 在控制端输入配对码，绑定到你的账号
3. 设置权限白名单：允许哪些目录、允许哪些命令

第 3 步最容易被跳过，也最重要。没有白名单的远程访问，等于给了一张不限额度的授权。

# ~/.codex/remote.toml
allowed_dirs = ["~/projects", "~/vault"]
allowed_commands = ["git", "npm", "node", "python"]
deny_commands = ["rm -rf", "git push --force"]

场景一：手机发起，电脑做 PPT

通勤路上想到一个分享主题，手机上发一条指令：

用 ~/vault/notes/产品定位.md 的内容，做一份 10 页的分享稿，风格参考 DESIGN.md，输出到 ~/projects/slides/。

到家打开电脑，文件已经在那了。你只需要在电脑上做最后的文案调整。

价值：把”灵感出现的地方”和”执行发生的地方”解耦。

场景二：推送 GitHub

改完一个小 bug，在手机上：

跑一遍测试，通过后提交，commit message 按 conventional commits 写，然后推送到当前分支。

整个过程你只发了一句话，但你仍然应该在电脑上看一眼 diff 再合并。远程控制省的是操作，不是判断。

场景三：一台机器控制另一台

我有台常开的机器专门跑定时任务。需要临时加任务时，从笔记本上远程派活：

在常开机上，把 scripts/daily.mjs 的 cron 从 8 点改到 7 点半，然后手动跑一次确认输出正常。

不用 SSH 进去改 crontab，也不用开远程桌面。

边界：什么不该远程做

• 需要看大量 diff 的重构
• 涉及数据库迁移的操作
• 任何没有测试覆盖的核心逻辑改动

原则：远程适合发起和确认，不适合审阅。

稳定性

实际用下来最常出问题的是网络切换（WiFi ↔ 蜂窝）。建议开启”断点续传”式的任务记录，断连后重连时先让它复述当前进度：

你刚才在做什么，做到哪一步了。

这一句能避免大量重复劳动。