Pushary
Control panel for AI agents on your lock screen
708 followers
Control panel for AI agents on your lock screen
708 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
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.
if pushary's backend has an outage while something's blocked waiting on you, does the agent hang forever or is there a timeout?
Pushary
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.
Pushary
@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.
Pushary
@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.
'the slowest step in a run is usually you' is the honest line. do the auto-approve policies stay fixed per tool, or learn which yes/no i keep repeating?
Pushary
@andrewzakonov
thanks mate, killer question, we call it the autopilot, every week it learns from your approval behaviour and suggests edits to your policies, you can approve them with a tap too.
much love <3