Documentation

Reply to AI agents from your phone: confirmations, choices and text

Answer an AI agent on iPhone or Android. Keep replies attached to the original question; the paired computer verifies and claims the answer before continuing.

Updated

How do I reply to an AI agent from my phone?

#

Pair Ntfyx with the computer running your task. When the agent or script explicitly sends a question, open it on iPhone or Android and confirm, choose an option or type an answer. The reply stays under its original question. The waiting computer verifies the signed answer and claims it once before the workflow decides what to do next.

Keep the computer and waiting process running.

Try a notification, confirmation, choice and text reply

#

Run one command at a time after pairing. These examples use your default authorized Topic; add --topic with an existing alias to select another. Each ask waits for its own answer. All four messages share one Session because they use the same session ID in the same Topic. The examples print results; they do not execute your answer or authorize an external operation.

Terminal
ntfyx send "The result is ready to review" --session-id review-demo --session-name "Demo review"
ntfyx ask "Continue this harmless demo?" --allow-deny --session-id review-demo --wait 60s --expires 90s --json
ntfyx ask "What should I check first?" --choice summary=Summary --choice logs=Logs --session-id review-demo --wait 60s --expires 90s --json
ntfyx ask "Add a review note" --text --session-id review-demo --wait 60s --expires 90s --json

Separate a waiting task from a complete walkthrough

#

The waiting-for-input guide helps diagnose an agent that needs a decision. The reply walkthrough demonstrates a complete choice → text → confirmation flow with a dated verification record. This page explains the shared phone-reply and approval contract.

Before you start

#

For the protected CLI scripts below, install Ntfyx CLI 0.6.0+ on Windows, macOS or Linux and the app on iPhone (iOS 18.4+) or Android (Android 10+). Android background push requires Google Play services. Pair the CLI as the same user who runs the task; installing it alone does not authorize the sender.

Free includes 100 messages per UTC day. Use ntfyx topics to find your local alias and replace Work in the examples. The shell installer below is for macOS/Linux; Windows installation and current phone availability are on the download page.

  1. Run ntfyx connect on the trusted computer and keep the fresh QR private.
  2. Use the phone’s private Topic connection flow to authorize this Source. Update older apps from the store and follow the private scanning entry; current versions are listed in the quickstart.
  3. Confirm one actual phone message before adding the wrapper to your own task.
Terminal
curl -fsSL https://ntfyx.me/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
ntfyx version --json
ntfyx connect
ntfyx topics

Inspect and run the demo

#

This example asks a question, waits synchronously and prints a harmless demo message only when the CLI returns success. It does not deploy software, run a payment or execute an external operation.

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

Answer on your phone

#

Open the request titled Review the demo step. Check the question and choose Allow or Deny. You can also answer a new request in a browser that your phone authorized. The receiver signs and encrypts the answer for the original source.

Ntfyx Web Inbox showing Continue the demo with Allow and Deny actions.
Actual local Web test with a synthetic request. A signed browser answer exercises the same request protocol; this screenshot does not establish phone delivery.

Understand the exit status

#

The script waits up to 60 seconds by default and the request expires after 90 seconds. A pending request can remain answerable after the local wait ends. A late reply never restarts an exited script.

OutcomeCLI exitDemo continues?
Verified Allow and claim acquired0Yes, prints one demo line.
Deny10No.
Local wait timed out14No.
Answer already claimed15No.
Transport failureNonzeroNo.
Terminal
bash approval-demo.sh Work 1s

Connect a real operation carefully

#

The synchronous CLI verifies the reply and acquires its one-time claim before returning success. Only the successful branch may continue. Keep your external operation idempotent and record its outcome separately: a claim cannot make an external deployment or transaction exactly once. If the result of a claim or operation is unknown, investigate instead of automatically rerunning the operation or requesting a fresh approval.

What was verified

#

These scripts were tested with the compiled CLI, a real local encrypted relay and signed replies from the Web Inbox. Phone authorization in that automated test used a programmatic identity. The screenshots show synthetic messages from that local Web test; they are not iPhone or APNs delivery evidence.

When the agent needs your input

#

Completion alerts, tool permission requests and missing information need different integrations. Use the guide below to choose a supported permission hook or explicitly ask for a choice or text reply through the CLI or local MCP. Existing terminal prompts are not automatically forwarded.

Compare ways to use coding agents from your phone

#

Compare full-session access, completion notifications, permission decisions and answers, with official sources, encryption scope, account requirements and starting prices.

Question tools and native permissions have different scopes

#

Both provide local MCP question tools and phone-reply guidance. Completion hooks are available on macOS / Linux. Claude Code also bridges AskUserQuestion; Codex native request_user_input is not intercepted. Native execution approvals have verified Linux x64 support for Claude Code 2.1.283 / 2.1.284 and Codex 0.158.0; Apple silicon Mac native approvals are verified with Claude Code 2.1.303 and Codex 0.163.0 and require CLI 0.1.5+.

Intel Mac native approvals remain unverified and return to the terminal. Codex requires interactive TUI and /hooks trust; codex exec does not trigger permission hooks. Claude setup permission hooks require --permissions on. Other MCP clients require host-specific configuration. This is not a hosted ChatGPT or Claude app-directory connector.

On Windows, use direct CLI setup or local MCP. Claude Code hooks require 2.1.139+; an older or unknown version gets MCP only. Codex on Windows provides MCP questions without automatic hooks. The marketplace plugin uses POSIX shell hooks; use direct setup on Windows. Native tool permission approvals retain their separate platform and host policy.

What is encrypted?

#

Protected Topic CLI and agent message titles, bodies, options and replies are end-to-end encrypted on your devices. Public Topic names and messages are readable by the service and anyone with the Topic ID or link. The explicit fixed monitor-access and webhook-management questions and their signed phone answers are disclosed to the service for verification.

HTTPS push and webhook requests are readable by the service before encrypted delivery. Optional provider verification secrets are encrypted and stored by the service, then used in plaintext to verify the raw webhook body; they are hosted secrets, not hidden from the service. My Monitor reads the monitored address, rule and response; a public publisher knows the content it publishes.

The relay routes ciphertext and processes operational metadata such as identifiers, time, size and push tokens. Do not put secrets in monitored URLs or request examples. Independent security review is not complete.