Pushary
Control panel for AI agents on your lock screen
682 followers
Control panel for AI agents on your lock screen
682 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
Pushary
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
Pushary
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?
Pushary
@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.
Pushary
@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.
Aadil, the audit trail is what makes this more than a convenience for me. I run HIPAA-compliant AI, and an exportable record of who approved what and when is exactly what a security review asks for.
The lock-screen surface is where I would pull on it though. If the approval preview shows a diff or command context, and an agent is operating over patient data, that snippet can carry PHI, and a lock-screen notification is readable without unlocking the phone. So the same thing that makes the tap fast also puts regulated data on a screen anyone nearby can glance at.
Can I mask the payload in the notification and require an unlock before the context renders, per policy? And does the audit trail freeze what the approver actually saw at decision time, not just the final command? In a regulated shop that gap is the difference between an audit trail and an alibi.
Pushary
@clemente_lopez1
Audit trail: yes, and it's built for exactly your line. The prompt and context you see get frozen to an immutable row the moment the question is raised. Your answer, the surface you approved from, the timestamp, and the latency all bind to that same row. It's what was on your screen when you decided, not a reconstruction from the final command. Secrets scrubbed on the way in, exports clean. That's an audit trail, not an alibi.
Lock screen: you caught a real gap and I won't dress it up. The body can carry context today, and previews render it right there on the lock screen. We strip credentials, but that isn't PHI, and it isn't per-policy yet. Device-level "show previews when unlocked" is the stopgap.
So we'd let you mark a tool as sensitive. Its notification just says "approval needed," and the real context only shows once you open the app and pass Face ID. That fits with the biometric step-up we're already working on. Tell me how you'd define sensitive for PHI, and I'll build to that rather than guess.
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"?
Pushary
@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?
Pushary
@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.
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.
Pushary
@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.
Pushary
@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.