Pushary
Control panel for AI agents on your lock screen
Start new thread

How do you stay aware of what your AI coding agents are doing?

by
•

I've been running Claude Code, Cursor, and Codex pretty heavily for the last few months and I keep hitting the same loop:

1. Start a task in one agent

2. Switch to something else (Slack, Twitter, another terminal)

3. Come back 30-40 minutes later

4. Agent finished 35 minutes ago. Or worse, it's been waiting for my approval the entire time.

The more agents I run, the worse it gets. There's no unified way to know what's happening across them.

Curious what other people's setups look like:

- Do you just keep terminals visible and check manually?

- Built any custom notification scripts?

- Use something like ntfy or Pushover?

- Just... accept the wasted time?

I've been building something in this space (push notifications + approval flows for AI agents) and I'm trying to understand if everyone's workflow is as janky as mine, or if some of you have figured out something clever.

Would love to hear what's working and what's not.

5.1K views

Add a comment

Replies

Best

I am not sure if that could help but I have had the same issue and I am not super happy with tools like Conductor. So I am building this CLI that let's you add a bunch of repo from Github (or Linear) and it monitors your issues and PR.

When I get a new Issue, I just press "w" on the side panel and it starts Claude Code (or Codex) and it injects automatically all the context to start working and start working. Also it detects when the agents needs my input and notify me.


There are many other cool things (what I love is that I keep track on top of the agent of the last command I ran because when you jump from agent to agent, I tend to forget what I even asked!!).


I am using this tool daily for all my agents, makes me so much more productive. I never create a git worktree. I rarely go in Github as I can do everything from the tool.


It's not perfect yet but definitely usable if you want to take a look.


 

This is cool. Sounds like you're solving the orchestration side, starting agents, routing context, tracking what you asked each one. Pushary comes at it from the other end: once the agent is running, making sure you know when it finishes or needs a decision without watching the terminal.

Probably complementary honestly. Your tool starts and tracks agents, Pushary handles the push notifications and permission approvals while they run. Would be interesting to plug them together.

 yes it also does some of that, it shows when the agent is working, when it's done and when it needs your input. A bit buggy now. But mostly working.

Also, have some feature when it auto-fix CI failure, merge conflict...Also, when you have comments on Github, I show that in the pane and you can select a bunch of comments, you type "w" and it will copy the comments and inject in the agent and start working.

Same thing on Issues, if I tag an issue in Github with "", it will start working on its own, don't even need to type "w".

So it does quite a lot for people like me who are super lazy!

  But yes, having on the phone is pretty cool. I started working on Slack integration but paused it.

 

Ha the tag triggering auto-work is a nice touch. That's the dream, agent just picks up issues without you doing anything.

The phone piece is the thing that changed my workflow the most. Not having to be at the computer when the agent needs a decision means I actually leave. Slack integration would be interesting too but push notifications hit different when you're away from the desk.

Good luck with the launch. Shipping something you use daily is the best signal - atleast this is what is going on with me 🚀

 i like the tool but it's not easy to configure and guide in README not clear enough, if you don't mind help me in this.

Wish you all the best good idea well design.

 hi Wael, yes, didn't plan to share it just yet, I am working on some readme and docs for dev and users.
What part of the configuration would you want help on? And in terms of docs, etc...any suggestion?

 Hi Antoine, i clone the repo in my machine but i can't run it i tried all possible way, so if there's any demo video how to setup will better.

 Hi, can you tell me what happens? Here or you can send me an email toussaint.antoine@gmail or create an issue. I am working on making work with brew as well, right now only for dev.

Same loop here for months. I'd kick off a Claude Code task, go do something else, come back 40 mins later and find out it'd been sitting on an approval prompt for half that time. The real pain isn't the wait, it's not knowing whether it's still running or just silently stuck. I've tried keeping terminals visible but that just means I'm half-watching two things at once and doing neither well.

Never got around to writing a custom notification script, mostly because that felt like another thing to maintain. Curious if you're handling the case where an agent needs a decision mid-task, not just a "done" notification, that's the one that kills flow the most for me.

 

That's literally the exact problem that made us build this. The "is it running or stuck?" limbo is the worst part of working with agents.

