Pushary - Approve AI requests from your lock screen
by•
One command connects your AI agents to your lock screen. When Claude Code, Codex, Cursor, Gemini CLI, Hermes, or Claude Cowork stops to ask, you tap yes from your phone and the run keeps moving. New in this launch: native iPhone and Android apps. Pairing is a QR code you scan from the terminal, no key to paste. Per-tool policies auto-approve the safe reads. Every decision lands in an audit trail.
Replies
Love this, it's so frustrating when an agent job stalls when I step away. Cool tool!
@kelly_king3
Thanks Kelly! That exact frustration is the whole reason it exists. Appreciate you 🙏
Congrats. My only concern is security. If someone gets access to my phone, what safeguards stop them from approving everything?
@himani_sah1
Good thing to press on, and I'll be straight about where the boundary is.
The first wall is that approving requires your device unlock. The Approve action is gated behind Face ID or your passcode, so a locked or lost phone can't approve anything, and denying stays one-tap since denying is always safe. The honest part: if someone can actually unlock your phone, your device auth is the boundary Pushary relies on, same as your banking app. I won't pretend there's a second password sitting on top of your Face ID.
What still limits the damage: only what your policy allows can be approved at all, destructive calls are force-held so they can't be one-tapped and need the app open with full context, and every approval is logged with when and from where. If a phone goes missing you can revoke it and kill any running agent from another device. One straight caveat, on Android the routine approve isn't behind an unlock at the notification layer yet, that's iOS today, and we're closing it with an in-app biometric.
A feature I would request is approve with Face ID confirmation for high-risk actions. :D
@iamanantgupta
Good news Anant, on iOS that already ships. Approving is gated behind Face ID or your passcode today, so a tap alone never approves, and high-risk calls go a step further and drop the one-tap approve entirely so you have to open the app and read the full context before you can say yes. The one place it's still on the list is Android, where the notification-level unlock isn't native yet, so we're adding an in-app biometric confirm there. Half your request is live, the other half is the next build. :)
Interesting take on the build. I was solving this with Slack messages, but lock screen approvals sound much smoother.
@roopreddy
Thanks Roop! And you don't have to give up Slack, it's a supported channel too, so approvals can land there, on your lock screen, or both. The difference from raw Slack messages is what happens at the message: it's an actual approve or deny in place, gated by policy so only the real decisions reach you, and every one is logged. A Slack ping tells you something happened, this lets you decide it without leaving where you are. Same idea you were already building, just with the decision built into the surface.
Congrats on shipping! Does this work only with coding agents or can I plug in any agents?
@syed_shayanur_rahman
Thanks! Not just coding agents. Those are the first-class ones, Claude Code, Codex, Cursor, Gemini, Hermes, where it hooks in deep. Any other agent can plug in two ways: over MCP if it speaks it, or through the SDK and framework adapters like LangGraph, CrewAI, the Vercel AI SDK, and the OpenAI Agents SDK.
So a marketing or ops agent that needs a human to approve something reaches your phone the same way a coding agent does. The one honest difference is depth: coding agents get hard gating at the hook level, everything else asks through Pushary cooperatively. But the human-in-the-loop part works for any agent.
Novel concept. What's the latency like from agent request to phone notification?
@zerotox
Good question, two parts to it. The part we control, agent request to push dispatched, is a few hundred milliseconds, the hook posts the request and the server fires the notification right away. The part we don't, push dispatched to your lock screen, rides Apple's and Google's push pipelines, usually a second or two but not something anyone can guarantee to the millisecond.
So end to end it's typically a couple of seconds in normal conditions, and the variable bit is the platform push layer, not us. The setup actually sends a test push and confirms delivery, so you can see your own real number instead of taking mine. And if a push is ever slow, the agent just keeps waiting on its timeout rather than moving on, so latency never turns into a missed decision.
congrats on the rebuild. the part that stands out is going all-in on native push after web push let you down on iPhone. genuine question - for the overnight runs, what happens if you don't respond to an approval within a few hours? does the agent just stay blocked indefinitely, or is there some timeout/escalation so a long run doesn't die silently while you're asleep?
The per tool policies plus the audit trail are the part I would build the whole product around. After a week of taps you can look back and see which approvals were rubber stamps every single time, then promote exactly those to auto. That is a much safer route to fewer prompts than guessing the policy up front.
The thing I would watch is what the notification actually shows. A lock screen has room for the command but not for the context, and an approval given without the diff is just a faster way to say yes to the wrong thing. Risk class might also travel further than tool name, since a read is a read whether it came from Codex or Cursor.
Congrats on shipping the native apps, iOS web push was never going to carry this.
the fail-closed design answers the question I would've asked about a missed tap, but what about the phone being straight up unreachable - dead battery, no signal, airplane mode on a flight. for the overnight-run use case you're marketing specifically, does the agent just sit blocked indefinitely until the phone comes back, or is there some kind of escalation/timeout path (email fallback, a second paired device, anything) so a dead phone overnight doesn't turn into a stalled job for hours?
@aadilghani good to know the fallback exists. one more - when the timeout hits and it falls back to the terminal, does the log distinguish that from a normal approval, so when you review a run later you can tell which approvals were an active human decision versus a timeout default kicking in?
Okay this is really amazing. I run multiple things at once some days and the tab switching happens. I am looking forward to trying this. Congratulations on your launch! :) Just wondering if it also works with tools outside of coding like general AI workflows?