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
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?
Pushary
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.
Pushary
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?
Pushary
@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?
Pushary
The per-tool policy layer is the part I'd want to configure first — the difference between auto-approving all file reads and auto-approving only reads from your project directory is a meaningful trust boundary. Is that granularity available now, or does the policy system work at the tool level only (all of Claude Code's file reads, not individual path patterns)? The audit trail only stays useful if the policy captures intent at the right grain.
Pushary
@hi_i_am_mimo
Valeria, this is exactly the right thing to check, and yes, it's path-level, not tool-level only.
A rule is the tool plus an argument pattern, so Read() auto-approves every read, but Read(src/) auto-approves only reads under your project directory and everything outside it still asks. Matching goes by specificity, a precise path rule beats a broad one, and an explicit rule you wrote always wins over the defaults. So the boundary you described, reads inside the project versus reads anywhere, is a rule you can write now.
And you're right that the audit only holds up if the policy captures the same grain. It does, the record stores the actual target that matched, the specific path, not just "a read happened," so what you see in the trail is at the same resolution as the rule that approved it.
the per-tool auto-approve for safe reads is the part I'd poke at - how do you define "safe" consistently across six agents that each have their own permission model, shared policy schema or configured per agent?
Pushary
@sabber_ahamed
we have both, you can share the same config across agents or per agent defined config if you prefer that, available both on the web dashboard and mobile dashboard. Happy to dive deeper and explain with more details. Looking forward to earning you as a user.
Product Hunt
The annoyance of having to open up an app, then select the chat, then either type or click accept is very real.
Love this! Congrats on the launch y’all :)
Pushary
@gabe
the man himself :)
thanks for the positive words and support <3
Nice framing — the phone approval loop is the part I’d actually use.
One small thing I’d want as a builder: not just Yes/No, but a quick risk label for why the agent is blocked — file write, shell command, dependency install, payment/API action, etc. When I’m away from the terminal, the hard part is knowing whether I’m approving a harmless unblock or changing the risk profile of the run. The audit trail could make that decision reviewable later.
Pushary
I literally was thinking about this. I personally would use this! I need to ask if I am allowed to use this on certain computers. But I really like this. Slightly thinking about how all the major players have this feature but you create a central hub which is very cool.
Pushary
@saderod
feel free to try it out, we offer a 7 day free trial risk free, check it, test it and let us know. Looking forward to earning you as our user <3