To answer your question directly - yes, mid-task decisions are the core feature, not an afterthought. Here's what actually happens:

Your agent hits a tool call that needs approval. Pushary sends a push notification to your phone instantly. You tap it, see what the agent wants to do, and approve or deny from your lock screen. The agent gets unblocked and keeps going. The whole loop takes a few seconds.

No terminal watching, no custom scripts, no Telegram bots. You set it up once with npx pushary init and it works across Claude Code, Codex, Cursor, and Hermes.

The "done" notifications are there too, but you're right - it's the mid-task approvals that actually save the most time. That's the difference between your agent being blocked for 20 minutes and being blocked for 10 seconds.

 The lock screen approve/deny flow is exactly what I wanted. That "blocked for 20 minutes vs 10 seconds" difference is painfully accurate. The fact that it works across Claude Code, Codex, and Cursor too means I don't have to pick a different solution per tool. Will give it a try this week, appreciate the detailed breakdown.

sure here’s is the link for later
pushary.com/ai-coding

I am using an external monitor, so my terminal sits on one monitor, and the browser on the other one - I might just read something while Claude is doing its job. It's important to mention that I'm not running in a fully auto mode - I'm always reviewing and confirming even small changes.

 

That's a totally valid setup - and honestly pretty common. The dual monitor approach works when you're actively pairing with the agent.

Pushary shines most when you want to step away from the desk entirely. Grab coffee, go for a walk, context-switch to a meeting - and still approve or deny tool calls from your phone in seconds. The agent never sits idle waiting for you to glance at the right monitor.

Even with your current setup though, push notifications can cut through better than a terminal prompt sitting in the corner of monitor two. Especially on longer tasks where your attention drifts.

 fair point!

I use Warp IDE. It has passive notifications (I think it also has active ones) when the agents finish. It also has tabbed views that you can set up with names/colors/groups to keep your session straight. One of the best features, you can save the views to open later. For example, if you're working on an app, you can open iOS/Android/Watch/Wear/Web all at the same time to help keep key features in sync and get them directly onto your FAQ/Support site. I think it works pretty well.

It does have an agent that is supposed to orchestrate, but I don't know what model it's on, and I'd rather do that myself — less drift.

If you're curious about the results:

Side note: Claude Code does have push notifications when agents finish, also.

 

Warp's saved views are legitimately great, the iOS/Android/Watch/Web group you can reopen in one click is exactly the kind of thing more tools should steal. And you're right that Warp and Claude Code both ping on "done." I'm not pretending that signal doesn't exist.

Here's the gap though: "done" is the easy notification. Every tool is converging on it because it's the obvious one. The two that nobody handles well are "blocked waiting on your approval" and "here's what actually changed," and they're handled per-tool, locked inside each app. Pushary's bet is the cross-tool layer: one inbox for approvals and handoffs across Warp, Claude Code, Cursor, and Codex, so you're not juggling three different notification systems with three different definitions of "done."

Also, big agree on the orchestrator. "I'd rather do that myself, less drift" is the correct instinct. A black-box orchestrator on a mystery model is just trading visible work for invisible work. Pushary deliberately doesn't try to drive your agents, it just tells you the truth about what they're doing so you stay the orchestrator.

and trytokenmomics shipping out of that multi-view setup is a solid flex, by the way.

Quick one: do Warp's notifications fire on approval-blocked, or only on finished? That's the line I keep trying to map across tools.

 They do both… they come through on my Apple Watch as "claude has a question," so Anthropic is likely firing them now that I think about it.

 

Acknowledged counterpoint, pivoted to differentiate on payload depth and remote capability

Appreciate the straight answer, that's useful intel, and I'll concede the point honestly: Anthropic firing "Claude has a question" to your watch means the bare ping is becoming table stakes, which I've suspected for a while.

But look at what the notification actually says. "Claude has a question." That's it. Which question? About what? Is it "can I create a file" or "should I rewrite your auth flow"? You can't tell from your wrist, so the ping doesn't save you the trip, it just schedules it. You still have to walk back to the terminal, read the context, and answer there. The notification knows something happened. It doesn't carry the decision.

