使用说明

从手机回复 AI Agent：确认、选择与文字回答

在 iPhone 或 Android 回答 AI Agent 的确认、选项或文字问题。答案绑定原问题，由已配对的电脑验签并单次领取，再按工作流继续。

更新于 2026年10月23日

怎样在手机上回复 AI Agent？

先把 Ntfyx 与运行任务的电脑配对。Agent 或脚本明确发出问题后，在 iPhone 或 Android 打开原问题，确认、选择选项或输入答案。回复留在原问题下；等待中的电脑验签并领取一次，再由工作流判断下一步。电脑和等待进程需要继续运行。

先试通知，再试确认、选项和文字回复

配对后逐条运行命令。示例使用默认已授权 Topic；需要选择其他 Topic 时加上 --topic 和已有别名。每次 ask 分别等待自己的答案。同一个 Topic 中使用相同 session ID，让这四条消息留在一个 Session。示例只输出结果，不执行答案或授权外部操作。

ntfyx send "结果已准备好，请查看" --session-id review-demo --session-name "示例检查"
ntfyx ask "继续这个无害示例吗？" --allow-deny --session-id review-demo --wait 60s --expires 90s --json
ntfyx ask "先检查哪一项？" --choice summary=摘要 --choice logs=日志 --session-id review-demo --wait 60s --expires 90s --json
ntfyx ask "请补充检查备注" --text --session-id review-demo --wait 60s --expires 90s --json

按等待场景或完整案例继续

“等待输入”指南帮助定位正在等人决定的 Agent；完整回复案例展示选项 → 文字 → 确认流程，并附有日期的验证记录。本页说明这些流程共同使用的手机回复与审批规则。

查看并运行独立确认示例

已有的 approval-demo.sh 会等待一次确认，只在 CLI 返回有效 Allow 且领取成功后打印无害的示例文字。先阅读脚本；下方 Work 是已授权的本地 Topic 别名，请替换成 ntfyx topics 列出的实际别名。脚本不部署软件、不付款，也不执行外部业务操作。

curl -fsSLo approval-demo.sh https://ntfyx.me/examples/scripts/approval-demo.sh
cat approval-demo.sh
bash approval-demo.sh Work

阅读 approval-demo.sh

在原问题下回答

在手机打开待回答的问题，核对上下文后选择 Allow 或 Deny。手机为该 Topic 授权的浏览器也可以回答它收到的新问题。接收端为原发送来源签名并加密答案；点开通知或查看详情本身不会批准请求。

Ntfyx Web 收件箱中的示例问题，包含 Allow 与 Deny 按钮。 — 真实本地 Web 测试中的合成问题。浏览器签名答案验证同一问答协议，这张截图不证明实体手机推送送达。

确认结果和退出状态

独立示例默认等待 60 秒，请求 90 秒过期。同步 ask 超时或被中断时默认尝试取消；取消未确认或使用 --keep-pending 时，远端请求可能暂时仍可回答。迟到回复不会重启已经退出的脚本。

结果	CLI 退出码	确认示例继续吗？
已核验 Allow，且单次领取成功	0	继续，只打印示例文字。
Deny	10	不继续。
本地等待超时	14	不继续。
答案已被领取	15	不继续。
传输失败	非零	不继续。

接入真实操作时保留执行边界

同步 CLI 会核对签名、原请求和截止时间，并取得一次性 claim；只有工作流认可的有效答案才能继续。拒绝、取消、过期或验证失败均不授权。外部部署、交易等操作仍需自己的幂等与结果记录：一次 claim 不保证外部副作用恰好执行一次。领取或操作结果未知时先核对原记录，不自动重跑操作或另发审批。

已有示例的验证范围

独立确认示例曾用编译后的 CLI、真实本地加密中继和 Web 收件箱签名回答验证。自动化接收端使用程序化身份，截图中的消息为合成内容；这不是本轮新的实体手机或 APNs/FCM 投递验收。更完整的选项、文字、确认流程保留单独的日期和公开验证摘要。

普通提问与宿主原生权限分别接入

两者都提供本地 MCP 提问工具和手机回复指引；macOS / Linux 提供完成通知 Hook。Claude Code 还可桥接 AskUserQuestion；Codex 原生 request_user_input 不会被拦截。原生执行审批已验证 Linux x64 上的 Claude Code 2.1.283 / 2.1.284 与 Codex 0.158.0，Apple 芯片 Mac 已验证 Claude Code 2.1.303 与 Codex 0.163.0 的原生审批，需 CLI 0.1.5+；Intel Mac 原生审批仍未验证，回到终端处理。Codex 仍需交互 TUI 与 /hooks 信任；codex exec 不触发权限 Hook。Claude setup 原生权限 Hook 需显式 --permissions on。其他 MCP 客户端需按宿主配置接入。这不是托管的 ChatGPT 或 Claude App 目录连接器。 Windows 使用 CLI 的直接 setup 或本地 MCP。Claude Code Hook 需要 2.1.139+；旧版或无法确认版本时只配置 MCP。Codex 在 Windows 提供 MCP 提问，不配置自动 Hook。市场插件的 Hook 使用 POSIX shell，Windows 请使用直接 setup。原生工具权限审批仍按单独的平台与宿主允许范围处理。

哪些内容端到端加密？

普通 CLI 与 Agent 消息的标题、正文、选项和回复在设备上端到端加密。明确的监控 / Webhook 管理固定授权问题及手机签名答案会披露给服务端核验。HTTPS 推送与 Webhook 请求在加密投递前对服务可见；可选供应商验证 secret 由服务加密存储，并在验签时以明文验证原始 body，是托管 secret，并非服务端不可见；My Monitor 会读取监控地址、规则和响应，公开发布者知道自己发送的内容。中继转发密文，仍处理标识符、时间、大小和推送令牌等运行元数据。不要在监控 URL 或请求示例中放密钥。尚未完成独立安全审计。

加密与验证