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
Hey PH 👋 Aadil here.
Pushary is the yes button for your AI agents. Their permission prompts and questions land on your phone's lock screen, you tap, the run keeps moving.
The problem
You hand an agent a 40-minute job and walk away. Two minutes in, it stops to ask permission for something trivial, and the whole run freezes until you wander back to the terminal. You can pay double for faster tokens and the run still waits at the same prompt. The slowest step in an agent run is usually you.
What's new in this launch
If you've seen Pushary here before: the first three versions ran on web push. iPhone web push drops just enough notifications that one missed approval kills trust in the whole setup (launch three got four upvotes, you can look it up). This launch is the rebuild on a channel you can trust:
- Native iPhone and Android apps, with approvals as lock screen actions
- Pairing is a QR code you scan from the terminal, no API key to copy around
- One inbox for every agent and machine you run
What's live today
- Enforced gating for Claude Code, Codex, Gemini CLI, Cursor, and Hermes: a risky command blocks until you answer, instead of pinging you after it already ran
- Claude Cowork and claude.ai connect with one pasted link and ask cooperatively
- Per-tool policies auto-approve the safe reads, so your phone only buzzes when it matters
- Every question and answer lands in an exportable audit trail
How it compares
- Happy and Omnara mirror your whole session to your phone, a terminal in your pocket. Pushary sends only the decisions: approvals, questions, task done. Less to look at, nothing to miss.
- Anthropic's Remote Control is free and genuinely good if you're on Claude Max and only run Claude Code. Pushary covers six agents across vendors and machines from one phone.
- DIY push (ntfy and friends) tells you after the fact. Pushary's hook integration blocks the risky command until you answer.
Where it kicks in
🚶 The agent hits a permission wall mid-refactor. You answer from the sidewalk. It never notices you left.
🍕 Three agents on two machines, one inbox, cleared over lunch.
🌙 The overnight run that used to die at 2am on a yes/no question.
Honest bits
$9.99/mo after a 7-day trial, and the trial asks for a card up front.
What I'd love from you
Hand your agent something long and tell me where you were when the first question reached your phone. Couch, train, school pickup. And if your agent still ended up waiting on you, that's exactly the feedback I need.
I'll be here all day <3
@aadilghani the audit trail angle is what gets me most here. everyone's focused on the "don't let the agent freeze" problem but having an exportable record of every approval decision is actually the compliance story nobody's talking about yet. curious whether you've had enterprise teams ask about that specifically, or is it mostly solo devs right now?
@rnagulapalle
this in specific was a team plan request, there were 3 devs working in a team and they wanted a shared export to later pass the approval/deny logic down through a model to learn the positives and negatives of their decision making during their retros.
super smart chaps, you can also use this as a solo dev just to recon on what went right and what went wrong, then feed it to Pushary auto-pilot which further auto approves the obvious commands which makes the agent go faster.
So basically you can manage AI agents from your phone instead of laptop?
@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.
@nivotools
Julian, thanks for the support and appreciation. Looking forward to earning you as our user <3
Can Pushary be used as an external Human-in-the-Loop (HITL) service via API?
I'd like my AI agents (built with LangGraph.js, Mastra, or PydanticAI) to send approval requests to Pushary, wait for a human response, and then continue execution.
Does Pushary provide APIs or webhooks that support this workflow?
@cvreyher
of course we have dedicated HITL API's with our partner plan, more information here https://pushary.com/human-in-the-loop
simple stupid one line integration.
had this happen last week actually, agent just sat there for 20 min waiting on a permission.
This actually looks very useful. I'm gonna try this out. Does it also work with VSCode and Antigravity?
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!
@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.
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.
@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.
@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.
Showing a diff on tap is the right baseline, but I'd push on a different gap. The thing missing at approval time isn't only what's on the screen, it's what's in the approver's head. At the terminal the whole session is scrolled above you. On a lock screen you get one diff and none of the intent you set 40 minutes ago and have half-forgotten. So you end up approving "does this change look ok" when the real question is "does this still match the plan", and a diff alone can't answer that.
Second thing is the medium. A notification trains a reflex, notifications are things you clear. The format that makes tapping yes fast also nudges toward yes, because that's what we do with the other 200 a day.
So my question is less about richer previews and more: does anything reconnect the approval to the original goal, not just the pending step? Something that lets me answer "is the agent still on track" and not only "is this one command safe"?
@jernej_jan_kocica
Jernej, this is the best version of this critique I've seen, so I'll answer both halves straight.
On intent: you're closer to having it than the lock-screen framing suggests. Every approval already carries the intent we pull from the session, the last thing you actually told the agent, sitting next to the pending step. So you're not answering "does this diff look ok" cold, you're answering it with your own ask in view. What we don't do yet is pin the goal you set 40 minutes ago and show drift against it across a long run. The full session is captured server-side, so the material to answer "still on track" exists, it just isn't wired to the approval as a plan-versus-now check. That specific thing, is-it-on-track rather than is-this-step-safe, is what I want to build next.
On the medium: you're right that a notification trains a clear-it reflex, and it's the strongest argument against fast-yes I've heard. What saves it here is fail-closed. Clearing or ignoring a Pushary request never approves, it denies or waits. So the reflex that burns you on the other 200 fails safe on this one. And because policy keeps the safe stuff off your phone, the ones that reach you aren't in that pile. Where you're still right: the highest-stakes calls shouldn't feel like the rest, and making them deliberately higher friction is on me.
If you want to get into how you'd represent "the plan" so drift is checkable, I'd gladly entertain that too :)
@aadilghani The way I'd make drift checkable is to stop treating the plan as prose and turn it into a small frozen contract at run start. Not the goal in a sentence, but the few things that would mean you've gone off it: allowed scope (these paths/modules), off-limits areas (don't touch auth or the payment code), a couple of invariants (public API stays stable, migrations stay reversible), and a short definition of done. The agent can draft that from the goal, you confirm it once, and it freezes.
After that "on track" stops being a judgment and becomes mechanical: does this step touch anything outside the contract or break an invariant. Then the approval can lead with the delta against the plan, not the diff in isolation. "This step edits auth, which you marked off-limits" is a very different prompt than "run this command". You're already capturing the session server-side, so this is a layer on top of what you have, not new plumbing.
The one trap: legitimate scope changes. Halfway through you decide the feature also needs Y. If that isn't its own explicit step ("agent wants to widen scope to include Y, approve?") then every real change reads as drift and you're back to alert fatigue, just a new flavour. So plan edits have to be first-class approvals, separate from step approvals.
Curious where you'd put the contract though: do you see the human writing those constraints, or the agent proposing them and the human just ratifying at run start?
@jernej_jan_kocica
Jernej, this is the right shape, and the contract framing is what unlocks it. On your actual question, I'd land on agent proposes, human ratifies, but with a split that keeps the ratify from dying of friction.
The off-limits areas and invariants are the durable part. Don't touch auth, don't touch payments, migrations stay reversible, public API stays stable, those don't change run to run. So they shouldn't be rewritten every time, they should be standing guardrails per repo that carry across runs. That's close to what the policy layer already does, so "off-limits" becomes a deny on those paths, set once. The per-run contract then shrinks to the part that actually varies: the scope for this task and the definition of done, which the agent drafts from the goal and you ratify against the standing guardrails.
I wouldn't have the human write it cold, because adoption dies, nobody hand-authors a contract before every run, and anything that adds friction at run start won't get used. But ratify can't be a rubber stamp for the reason you already named: wave through a contract the agent scoped too wide and you've just moved the reflexive yes up a layer. So the ratify view has to lead with the consequential bits, what's off-limits and what invariants are claimed, and make widening take a real tap.
The scope-change trap falls out of the same mechanism rather than needing a new one. The delta-check that flags drift is exactly what raises "agent wants to widen scope to include Y, approve?", one signal, two outcomes. And approving it has to amend the frozen contract, so the next ten steps in that area stop re-prompting. That's what keeps it from becoming a new flavour of fatigue.
Where it gets genuinely hard is invariants that aren't path-shaped. "Public API stays stable" is checkable, "migrations stay reversible" much less so without running something. That's the part I don't have a clean answer for yet, and it's where I'd keep pulling on this with you.
@aadilghani Agent-proposes-human-ratifies with the guardrails standing per repo is exactly right, that's the version that actually gets used.
On the non-path invariants, I'd stop trying to check them at approval time and turn each one into a required artifact plus a cheap check that runs in the sandbox. "Migrations stay reversible" isn't provable from the diff, but you can require the step to ship a down-migration and have the sandbox run up, down, up and diff the schema. If it doesn't round-trip, that's your drift signal, and it surfaces to the approval instead of a human eyeballing it. "Public API stays stable" becomes a contract/snapshot test, any change to the public surface is the tripwire.
So maybe two kinds of invariant: path-shaped ones that are a static deny before the step, and check-shaped ones that run as a tripwire and only escalate to you when they fire. The human ratifies the invariant either way, the system just picks how it's enforced.
The honest limit is it only covers invariants you can write a check for. "Migrations reversible", yes. "This stays readable" or "this respects what the user actually meant", no, those stay human and the contract shouldn't pretend otherwise. But the mechanizable ones are most of the dangerous ones, so it's a fair trade.
Hey Aadil! Looks awesome and sounds so promising for every dev. Wish you all the best here!
@german_merlo1
Thanks Germán, really appreciate you stopping by. Means a lot. 🙏
if there are any questions you have after using the product I'm always here or email at aadil@pushary.com