Pushary
Control panel for AI agents on your lock screen
708 followers
Control panel for AI agents on your lock screen
708 followers
Your AI agents stop when they need a permission or an answer. Pushary puts that yes or no on your lock screen, so the work keeps moving while you are away. New in this launch: native iPhone and Android apps. Pair with your terminal by scanning a QR code, no key to paste. Approvals, questions, and task-done alerts from Claude Code, Codex, Cursor, Gemini CLI, Hermes, and Claude Cowork land in one inbox, with per-tool policies that auto-approve the safe stuff and an audit trail of every decision.
This is the 4th launch from Pushary. View more
Pushary
Launching today
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.
Free Options
Launch Team / Built With
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?
Pushary
@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
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.
Pushary
@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.
Lock-screen approvals solve a real gap for long-running coding agents, but that tiny approval moment has to carry a lot of meaning. I would want to see which repo/session/tool is asking, what files or services are affected, and whether the action is reversible. How much of that fits into the mobile prompt?
Pushary
@yaroslav_stelmakh
Yaroslav, good list, and most of it already rides along.
Agent, tool, and repo: yes. Every request carries the agent it came from, the tool and its target (the file for an edit, the command for a shell call), and the project it's running in. Session identity is tracked too, so the app groups requests by agent and run.
What's affected: for an edit or a command you get the exact target. Structured "services" is softer, a deploy shows the command, not a parsed list of what it touches. Real gap, not pretending otherwise.
Reversible: today that comes through a risk classifier that flags destructive calls like rm -rf or a force push, so those are marked and never auto-approve. It's a risk signal, not a hard guarantee, and I'll say that straight.
How much fits: the notification carries the headline, which agent and what it wants. The full command or diff, your intent, and the risk flag live one tap in, so the glance stays scannable and the detail is there when the call is close. The more you cram onto the lock screen, the less gets read, so it's a glance plus a real detail view.
Where I'd want your push: the smallest set that lets you say yes safely without tapping through. That's the line I'm still tuning.
Love the switch to QR pairing! With one unified inbox, how does it handle multiple agents requesting approval at the exact same time?
Pushary
@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?
Pushary
@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?
Pushary
@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.
Love the idea. When the approval request shows up, does it include enough detail to understand what the agent is about to do? I’d want to see the action and the data involved before tapping approve.
Pushary
@liana_preston
Thanks Liana! Yes, that's the bar, you shouldn't be tapping approve on a mystery.
Every request carries the actual action, the exact command or the file it wants to touch, plus which agent and project it came from. The glance on the lock screen is the headline, and one tap in you get the full context, the command or diff and the intent you set, so you're judging it against what you actually asked for instead of a diff in a vacuum. And approving takes a deliberate unlock, so you can't blind-approve by reflex.
Where I'll be honest: how much data rides along depends on what the step exposes. A file edit or a command is precise. A broad "deploy" shows you the command, not a parsed map of everything it touches. That richer preview is the part I'm still building.
what happens if you're on a plane or somewhere dead zone and something's blocking on you.
Pushary
@sadie_charlotte
Good question, and honestly it's the whole point. Nothing risky runs while you're dark. Pushary is fail-closed: no answer defaults to no, so a blocked call never gets auto-approved on your behalf just because you dropped off signal. The worst case is that one step waits or gets denied per the policy you set, while everything safe keeps moving.
And you set that behavior per tool. A risky command can hold for a decision, fall back to deny after a timeout you choose, or route to a teammate if you're out of reach. Meanwhile reads, greps, anything you've allowlisted auto-approve, so most of a run never needs you at all.
When you land, the questions that were waiting are sitting in your inbox. You answer, the agent picks back up.