Documentation
An agent reply walkthrough: one task, three original questions
Run a harmless Ntfyx workflow: receive a notification, choose, type a reply and confirm in one Session. Verify the original answer and one-time claim before continuing.
Updated
The task: review a note, then print a local summary
#A script has a synthetic note ready and needs your input. It sends an ordinary notification, asks whether to continue, asks for a short text note, then requests a final Allow or Deny. Only the allowed branch prints a JSON summary in the original terminal and sends a completion notification. The script never deploys, changes a service, invokes an AI model or executes the reply text.
Prerequisites and the exact script
#Use the published Ntfyx CLI 0.4.1, Python 3, and an existing CLI connection approved by your primary phone. Work below is a CLI Topic alias: replace it with an alias shown by ntfyx topics. On the receiving phone, or an optional browser authorized for that Topic, keep the Inbox available. The script requires no Python packages and opens no local listening port.
Read its source before running it.
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 WorkAnswer each original question
#At startup the terminal prints a new Session identifier. The script uses that same identifier and the name A harmless reply walkthrough for every message and question in this run. Open that conversation in the selected Topic. Each answer belongs to the request that asked it; typing a note is not an answer to the final confirmation.
| Step | What to do | What may continue |
|---|---|---|
| Ordinary notification | Read Reply walkthrough: start. | Nothing has been approved or executed. |
| Choice | Select Prepare the demo summary, or Stop this demo. | Only the continue option reaches the text question. |
| Text | Use Reply on that question and enter Review README only. | A verified, claimed text answer supplies data, not a command. |
| Confirmation | Review the final question and choose Allow or Deny. | Only a verified, claimed Allow reaches the local print. |
| Completion | Look for Reply walkthrough: completed in the same conversation. | It reports this script’s local demo result; it is not a deployment receipt. |
Why checking a successful exit is not enough
#Synchronous ntfyx ask verifies the signed answer against the saved original request, checks its request binding and deadline, and acquires a one-time claim. The example additionally checks answered status, the claim flag, the response type and the selected choice. A valid Stop choice is still a successfully answered choice; its meaning must be read.
A read-only ntfyx result can also exit 0 without granting any execution claim. The example returns normally after Stop, but does not print a summary or run another step.
Deliberately try the stopping paths
#Start a fresh run for each deliberate case. First choose Stop this demo: no text or confirmation should follow. On another run, continue and supply the note, then choose Deny: no summary should print. To observe a short unanswered wait, run the command below and leave its choice unanswered. It stops with exit14 and attempts to cancel the pending request; a late answer cannot restart the exited process.
| Outcome | Observed exit | Local summary printed? |
|---|---|---|
| Continue, text and final Allow | 0 | Yes, one local summary. |
| Stop at the choice | 0 | No; the valid choice ended the demo normally. |
| Final Deny | 10 | No. |
| Unanswered one-second wait | 14 | No. |
| Try to claim an already consumed answer again | 15 | No new claim. |
python3 agent-reply-walkthrough.py Work --wait 1s --expires 90sRecorded verification: 24 October 2026
#This exact public example was exercised against the real staging API using the published Linux x64 CLI 0.4.1 release binary. Its SHA-256 was fb28aace205be64f82d440ef3dec5da6d0e7074c8144063e6dbd4ca75698a89a, matched to the publicly served signed release manifest. Continue, Stop, Deny and unanswered timeout all passed.
A locally generated programmatic Phone receiver decrypted the notifications and signed the answers; no physical phone, APNs/FCM alert, browser UI or live Claude/Codex host was used.
| Check | Recorded observation |
|---|---|
| Context | Each fixture kept its ordinary messages and questions in one Topic and Session. |
| Continue | Choice, text and confirmation were verified and claimed; only this case printed the summary and sent completion. |
| Stop and Deny | Neither printed a summary; Stop did not ask the later questions. |
| Timeout | The CLI cancelled the request; the receiver SDK refused to submit a late answer after reading that terminal state. |
| Seven answered requests | Each had a bound signed answer and a server-side claim; repeated CLI claim exited15 and a fresh server claim was refused. |
| Read-only results | They exited0 but did not grant a claim, including for the denied answer. |
| Cleanup | All four synthetic Inboxes were root-deleted and their temporary CLI credentials removed. |
Ordinary questions are separate from native permission hooks
#The same explicit send and ask workflow is supported by the macOS and Linux companion CLI. This recorded run used Linux x64 only. Native host permission hooks are a separate integration with narrower tested versions and modes: the published guides describe Linux x64 checks and Apple silicon Mac validation with Claude Code 2.1.303 and Codex 0.163.0 (CLI 0.1.5+), with Intel Mac terminal fallback.
A local MCP tool, a completion hook and a native PermissionRequest are not interchangeable. Keep the host’s own sandbox, deny rules and trust decisions.