用 Shelly 将安卓手机接入 Codex

让 ChatGPT 操作 Android 手机，作者走的是一条远程终端路线：用 Shelly 把手机接入 ChatGPT 的 Codex 模式，再通过 ClosePaw 操作其他 App。按作者的方案，整套流程在手机上运行，不需要 PC、Termux 或 root，跨 App 操作要由机主在手机上批准。

这套方案值得看的地方，是它把「模型提出操作」和「人批准操作」分开了。不过，作者只在一台 Galaxy Z Fold6 上跑通过完整流程，长任务也存在可靠性问题。它更适合当作一个可复现的实验，而不是已经成熟的手机助手。

手机怎样成为 Codex 的远程机器

准备条件包括一台 arm64 Android 手机、能在 ChatGPT app 中使用 Codex 的账号，以及开源终端 Shelly。Shelly 采用 GPL-3.0 许可，APK 从 GitHub Releases 获取。首次启动需要授予「所有文件访问权限」。

先在 Shelly 终端里启动 Codex，完成账号登录：

codex

注意这一行启动的是 Codex。未登录时，Shelly 会在内置浏览器面板里打开 ChatGPT 的设备码登录流程；按作者描述，使用的是 ChatGPT 订阅，不需要 API key。

接着把手机配对到 ChatGPT：

shelly codex pair

关键是这条配对命令：它在手机上运行官方 codex remote-control，输出配对码。然后在 ChatGPT app 的 Codex 中添加远程机器，输入配对码，手机就会出现在机器列表里。

为应对 App 重启和网络切换，作者建议开启 Settings → Codex Login → Keep ChatGPT connected。

此时已经能执行查询剩余存储空间等终端任务。Shelly 本身打包了 bash、git、Python 3、Node.js、ssh、tmux、vim 和 Codex CLI，因此 APK 较大。原文还提到多面板 AI 聊天、本地 LLM，以及由手机闹钟唤醒、把带来源笔记保存到 Markdown 或 Obsidian 的定时代理，但没有展开验证这些能力。

操作 Spotify，为什么还需要另一道门

终端命令和操作 App 界面是两条路径。要进入 Spotify、Maps 等 App，还需要 ClosePaw Shelly build 和 Shizuku；只跑终端任务不用安装这两项。

作者给出的例子，是让 Spotify 将「Grunge Forever」歌单保存到资料库。请求里要明确说「on this phone」，并指定 shelly closepaw --wait。Codex 随后在手机终端执行 shelly closepaw --wait "<goal>"。

Shelly 会发出通知，机主解锁设备后才能点击批准。ClosePaw 随后在后台虚拟显示屏中操作 Spotify，主屏幕仍可供用户使用，完成结果再回到 ChatGPT。

批准必须发生在模型够不到的位置。

作者担心，模型读到的网页可能夹带额外指令。如果批准权也在模型手里，恶意内容就可能把无关操作塞进任务。

方案允许通过通知按钮，或在 Shelly 自己的聊天中输入 approve <hash> 批准。一次性随机值（nonce）只存在 Shelly 进程内存中，模型在 shell 里写一个「approved」文件无法代替批准。

返回结果还必须来自固定签名的 ClosePaw 构建，并携带当前请求的 nonce；结果作为数据传给 ChatGPT，而非新指令。这里既检查谁批准，也检查结果来自谁、对应哪次请求。

为什么短任务更容易跑通

作者遇到的第一个问题，是等待过程：命令约 10 秒没有输出时，Codex 往往会结束当前轮次。shelly closepaw --wait 会持续输出进度和明确的「keep waiting」，帮助结果在同一轮聊天里返回。

第二个问题是工具选择。不说「on this phone」、不指定工具时，Codex 曾寻找 Spotify plugin，或者尝试 am start；作者设备上的 Samsung Knox 会阻止后者启动 App。若账号平时使用其他语言，作者还建议明确要求英文回复。

第三个问题更难绕开：ClosePaw 依赖读取屏幕完成操作。作者测试中，逐首添加 10 首歌这样的长流程不可靠，短而具体的目标表现更好。

这些是作者的实测观察，但完整验证只有一台设备，样本量为 N=1。原文没有提供任务成功率、耗时分布，也没有验证其他手机。

我的判断

我认同它对批准边界的处理。提示词里的「不要自行批准」无法代替程序权限控制；让模型生成请求，再由独立机制放行，是值得借鉴的设计。

但这里的批准针对一次目标请求，原文没有说明每次点击都会单独确认。它也没有给出完整威胁模型或安全审计，不能仅凭 nonce 和签名校验就认定整条链路安全。

与需要用户持续接管屏幕的操作方式相比，后台虚拟显示屏更方便；与直接调用服务 API 相比，读屏操作又更依赖界面状态。这篇没有给出两者的对照数据，可靠性判断仍属于作者的有限经验。

另外，免 root 不等于无需权限。所有文件访问权限、Shizuku，以及指定构建的安装要求，都需要使用者理解。原文没有说清各组件的完整权限范围。

能拿来做什么

• 想复现时，先完成登录、配对和存储查询，再尝试一次保存歌单这样的短目标，每一步分别确认结果。
• 给手机下任务时，明确设备、目标 App 和 shelly closepaw --wait，减少模型选错工具的机会；长流程拆成可检查的短任务。
• 做日常 AI 编程工具或 Node 命令封装时，可以借鉴独立批准机制：由程序校验授权与请求对应关系，返回内容按数据处理，别把安全边界寄托在提示词上。
• 封装耗时命令时，可以参考持续输出进度的做法，同时实际检查所用代理的等待行为；作者观察到的约 10 秒不能当作所有工具通用的超时规则。