That's the actual gap Pushary lives in: the ping carries the question, the diff, and the risk, and you answer it from the phone. The trip back to the terminal is the product being removed, not the silence. Plus it's one inbox across Claude Code, Cursor, and Codex instead of each tool pinging in its own dialect.

Honest question back, since you've got the watch setup live: when "Claude has a question" hits your wrist, what do you actually do, walk back immediately, or finish what you're doing because you can't tell if it's urgent? That gap between ping and action is exactly what I'm trying to measure.

I still check manually most of the time and the worst part is finding out the agent was waiting for one small approval. A simple done/stuck/needs input notification would be useful. Are you building this mainly for terminals or also for Slack/GitHub workflows?

 

Direct answer: the capture starts at the terminal layer, because that's where the agents actually live and where the "waiting on one tiny approval for 35 minutes" pain is sharpest. Claude Code, Cursor, Codex. But the delivery side is deliberately channel-agnostic. The whole point is the alert finds you wherever you are, so phone and Slack are first-class, not the terminal you've already walked away from.

GitHub workflows are the natural next layer and very much on the radar, because a blocked agent and a PR waiting on review are the same problem wearing different clothes: work that's done moving and now stuck on a human who doesn't know yet. Unifying "your agent needs you" and "your PR needs you" into one inbox is exactly the direction.

And yes, done / stuck / needs-input is the entire signal. Three states, not a firehose. The one that earns its keep is "needs input," because that's the silent 35-minute killer you described. Done you recover from, stuck-on-a-y/n just bleeds.

Quick one back: if it pinged you in Slack, would you want to actually answer the approval right there in the thread, or just get the nudge and walk back to the terminal? Trying to figure out how much people want to resolve in-channel versus just be told.

First of all, I use /goal a lot, I don’t care too much about its implementation details, I just tell it what’s a success criteria, for me it’s mostly end to end test with computer use and then create PR, I have local agents setup to automatically review PRs and send me the first pass result. I’ve encoded a lot of my team’s workflow into the product I built: Vokal.team, where my agents can collaborate with my teammates’ agents, and send notification over the phone.

 

The /goal plus success-criteria approach is the grown-up version of agent direction, and most people aren't there yet. "I don't care how, here's what done looks like, end-to-end test then PR" is exactly how you'd brief a senior engineer. The fact that you've got local agents auto-reviewing PRs and sending you the first-pass result means you've already closed the loop most of this thread is still hand-cranking. Respect.

Vokal sounds like you took it a layer past where most people stop. Agents collaborating with teammates' agents is the part everyone gestures at and few actually ship, and it's the logical endgame: not just "my agent pings me," but "my agent talks to your agent and only escalates to humans when it has to." That's a harder and more interesting problem than the single-player version.

Honestly the overlap is friendly, not competitive. You've built the collaboration fabric between agents and people. Pushary is narrower, the control and observability layer that surfaces state, approvals, and diffs across whatever coding tools you're running. Different altitude, same belief that the human should be the orchestrator, not the polling mechanism.

Curious, when your agents collaborate, how do you keep one agent's confident-but-wrong output from becoming another agent's input? That trust-propagation problem is the thing I'd lose sleep over in a multi-agent setup.

 That trust-propagation problem is exactly why Vokal is built around a traceable, chained event log with identity attached. Agents can hand work to other agents, but the handoff is not just “believe this summary.” The workspace keeps who did what, what changed, what was reviewed, and where human approval entered the loop.

Humans still set the goal and approval boundaries in the beginning. Over time, the workspace gets smarter from approvals, corrections, and review trails, instead of letting one agent’s unchecked assumption become the next agent’s source of truth.

 

That's the right architecture and you clearly thought about it before it bit you, which is rarer than it should be. Attaching identity to a chained event log means provenance is a property of the system, not a vibe. You don't trust the summary, you trust the trail, and "where did human approval enter the loop" being a first-class field is the part most people forget until an unreviewed assumption has already metastasized three handoffs deep.

The one thing I'd keep poking at: a trace tells you what happened, not whether it was right. A confident-wrong assumption that gets rubber-stamped early is still fully traceable and still wrong, it just has a paper trail now. Sounds like your answer is the workspace getting smarter from corrections and review trails over time, which is the actual defense, provenance catches it on the post-mortem, the learning loop is what stops it recurring. That's a slower, more honest fix than pretending the log itself prevents bad inputs.

