使用说明
Agent 原问题回复实录：一件事，三个明确问题
运行一个无害的 Ntfyx 案例：收到通知、选择、填写备注并在同一 Session 确认。核对原问题签名回答与一次性 claim 后，脚本才继续。
更新于
这件事：核对一条示例备注，再打印本地摘要
#脚本准备好一条合成备注，需要你补充信息。它先发普通通知，再问是否继续、需要什么文字备注，最后要求明确允许或拒绝。只有允许分支才在原终端打印一份 JSON 摘要，并发送完成通知。脚本不会部署、修改服务、调用 AI 模型，也不会把回复文字当作命令执行。
准备条件与完整脚本
#使用已公开的 Ntfyx CLI 0.4.1、Python 3，以及由主手机批准的现有 CLI 连接。下方 Work 是 CLI Topic 别名，请替换为 ntfyx topics 实际列出的别名。在接收手机或已为该 Topic 授权的浏览器中打开收件箱。脚本不需要额外 Python 包，也不会开启本地监听端口；先读源码再运行。
ntfyx version --json
ntfyx topics
curl -fsSLo agent-reply-walkthrough.py https://ntfyx.me/examples/scripts/agent-reply-walkthrough.py
cat agent-reply-walkthrough.py
python3 agent-reply-walkthrough.py Work在提出问题的那条消息上回答
#启动时，终端会打印本轮新生成的 Session 标识。脚本为本轮所有消息和问题复用该标识，会话名称为 A harmless reply walkthrough。进入所选 Topic 下的这条会话。每次回答都对应提出它的原请求；填写备注不等于回答最后一道确认题。
| 步骤 | 你要做什么 | 什么可以继续 |
|---|---|---|
| 普通通知 | 阅读 Reply walkthrough: start。 | 尚未批准或执行任何步骤。 |
| 选择题 | 选择 Prepare the demo summary 或 Stop this demo。 | 只有继续选项才会进入文字题。 |
| 文字题 | 点击该问题的“回复”，填写 Review README only. | 验签并领取后的文字只是数据，不是命令。 |
| 确认题 | 核对最后一个问题，选择 Allow 或 Deny。 | 只有验签并领取的 Allow 才进入本地打印。 |
| 完成消息 | 在同一会话查看 Reply walkthrough: completed。 | 它报告脚本的本地示例结果，不是部署回执。 |
为什么不能只检查退出码成功
#同步 ntfyx ask 会把签名回答与本地保存的原请求核对，检查请求绑定与截止时间，再领取一次性 claim。本例继续核对 answered 状态、已领取标志、回复类型和具体选项。有效的 Stop 也是成功回答的选择题，必须读取其含义；只读 ntfyx result 也能退出0，却不授予执行领取。本例选择 Stop 后正常结束，但不会打印摘要或执行下一步。
主动试一次停止分支
#每个分支都从新一轮示例开始。先选择 Stop this demo，后续文字题和确认题不应出现。另一轮中选择继续并填写备注，再选择 Deny，不应打印摘要。要观察短等待超时，可运行下方命令，先不回答其选择题：脚本退出14，并尝试取消待处理请求；迟到回答不会重启已经退出的进程。
| 结果 | 观察到的退出码 | 打印本地摘要？ |
|---|---|---|
| 继续、填写备注、最后 Allow | 0 | 是，一份本地摘要。 |
| 选择题直接 Stop | 0 | 否，有效选项让示例正常结束。 |
| 最后 Deny | 10 | 否。 |
| 一秒内无人回答 | 14 | 否。 |
| 再次领取已消费的回答 | 15 | 不会取得新 claim。 |
python3 agent-reply-walkthrough.py Work --wait 1s --expires 90s2026 年 10 月 24 日的实际验证
#本例脚本使用已公开的 Linux x64 CLI 0.4.1 release 二进制，在真实 staging API 完成验证。二进制 SHA-256 为 fb28aace205be64f82d440ef3dec5da6d0e7074c8144063e6dbd4ca75698a89a，与公开服务的签名发行清单一致。继续、Stop、Deny、无人回答超时四种情况均通过。接收端是本地新生成、自动解密与签名回答的程序化 Phone 角色；没有使用实体手机、APNs/FCM 横幅、浏览器 UI，也没有运行真实 Claude/Codex 宿主。
| 检查 | 实际观察 |
|---|---|
| 上下文 | 每个隔离样本的普通消息与问题均在同一 Topic、同一 Session。 |
| 继续 | 选择、文字、确认均验签并领取；只有本分支打印摘要并发送完成。 |
| Stop 与 Deny | 均未打印摘要；Stop 后也没有继续提问。 |
| 超时 | CLI 已取消请求；接收端 SDK 读取终态后拒绝再提交迟到回答。 |
| 七个已回答请求 | 逐个核对原请求签名绑定及服务端 claim；重复 CLI 领取退出15，全新服务端 claim 同样被拒绝。 |
| 只读结果 | 均可退出0，但不授予 claim，包括被拒绝的回答。 |
| 清理 | 四个合成收件箱均由各自 root 删除，临时 CLI 凭据目录已清除。 |
普通问答与原生权限 Hook 分开看
#macOS 与 Linux 配套 CLI 均支持这类显式 send、ask 流程，本轮实际运行只使用 Linux x64。宿主原生权限 Hook 是另一条适配链，已测版本和模式更窄；指南分别列出 Linux x64 与 Apple 芯片 Mac（Claude Code 2.1.303、Codex 0.163.0，需 CLI 0.1.5+）的验证范围；Intel Mac 原生审批仍回到终端。本地 MCP 工具、完成 Hook 和原生 PermissionRequest 不能相互替代，宿主沙盒、拒绝规则与本人信任选择继续有效。