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
@aadilghani - Looks cool, and very useful for streamlining development workflows. An plans to integrate with @opencode in the future?
@codeandsea
Thanks Brent! Short answer, yes, that's exactly the kind of agent I want to cover.
Today, if OpenCode can load an MCP server (most agents can), you can wire Pushary in right now through the "Other" option in setup and get the notifications and ask-a-human flow. The piece that makes it first-class, approve or deny on its tool calls, needs a pre-tool hook I can wrap, the same way Claude Code and Codex expose theirs. If OpenCode has that surface, a proper adapter is quick and I'd build it.
Point me at its hook or permission API and I'll take a real look.
@aadilghani - Awesome, yes opencode does support MCP integration now.
@codeandsea
Legend! <3
Love the switch to QR pairing! With one unified inbox, how does it handle multiple agents requesting approval at the exact same time?
@aren_barseghyan
Thanks Aren! They don't collide, because nothing is shared between them. Each request is its own item with its own id, tagged with the agent, session, and project it came from, so three agents asking at once show up as three separate cards in the inbox, each labeled so you can tell them apart.
You answer them independently, and answering one resolves only that request. An unanswered one waits or denies on its own timeout without holding up the others, and the finalize step is guarded so a fast double-tap or two devices can't record conflicting answers for the same request. Policies also quietly clear the safe ones, so a burst rarely lands on you all at once.
@aadilghani Since approvals happen right from the lock screen, what stops an accidental tap (say, phone in a pocket) from approving something with real blast radius? Is there a confirmation step or biometric check? or does every lock screen tap get treated the same regardless of what it's approving?
@clement_avq
Clement, good thing to poke at, and no, every tap is not treated the same.
Deny is the only true one-tap, because denying is always safe. Approve is gated: the Approve action requires device authentication, so tapping it wakes Face ID or your passcode before anything registers. A phone in your pocket can't approve, the tap just hits the unlock wall and nothing happens.
There's a second layer too. When the server flags a decision as off or high-risk, it drops the one-tap Approve button from the lock screen entirely, so for those you can't approve from the notification at all, you open the app and go through the full context first.
So the accidental yes you're describing is exactly what the auth gate on approve is there for. Denying stays instant since it's always safe, and approving never happens without a deliberate unlock.
@aadilghani That's a solid answer, the unlock wall makes sense! Curious if the high-risk threshold is user-configurable, or fixed by your classifier. And does Android get the same two-layer treatment as iOS?
@clement_avq
Two good ones, and the honest answers differ by question.
On the threshold: it's currently computed, not a dial you set. The gate that drops one-tap approve fires when the action is classified destructive, or when it doesn't match the intent you gave the agent, so a high-consequence call that also looks off-plan loses the shortcut. What you do configure is the policy on top, you can force any tool to always ask or to deny outright, and an explicit rule you write wins over the classifier. So it's a fixed safety floor with your policy layered above it. A user-tunable risk slider isn't there yet, and if that's what you're after I'd rather say so than pretend the dial exists.
On Android: partly, and I won't claim full parity. The gating layer, dropping one-tap approve for the risky or off-plan calls, works on both, it's server-driven and the Android background handler enforces it too. The device-unlock wall on the everyday approve button is the iOS-specific piece, because that authentication flag is an iOS notification capability Android doesn't expose the same way. So on Android a routine approve isn't held behind Face ID at the notification layer yet. Closing that with an in-app biometric confirm on Android is on the list, and it's a fair gap to call out.
@aadilghani Appreciate the straight answer, especially not pretending the risk dial exists. One practical follow-up: until the in-app biometric confirm ships on Android, would you recommend forcing "always ask" on high-consequence tool categories there to make up for the missing unlock wall?
Congrats on the launch man, almost overtook us too aha)
Is this essentially an app on mac and on iphone?
@evgeny_timofeev
Haha appreciate it man, good luck with yours too )
Not quite an app on both ends. On the Mac side there's no desktop app, it's a one-command CLI that hooks into the agent you already run, Claude Code, Codex, whatever. On the phone side yes, it's a real native app, iPhone and Android, and there's a web version too if you'd rather not install anything. The agent keeps running on your machine, the phone is just where the decisions reach you.
Anyone running Claude Code or Cursor heavily knows the pain of an agent stuck waiting on a yes while you are away from the keyboard. Pushary going after that with lock-screen approvals is well targeted. The thing that would keep me using it is trust, showing enough of what the agent wants to do that I can approve safely from my phone. Get that right and this fits into a lot of workflows.
@roguetink
That's exactly the bar. A yes/no with no context is just a slower terminal. So the approval shows the real call, the exact command or file, the agent, and the project, and policies mean only the risky stuff reaches you in the first place. Richer previews like an inline diff before you approve are where we're headed next. If you run agents heavy, I'd want your read on where the context isn't enough yet.
'the slowest step in a run is usually you' is the honest line. do the auto-approve policies stay fixed per tool, or learn which yes/no i keep repeating?
@andrewzakonov
thanks mate, killer question, we call it the autopilot, every week it learns from your approval behaviour and suggests edits to your policies, you can approve them with a tap too.
much love <3
Using the lock screen as the place where an agent reaches the human is a very natural and also great idea. Can teams require Face ID or another authentication step for especially sensitive approvals?
@nico_mandera
Right instinct, and it's exactly where this goes.
Today there's already a quiet baseline. The request lands on a device that's yours and already unlocked, and sensitive tools never auto-approve. You tag them, they wait for a real human or escalate, and nothing slips through if you drop off signal.
The Face ID layer you're describing is the next one. Both platforms hand us local biometric auth, and since policy is already per-tool, it drops in as a flag: require a biometric confirm on Approve for anything you mark sensitive. Tap Approve, Face ID re-checks, then it counts. That's on the build list.
If your team can tell me where you'd draw the "especially sensitive" line, I'll build it with you. That's the input that makes it sharp.
shoot me an email at aadil@pushary.com and we can make it real from there <3
Aadil, the audit trail is what makes this more than a convenience for me. I run HIPAA-compliant AI, and an exportable record of who approved what and when is exactly what a security review asks for.
The lock-screen surface is where I would pull on it though. If the approval preview shows a diff or command context, and an agent is operating over patient data, that snippet can carry PHI, and a lock-screen notification is readable without unlocking the phone. So the same thing that makes the tap fast also puts regulated data on a screen anyone nearby can glance at.
Can I mask the payload in the notification and require an unlock before the context renders, per policy? And does the audit trail freeze what the approver actually saw at decision time, not just the final command? In a regulated shop that gap is the difference between an audit trail and an alibi.
@clemente_lopez1
Audit trail: yes, and it's built for exactly your line. The prompt and context you see get frozen to an immutable row the moment the question is raised. Your answer, the surface you approved from, the timestamp, and the latency all bind to that same row. It's what was on your screen when you decided, not a reconstruction from the final command. Secrets scrubbed on the way in, exports clean. That's an audit trail, not an alibi.
Lock screen: you caught a real gap and I won't dress it up. The body can carry context today, and previews render it right there on the lock screen. We strip credentials, but that isn't PHI, and it isn't per-policy yet. Device-level "show previews when unlocked" is the stopgap.
So we'd let you mark a tool as sensitive. Its notification just says "approval needed," and the real context only shows once you open the app and pass Face ID. That fits with the biometric step-up we're already working on. Tell me how you'd define sensitive for PHI, and I'll build to that rather than guess.
Very nice idea! Nothing more annoyting than coming back to an agent thats been idle due to a small permission request. There should be categories in terms of minor or major permission/change requests - some requests really do require proper review before approving.
Upvoted!
@kristaps_karnitis
Thanks Kristaps, and you're describing what's already under the hood.
The low-stakes stuff like reads auto-approves, so you never walk back to an agent frozen on something trivial. The risky class is handled differently on purpose: destructive commands get held for a real decision even when a broader rule would have waved them through, so "delete everything" can't slip past on a general allow.
You set the line per tool. Reads auto, edits under src escalate, rm -rf denied, whatever matches how you work. Minor flows through, major waits. Appreciate the upvote.
This solves a real annoyance — I lose so much time because an agent stops mid-run waiting for a yes/no while I'm away from the desk. The per-tool auto-approve policies are the killer feature; blanket approvals are how people get burned. Can policies be scoped per-project, not just per-tool? Different repos have very different risk profiles.
@cyrus_chan2
Thanks Cyrus, and agreed, blanket approvals are how people get burned.
Straight answer on per-project: today policies are scoped to the workspace behind your API key and matched on tool plus args, not per repo. So one key across several repos shares one policy set, and two repos with the same path hit the same rule.
Different repos, different risk profiles is exactly the gap, and repo-scoped policies are going up the list, narrow to where a rule was created by default and widened to the whole workspace on purpose. Appreciate you naming it.