Funny how convergent this is from different angles. You're solving trust between agents inside one workspace, I'm solving visibility across whatever tools someone's already running. Same underlying belief that the human sets the boundaries and the system has to make truth legible rather than assumed.

Last one and then I'll stop interrogating your roadmap: when a correction lands, does it propagate back to invalidate work that was built on the wrong assumption, or does it only improve the next run? The retroactive case is the hard one.

the "agent finished 35 min ago" problem and the "agent is still looping" problem are the same thing with different ends. one wastes your time, the other wastes your tokens. been building the loop side (tokenwall.dev, validating this week), circuit breaker that catches runaway loops at iter 3 vs noticing after. would folks here want notifications about loop-events too, or is that a separate observability layer?

 

Your framing is the sharpest unification in this thread: finished-35-min-ago and still-looping are the same blindness, just pointed at different resources. One bleeds your clock, the other bleeds your wallet, and both come from the human not perceiving state in real time. Same disease, different organ.

Direct answer to your question: yes, loop-events belong in the same inbox, but they want a different verb than approvals, and that distinction is the whole game. An approval-block wants notify-first, because the human is the missing input, nothing should happen until you answer. A runaway loop wants act-first, notify-second, because by the time you read "hey, it's looping," iteration 12 has already torched the tokens. Your circuit-breaker instinct, kill at iter 3, is exactly right: the loop case is one where the notification should arrive as an FYI after the system already stopped the bleeding, "caught a runaway loop, halted it, here's what it was thrashing on," not a question you have to answer while the meter runs.

So not a separate observability layer, same layer, two response policies: approvals escalate to you, loops self-terminate and then report. The thing they share is the inbox and the truth about agent state. The thing that differs is who acts, you or the breaker.

We're clearly on adjacent faces of the same cube, you're guarding the token side at runtime, I'm on the status/approval side. tokenwall catching loops at iter 3 is the kind of thing that should fire an event Pushary would happily surface. Genuine question: how are you detecting a loop at iter 3 without false-positiving on legitimate retries? Distinguishing "stuck in a circle" from "correctly trying three times" seems like the entire hard part, and where I'd expect a circuit breaker to either nag too early or trip too late.

  this might be the single best reply on a launch-day comment i've ever gotten. that "two response policies on the same inbox" framing is sharper than mine, borrowing it.

on the loop detection: honest answer is i'm validating before building, so the exact detector isn't shipped yet. the design i'm landing on is two signals stacked:

  1. tool-call signature diff: hash of (tool_name, normalized_args). 3 identical hashes in a row = candidate.

  2. 2. progress signal: did anything change in the environment between calls? if state delta is zero across N steps, that's loop-coded. legitimate retry is usually paired with a side effect (status check, partial commit, etc).

the false-positive case you flagged, "correctly trying three times", is exactly where the exponential-backoff side-channel matters. retries are paced. loops aren't. the breaker should look for unpaced repetition + zero state delta + escalating token spend, not just repetition.

your integration suggestion (tokenwall fires loop-halt event, pushary surfaces "halted, here's what it was thrashing on") is basically the right shape. want to chat about a webhook contract once i ship the MVP? cheap version: simple POST with {agent_id, signature, attempt_count, last_args}. we could test the integration before launch-launch.

 

Take the framing, it's yours, that's what it's for. And the compliment's mutual, your detector design is the part of this conversation that's actually hard, I was riffing on policy, you're shipping the mechanism.

The two-signal stack is right, and the thing that makes it right is the second signal, not the first. Three identical tool-call hashes alone is a coin-flip, plenty of legitimate work hammers the same call. It's the zero state-delta that turns repetition into a loop, because a real retry is trying to change the world and a loop is just re-asking the same question expecting a different answer. You've basically operationalized the definition of insanity, which is the correct definition of a loop.

