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
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?
@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.
This is neat. Do policies carry over if you reinstall the app or switch to a new phone?
@dhiraj_patel5
Of course they do, they are account specific, so just ensure you use the same account and you're golden.
the lock screen is the right place for this. agent permission prompts are the exact kind of thing that should interrupt you for 5 seconds, not require you to open a laptop and find the right terminal window. the "work keeps moving while you're away" framing is good because that's the actual cost of blocked agents, it's not just inconvenience, it's idle compute and missed time windows. curious whether you can set different approval thresholds per agent or per action type, or is it a single yes/no for everything?
@shubham4real
Thanks Shubham, and you nailed the real cost, idle compute and missed windows, not just annoyance.
On your question: both, and it's more granular than a single yes/no. Every tool gets its own rule, so a read auto-approves, an edit under src waits for you, a force push or rm -rf is denied outright, each with its own timeout. It's per agent too. Claude Code and Codex can run under different profiles with a shared default underneath, so you can be loose with one and strict with another. You can also flip a whole agent's mode on the fly: push me everything, notify only, or keep it at the terminal.
So the yes/no is really the last mile. Most of the decision is the policy you set before anything reaches your phone.
lfg!! congrats on the launch. cracked founder
@mcarmonas
my guy!! thanks for the shout and the support, much love <3
@ankita_singh27
Fair question. Claude Code's app is genuinely good at what it does, remote-driving a Claude Code session. The difference is the job it's doing.
That app drives one vendor. Pushary sits across Claude Code, Codex, Cursor, Gemini and Hermes, so if you run more than one agent it's one inbox and one policy instead of an app per tool.
It's also a different model. Remote control is pull, you open the app and drive. Pushary is push, the agent keeps running on your machine and only reaches you when it hits something it can't decide alone. You're not watching a session, you're getting tapped for the five seconds that need a human, and the safe stuff auto-approves so it never reaches you. On top of that, per-tool policy decides what even surfaces, and every approval lands in one immutable cross-agent record. That's governance, not just access.
Honest reply dev-to-dev: if Claude Code is your only agent and you just want to drive it from your phone, their app is good and you may not need me. Pushary earns its spot when you're running more than one, want to stop hand-approving the trivial stuff, and need a record of what got approved while you were away.
I spend most of my day reviewing diffs an agent wrote, and the failure mode nobody warns you about is approval fatigue. When 95 percent of the prompts are a trivial yes you start tapping through on reflex and stop actually reading, which is the exact moment the one destructive action sails through.
So the hard part of a tool like this is not the lock screen, it is the policy layer deciding what is even worth interrupting me for. Saw you mention auto approve policies, that is the piece I would treat as the whole product. Get the selection right and every prompt that survives it gets read properly. Get it wrong and you have just moved the rubber stamping onto a smaller screen.
@leomiller_dev
Leo, you're right, and it's the thing I'd defend hardest. The lock screen is the easy 10 percent. The selection layer is the product, and if it's wrong you've just handed people a smaller surface to rubber-stamp on. No argument.
So here's the part built for exactly your failure mode. It isn't only "user writes allow rules," there's a floor and a ceiling. Safe read-only stuff auto-approves so the 95 percent never reaches you. And a call the risk classifier flags destructive, rm -rf, force push, drop table, is force-held even when a broad rule would have waved it through. So the reflex tap can't sail a destructive action past, because the dangerous class doesn't ride on a general allow in the first place. An explicit rule you wrote still wins, so it doesn't turn into a nanny.
Where you're still right and I won't pretend otherwise: selection is only as good as the classifier and the rules behind it, and that's never finished. The next piece is risk that accumulates across a run, so the tenth borderline call in a session isn't treated like the first. That's the direction, and getting it right is the actual work. You've named the whole game.
@aadilghani The force hold on the destructive class regardless of a broad allow is the part that sold me. That's the exact thing a pure user-defined rule set always misses, because nobody writes the rule for the action they didn't see coming. Accumulating risk across a run is the right next target too. Good luck with the rest of the day.
@leomiller_dev
"Nobody writes the rule for the action they didn't see coming" nails exactly why the ceiling has to be a default. You can't allowlist your way out of the thing you didn't predict. Thanks Leo, genuinely glad it landed. Onward.
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.
@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.
Really smart solution to a common problem with AI agents. Aadil, approving important requests from your phone while keeping risky actions controlled can save a lot of time.
Congrats on the launch 👍
@ridhwikvinod
Thanks Ridhwik, and this is a great non-dev framing. Most of the value is the same whether the risky action is rm -rf or "email this client."
First question: yes, policies work the same way. They match on the tool and its arguments, so a send-email or update-CRM action is governed exactly like a shell command, you set a rule that says that tool asks first. Two honest caveats. The automatic "this looks dangerous" detection is tuned for code today, so for outbound email or CRM writes you'd set the rule explicitly rather than lean on it guessing. And enforcement depends on the surface: Claude Code and Codex are hard-gated at the hook level, while Cowork and claude.ai go through the connector, where the agent asks through Pushary cooperatively. So it works for your setup, it's just a slightly different guarantee than the hook path.
Second question: honestly, not yet, and you've put your finger on the exact thing that turns this from a solo tool into a company one. Today an approval goes to the devices paired on the account, and escalate just means it comes back to you after a timeout, not to someone else. Routing an outbound email to your marketing director, plus a shared team inbox, is the build I most want to get right, for exactly the reason you gave: the real approver often isn't whoever holds the phone. If you want to help shape what that should look like, I'd genuinely take the input.
Really cool concept! How do you prevent accidental approvals from the lock screen?
@dhatri_rai1
Thanks Dhatri! Approving is gated behind your device unlock, the Approve button carries an auth requirement, so tapping it triggers Face ID or your passcode before anything registers. A stray tap or a phone in your pocket just hits the unlock wall and nothing happens. Deny stays one-tap since denying is always safe. And for the riskiest calls the server drops the one-tap Approve entirely, so you have to open the app and read the full context before you can say yes.