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
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.
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.
The per tool policies plus the audit trail are the part I would build the whole product around. After a week of taps you can look back and see which approvals were rubber stamps every single time, then promote exactly those to auto. That is a much safer route to fewer prompts than guessing the policy up front.
The thing I would watch is what the notification actually shows. A lock screen has room for the command but not for the context, and an approval given without the diff is just a faster way to say yes to the wrong thing. Risk class might also travel further than tool name, since a read is a read whether it came from Codex or Cursor.
Congrats on shipping the native apps, iOS web push was never going to carry this.
Pushary
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?
Pushary
@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.
minimalist phone: reduce your screentime
So basically you can manage AI agents from your phone instead of laptop?
Pushary
@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.
Pushary
@nivotools
Julian, thanks for the support and appreciation. Looking forward to earning you as our user <3
ok but is it really worth 10 bucks a month just for tapping yes/no on my phone.
Pushary
@ayazakram
Fair pushback. The tap is the cheap part.
What you're actually paying for is the agent not sitting dead for an hour while you're away from the keyboard. It hits a risky command mid-run, and instead of blocking until you wander back, it reaches your phone and keeps going the second you answer.
It's also one policy across Claude Code, Codex, Cursor and Gemini, so the safe stuff auto-approves and only the calls that genuinely need a human ever buzz you. And every decision lands in an audit trail, which starts mattering the moment more than one person is running agents.
If you're running a single agent and happy watching the terminal yourself, honestly it might not be worth it yet. It earns the $10 the day you stop watching.
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!
Pushary
@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.