The backoff side-channel is the sharpest piece and I'd lean on it harder than the others. "Retries are paced, loops aren't" is a near-free signal because the timing is observable without understanding intent at all, you don't have to know what the agent meant, you just have to clock that it's repeating at machine speed instead of backoff cadence. Unpaced plus zero-delta plus rising spend is a tight three-way AND, and each one alone false-positives, which is exactly why stacking them is the move. My one paranoid note: watch the agent that loops slowly, some models pause between identical calls and could pace their way under a naive timing threshold. The zero-delta signal saves you there, which is another reason it's load-bearing.

Yes to the webhook contract, genuinely keen. Your cheap version is the right MVP, but let me push it one notch so it maps to the two-policy thing, because I think your detector naturally emits two events, not one. A loop-warning at iter 3 (notify-only, "heads up, this looks loop-coded") and a loop-halt when the breaker actually trips (acted, "killed it"). Same shape, different verb, exactly the split we landed on. So I'd want event_type in the payload to pick the policy, plus two fields that make the surfaced notification actually useful instead of cryptic:

{
  event_id,        // idempotency, so a halt doesn't double-fire
  agent_id,
  event_type,      // "loop_warning" | "loop_halt"
  signature,       // your hash
  attempt_count,
  last_args,       // raw, for the trail
  summary,         // human one-liner: "re-running the same failing migration check"
  tokens_burned    // the "here's what it cost you" number people actually feel
}

The summary and tokens_burned are the two that turn "halted" into a notification someone's glad they got. Raw last_args is great for the audit trail and useless on a phone. Let's wire the cheap version first and add fields as they earn their place. Ping me when the MVP's up and I'll stand up a test endpoint, we can fire fake halts at each other before either of us launch-launches.

  taking all of it. two-event split (loop_warning vs loop_halt) is cleaner than my one-event sketch and maps to your two-policy thing without forcing the caller to interpret. event_id for idempotency is the kind of thing you only think about after a duplicate alert in prod, glad you added it.

summary as a human one-liner is the move. tokens_burned too, "agent X just burned $4.20 on a loop" is the field that makes someone's bedtime ok. last_args stays for the audit trail like u said.

slow-loop paranoia is the right paranoia. there's a sub-case where the agent isn't malicious slow, just pretending to be a polite retry, same shape, but the zero-delta catch saves it. agreed it's load-bearing.

let's wire it. when i ship the MVP webhook (probably end of next week if validation holds, see the kill criteria on the landing), i'll ping. fire fake halts at each other before launch-launch is exactly the integration test i'd want to run. you've effectively pre-designed pushary as my first integration partner here. taking it.

This is exactly the gap I keep running into too — the hard part is not just notifications, it’s knowing the state of the work across agents: running, blocked, waiting on approval, or already finished.

That’s the problem I’m trying to solve with LineageLens as well. Curious what people think matters most in a multi-agent workflow: completion alerts, approval checkpoints, or a single unified status view?

 

Direct answer, and it has a clear winner: approval checkpoints, not close. Completion alerts are recoverable, you find out late, you shrug, you move on. A unified status view is valuable but it's pull, you have to go look. Approval checkpoints are the only one actively bleeding time while you're unaware: the agent finished and is now frozen on a yes/no, and every minute of that is pure waste on both sides. Fix that and you've caught most of the pain.

But those three aren't really peers, they're layers of one thing. The status view is the foundation, you can't alert on a state you don't track. Completion and approval are just the two states worth interrupting someone over. So "which matters most" is half a trick question: you build the status layer because you have to, then approval is the alert that earns its keep.

The trap in "single unified status view," and the thing I'd watch for with LineageLens: a view people have to watch becomes another dashboard they forget to check. The value evaporates if it's pull instead of push. It should exist for when you want it, but it should tap you, not wait for you.

Genuine question, not a pitch: where's LineageLens focused, the lineage of what each agent did, or the live state across them? The name makes me think you're after the durable trail, what changed and why it survived, which is a lagging-quality signal, while running/blocked/done is the live signal. Those are different products that share a status layer. Which one's your spine?

I found the same issue...but gave myself a reassuring answer: I'm saving hours anyway... and got along with it.

 

That's a genuinely healthy answer, and I don't want to talk you out of it, because you've spotted something a lot of people in this thread haven't: the wasted 20 minutes only stings if you measure it against perfection instead of against the before. Net of everything, you're hours ahead. Optimizing the last 20 minutes when you just saved three hours is the kind of thing that feels productive and isn't. "Saving hours anyway" is the correct frame for most people most of the time.

