Pushary
Control panel for AI agents on your lock screen
883 followers
Control panel for AI agents on your lock screen
883 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
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
FetchSandbox
@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?
Pushary
@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.
Pushary
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.
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.
the fail-closed design answers the question I would've asked about a missed tap, but what about the phone being straight up unreachable - dead battery, no signal, airplane mode on a flight. for the overnight-run use case you're marketing specifically, does the agent just sit blocked indefinitely until the phone comes back, or is there some kind of escalation/timeout path (email fallback, a second paired device, anything) so a dead phone overnight doesn't turn into a stalled job for hours?
Pushary
@aadilghani good to know the fallback exists. one more - when the timeout hits and it falls back to the terminal, does the log distinguish that from a normal approval, so when you review a run later you can tell which approvals were an active human decision versus a timeout default kicking in?
The per-tool policy layer is the part I'd want to configure first — the difference between auto-approving all file reads and auto-approving only reads from your project directory is a meaningful trust boundary. Is that granularity available now, or does the policy system work at the tool level only (all of Claude Code's file reads, not individual path patterns)? The audit trail only stays useful if the policy captures intent at the right grain.
Pushary
@hi_i_am_mimo
Valeria, this is exactly the right thing to check, and yes, it's path-level, not tool-level only.
A rule is the tool plus an argument pattern, so Read() auto-approves every read, but Read(src/) auto-approves only reads under your project directory and everything outside it still asks. Matching goes by specificity, a precise path rule beats a broad one, and an explicit rule you wrote always wins over the defaults. So the boundary you described, reads inside the project versus reads anywhere, is a rule you can write now.
And you're right that the audit only holds up if the policy captures the same grain. It does, the record stores the actual target that matched, the specific path, not just "a read happened," so what you see in the trail is at the same resolution as the rule that approved it.