Pushary
Control panel for AI agents on your lock screen
901 followers
Control panel for AI agents on your lock screen
901 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
Launched this week
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
@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.
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
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 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.
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.
This actually looks very useful. I'm gonna try this out. Does it also work with VSCode and Antigravity?
Pushary