Here's the only place I'd gently poke, and it's not to sell you anything: that math holds beautifully at one or two agents. The reason it stops holding is purely parallelism. When you're running one, idle time is just a gap in a session that still netted you hours. When you're running five, the idle time stacks, because while you didn't notice agent two was stuck, agents three through five also finished and started waiting, and now the wasted time isn't a footnote, it's the bottleneck on how many you can actually run. The "I'm saving hours anyway" buffer is real, it just gets thinner the more agents you add, until one day the overhead is the thing capping your throughput.

So your answer isn't wrong, it's right for where you are. The honest version of my pitch is: this matters exactly when you decide to scale past what "I'll just check eventually" can hold, and not a moment before. If two agents and a relaxed attitude is your setup, you've genuinely solved it, and a tool would be solving a problem you don't have yet.

Question, because your framing is actually useful to me: at what point would the wasted time stop feeling like an acceptable tax, is it a number of agents, or is it more about the task being important enough that a 30-minute stall actually costs you something downstream? I'm trying to figure out whether people graduate into this problem by volume or by stakes.

 Thanks for the thorough and argumented answer. Obviously you've gone deep in the matter, more than I have ever dreamt of. Or maybe you're more of a developer analytical mind, and I'm more of a poet mind, sort of thing. With the development of my wonderful kid, memsoph.ai, which will launch in a couple of weeks here, I was so excited to go on and on, that I don't really ponder on your assumptions.. maybe because, actually, I rarely used more than 3 agents. Can I upvot your product or it is too late?

 

Ha, poet mind versus analytical mind is exactly right, and don't sell the poet short, you summed up in one line ("I'm saving hours anyway") what took me four paragraphs to circle. That's the poet winning.

And you just answered your own question without noticing: you rarely run more than 3 agents, which is precisely why the wasted time hasn't bitten you. You're below the line where it starts to hurt. So your relaxed take isn't naive, it's correct for your setup. No notes.

You can absolutely still upvote, never too late, and thank you. But honestly the better move: just try it. . Even at 3 agents the "it's been stuck waiting on you for 12 minutes" ping might earn its keep, and if it doesn't, you'll have a sharp poet's reason why, which is more useful to me than an upvote anyway.

Good luck with the launch in a couple weeks, building something you're that excited about is the whole point. Go enjoy it.

 will check, and most definitely upvote.

Honestly this is one of the biggest pain points with multi-agent workflows right now. I keep falling into the same trap — kick off a task, get distracted, come back to find it either finished an hour ago or has been stuck waiting on me the whole time. Neither is great.

I've been keeping a terminal visible on a second monitor which helps a little, but it obviously doesn't scale. A simple notification layer that just says "agent done" or "needs your input" would be a game changer. Curious to try what you're building!

 

The second monitor is the upgrade everyone tries right before they give up on watching entirely, and it's worth naming why it only half-works: you didn't reduce the monitoring, you just gave it its own real estate. The glance is cheaper, but it's still a glance you have to remember to take, and the screen still goes quiet the same way whether the agent finished, got stuck, or crashed. You bought a better seat for a show you still have to keep looking at. And the moment you've got more agents than fit legibly on that monitor, you're back to scanning.

The "agent done / needs your input" split you described is exactly the right minimum, and I'd just push you to weight them differently: done can wait, needs-input is the one actively burning your time while it sits. That second one is the whole reason to build this. The second monitor treats them identically, both just show up as activity on the screen, which is precisely why the silent wait still slips past you.

You said you're curious to try it, so genuinely, do, it's at , and you're exactly the person whose feedback I want, because two-agents-and-a-second-monitor is the real-world setup, not the power-user fantasy. If it doesn't beat your current monitor, I want to know why.

One question while you're still in the manual phase: on that second monitor, when an agent goes quiet, how long before you notice, is it seconds because it's in your eyeline, or does it still take you minutes because the quiet doesn't grab you the way movement does? I'm trying to figure out whether visibility alone is the fix people think it is, or whether silence is invisible even when it's right in front of you.

First
Previous
123
•••
Next