Pushary - Approve AI requests from your lock screen

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

@kristaps_karnitis 

Thanks Kristaps, and you're describing what's already under the hood.

The low-stakes stuff like reads auto-approves, so you never walk back to an agent frozen on something trivial. The risky class is handled differently on purpose: destructive commands get held for a real decision even when a broader rule would have waved them through, so "delete everything" can't slip past on a general allow.

You set the line per tool. Reads auto, edits under src escalate, rm -rf denied, whatever matches how you work. Minor flows through, major waits. Appreciate the upvote.

@cyrus_chan2 

Thanks Cyrus, and agreed, blanket approvals are how people get burned.

Straight answer on per-project: today policies are scoped to the workspace behind your API key and matched on tool plus args, not per repo. So one key across several repos shares one policy set, and two repos with the same path hit the same rule.

Different repos, different risk profiles is exactly the gap, and repo-scoped policies are going up the list, narrow to where a rule was created by default and widened to the whole workspace on purpose. Appreciate you naming it.

@yaroslav_stelmakh 

Yaroslav, good list, and most of it already rides along.

Agent, tool, and repo: yes. Every request carries the agent it came from, the tool and its target (the file for an edit, the command for a shell call), and the project it's running in. Session identity is tracked too, so the app groups requests by agent and run.

What's affected: for an edit or a command you get the exact target. Structured "services" is softer, a deploy shows the command, not a parsed list of what it touches. Real gap, not pretending otherwise.

Reversible: today that comes through a risk classifier that flags destructive calls like rm -rf or a force push, so those are marked and never auto-approve. It's a risk signal, not a hard guarantee, and I'll say that straight.

How much fits: the notification carries the headline, which agent and what it wants. The full command or diff, your intent, and the risk flag live one tap in, so the glance stays scannable and the detail is there when the call is close. The more you cram onto the lock screen, the less gets read, so it's a glance plus a real detail view.

Where I'd want your push: the smallest set that lets you say yes safely without tapping through. That's the line I'm still tuning.

@dhiraj_patel5 

Of course they do, they are account specific, so just ensure you use the same account and you're golden.

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

@mcarmonas 

my guy!! thanks for the shout and the support, much love <3

@krekeltronics 

Thanks Patrick, that's exactly the framing. The agent was never the slow part, the human loop was, and most tools optimize the wrong half.

On the audit piece, agreed it carries as much weight as the tap. Every decision writes to an immutable record: what was asked, what got answered, when, and from which surface, bound to the request so it can't drift after the fact. For a small team that's the difference between "the agent did something" and "here's exactly what was approved while everyone kept moving." It exports too, so it holds up when someone actually asks.

@ankita_singh27 

Fair question. Claude Code's app is genuinely good at what it does, remote-driving a Claude Code session. The difference is the job it's doing.

That app drives one vendor. Pushary sits across Claude Code, Codex, Cursor, Gemini and Hermes, so if you run more than one agent it's one inbox and one policy instead of an app per tool.

It's also a different model. Remote control is pull, you open the app and drive. Pushary is push, the agent keeps running on your machine and only reaches you when it hits something it can't decide alone. You're not watching a session, you're getting tapped for the five seconds that need a human, and the safe stuff auto-approves so it never reaches you. On top of that, per-tool policy decides what even surfaces, and every approval lands in one immutable cross-agent record. That's governance, not just access.

Honest reply dev-to-dev: if Claude Code is your only agent and you just want to drive it from your phone, their app is good and you may not need me. Pushary earns its spot when you're running more than one, want to stop hand-approving the trivial stuff, and need a record of what got approved while you were away.

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