Pushary
Control panel for AI agents on your lock screen
521 followers
Control panel for AI agents on your lock screen
521 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
Many other agent-approval tools I tried miss is that risk accumulates across a run rather than sitting in any one command, and I think you guys are on the way to catch that! Also fail-closed gating on the risky call is the genuinely useful bit here. Though does a session carry any notion of its own accumulating blast radius? Congrats on the launch!
Pushary
@artstavenka1
Thanks Art. Today we score risk per command, not per run. The classifier flags the dangerous calls and those always get held for you, on top of the per-tool policies you set.
A session that carries its own accumulating blast radius though, we're not there yet. That's the build, and you've framed it better than I usually do. Would love to compare notes.
minimalist phone: reduce your screentime
So basically you can manage AI agents from your phone instead of laptop?
Pushary
@busmark_w_nika
Almost. The agent still runs on your laptop or server, you're not coding on your phone. Pushary just reaches you the moment it needs a human, so you can approve, deny, or answer from anywhere and it keeps moving. The phone is where the agent finds you when you've left the desk, not where you do the work.
the bottleneck was never the model, it was the human delaying the nudge, bringing this to the closest interface belonging to a human is the key.
if pushary's backend has an outage while something's blocked waiting on you, does the agent hang forever or is there a timeout?
Pushary
Congrats on the launch, the fail-closed default for lost connectivity stood out, most agent tools just retry and hope. Curious how the auto-approve policies scope in practice: per project or repo, or one policy that applies account-wide, so a different agent session under the same account could end up inheriting an approval meant for a different job entirely.
Pushary
@vollos
Good instinct, that's the exact failure mode worth worrying about. Two different mechanisms here, and they behave differently.
A one-off approval, where you tap yes on a specific blocking call, is bound to that single request. It resolves that one call and nothing else. A different session asking for its own git push raises its own request with its own id, so an approval never carries from one job to another. The scenario you're describing doesn't happen.
The standing auto-approve rules are the separate thing. They live at the workspace level and match on the tool plus its arguments, so you scope them by pattern, not by session. Read() approving everywhere is deliberate, since reads are safe. Anything with real blast radius you'd pin down, like Edit(src/) or a specific command, so it can't quietly cover work it was never meant to. Finer per-repo scoping on those standing rules is where I'd most want your input, because teams running very different projects under one account is exactly who this has to fit.
@aadilghani That distinction answers the worry cleanly, request-scoped one-offs can't leak between sessions. The standing rules are where I'd poke at the same edge you flagged: if two different repos under one account both have a path that matches the same pattern, say Edit(src/), does the match key include which repo or workspace raised the request, or is it purely tool plus args regardless of which project it came from? That's the exact case a multi-client setup would hit first.
Pushary
@vollos
today the match key is tool plus args, not repo-aware. Two repos with the same src/ path both match a single Edit(src/**) rule, because the match never looks at which repo the call came from. Policies are scoped to the workspace behind your API key, so the blind spot is one key running across several repos, which multi-client setups hit first.
The fix is to fold the repo identity into the match key, so a standing rule is scoped to where it was created and you broaden it to the whole workspace deliberately, not by default. Narrow first, widened on purpose.
That's going up the list. "Same path name, different repo" is a case that looks fine right up until an approval quietly covers the wrong one, and it's much cheaper to fix now than after. Appreciate you pushing on it.
@aadilghani Narrow-first, widened on purpose is exactly the right default for something with this much reach per key. Good on you for tracing it down to the match logic instead of just patching the symptom.
'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?
Pushary
@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?
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.