Pushary - Approve AI requests from your lock screen

@liana_preston 

Thanks Liana! Yes, that's the bar, you shouldn't be tapping approve on a mystery.

Every request carries the actual action, the exact command or the file it wants to touch, plus which agent and project it came from. The glance on the lock screen is the headline, and one tap in you get the full context, the command or diff and the intent you set, so you're judging it against what you actually asked for instead of a diff in a vacuum. And approving takes a deliberate unlock, so you can't blind-approve by reflex.

Where I'll be honest: how much data rides along depends on what the step exposes. A file edit or a command is precise. A broad "deploy" shows you the command, not a parsed map of everything it touches. That richer preview is the part I'm still building.

@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.

@dhatri_rai1 

Thanks Dhatri! Approving is gated behind your device unlock, the Approve button carries an auth requirement, so tapping it triggers Face ID or your passcode before anything registers. A stray tap or a phone in your pocket just hits the unlock wall and nothing happens. Deny stays one-tap since denying is always safe. And for the riskiest calls the server drops the one-tap Approve entirely, so you have to open the app and read the full context before you can say yes.

@kelly_king3 

Thanks Kelly! That exact frustration is the whole reason it exists. Appreciate you 🙏

@himani_sah1 

Good thing to press on, and I'll be straight about where the boundary is.

The first wall is that approving requires your device unlock. The Approve action is gated behind Face ID or your passcode, so a locked or lost phone can't approve anything, and denying stays one-tap since denying is always safe. The honest part: if someone can actually unlock your phone, your device auth is the boundary Pushary relies on, same as your banking app. I won't pretend there's a second password sitting on top of your Face ID.

What still limits the damage: only what your policy allows can be approved at all, destructive calls are force-held so they can't be one-tapped and need the app open with full context, and every approval is logged with when and from where. If a phone goes missing you can revoke it and kill any running agent from another device. One straight caveat, on Android the routine approve isn't behind an unlock at the notification layer yet, that's iOS today, and we're closing it with an in-app biometric.

@iamanantgupta 

Good news Anant, on iOS that already ships. Approving is gated behind Face ID or your passcode today, so a tap alone never approves, and high-risk calls go a step further and drop the one-tap approve entirely so you have to open the app and read the full context before you can say yes. The one place it's still on the list is Android, where the notification-level unlock isn't native yet, so we're adding an in-app biometric confirm there. Half your request is live, the other half is the next build. :)

@roopreddy 

Thanks Roop! And you don't have to give up Slack, it's a supported channel too, so approvals can land there, on your lock screen, or both. The difference from raw Slack messages is what happens at the message: it's an actual approve or deny in place, gated by policy so only the real decisions reach you, and every one is logged. A Slack ping tells you something happened, this lets you decide it without leaving where you are. Same idea you were already building, just with the decision built into the surface.

@syed_shayanur_rahman 

Thanks! Not just coding agents. Those are the first-class ones, Claude Code, Codex, Cursor, Gemini, Hermes, where it hooks in deep. Any other agent can plug in two ways: over MCP if it speaks it, or through the SDK and framework adapters like LangGraph, CrewAI, the Vercel AI SDK, and the OpenAI Agents SDK.

So a marketing or ops agent that needs a human to approve something reaches your phone the same way a coding agent does. The one honest difference is depth: coding agents get hard gating at the hook level, everything else asks through Pushary cooperatively. But the human-in-the-loop part works for any agent.

@zerotox 

Good question, two parts to it. The part we control, agent request to push dispatched, is a few hundred milliseconds, the hook posts the request and the server fires the notification right away. The part we don't, push dispatched to your lock screen, rides Apple's and Google's push pipelines, usually a second or two but not something anyone can guarantee to the millisecond.

So end to end it's typically a couple of seconds in normal conditions, and the variable bit is the platform push layer, not us. The setup actually sends a test push and confirms delivery, so you can see your own real number instead of taking mine. And if a push is ever slow, the agent just keeps waiting on its timeout rather than moving on, so latency never turns into a missed decision.