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

@riya_pariyar 

"A finished agent I can recover from, one sitting on a y/n for 40 minutes hurts differently" is painfully accurate. The finished one wasted your time. The blocked one wasted its time and yours, simultaneously, while smugly doing nothing.

To your question: there's a layer in between, on purpose. The agent doesn't push to you directly, it hits Pushary, and we relay it as the approval request with context attached, then route your y/n back to the right terminal. Going direct would mean every agent needs your device, your auth, and your phone number baked in, which is a security nightmare and breaks the second you add a seventh terminal. The middle layer is what lets one inbox sit across Claude Code, Cursor, and Codex at once.

The fun part is the layer can also be smart: batch the noise, flag the risky approvals louder than the trivial ones, so you're not getting paged for "can I create a file."

Out of curiosity, would you actually want to approve from your phone, or just be told it's blocked so you can walk back to the machine? Trying to figure out how many people want full remote control vs. just the heads-up.

@robstout 

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.

hopscotch.city 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.

@kevinzrzgg 

"Separate progress logs from needs-attention" should be the first line of the spec, and it's the line most people get wrong. They pipe every step to a notification and train themselves to ignore the channel, which is worse than silence. The signal is the four state changes you listed, nothing else. Progress is for the log you read when you choose to. Attention is for the ping you can't ignore.

You're also right that a tiny script gets you most of the way on one tool, one machine. The catch is that's where everyone starts and then quietly drowns. The script that watches Claude Code's log doesn't know about Cursor's, the one for your laptop doesn't follow you to your phone, and "finished with a summary of changed files" needs the agent to actually emit that summary reliably, which is its own small project. It scales to one of you and one tool beautifully, and falls apart at six agents across three tools.

That's the entire reason Pushary exists: the exact state machine you described (running, blocked, failed, done-with-diff) but as one layer across tools and devices, so you're not maintaining a script graveyard. You nailed the spec. We just productized the part where it has to keep working at scale.

The real unlock is your last sentence: making the agent declare when it needs a human instead of silently waiting. Curious, in your setup do you prompt the agent to announce that, or do you infer "blocked" from the terminal going quiet? The detection method is the part I keep going back and forth on.

@mert__33 

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.

@kevinzrzgg 

"Closer to a tiny handoff report than a push alert" is the cleanest way I've heard anyone draw that line. A bare "agent finished" just relocates the work, you still have to climb back into the terminal to find out what finished means. The notification should carry the decision, not just announce that a decision is waiting.

Your three boring bits are the exact payload: what changed, what it needs from me, and did it touch anything risky. That last one is the underrated star. Most setups surface changed files and failures but never flag "by the way, I edited the auth flow," which is precisely the change you'd want screaming at you and the one that arrives silently. Changed files and tests are the body of the report. "Touched something risky" is the headline.

This is more or less Pushary's whole spec, so either you've been reading my notes or we independently arrived at the same correct answer. The push is the handoff: changed files, tests run, failures, waiting-on-approval-for-X, with risk flags promoted to the top so the loud stuff stays loud.

The hard part is the risk flag, because the agent has to reliably know it touched something sensitive. Curious how you'd draw that line, declare risky paths per project up front (auth, payments, migrations), or have the agent infer risk on its own? I trust the first more than the second right now.

@goddey_uwamari 

The AWS-bill parallel is painfully good. "You find out what it cost when the invoice lands" is the exact same failure mode as "you find out the agent was blocked when you happen to glance at the terminal." In both cases the system was telling you the whole time, you just had no surface listening. Observability gaps are all the same shape: work happening faster than the human can passively perceive it.

To your actual question, the patterns that keep showing up in this thread and hold up: isolate first (git worktrees, one per agent, so contexts never collide), then collapse the signal to three states (done, blocked, failed) instead of streaming every step, then make the notification a tiny handoff report (changed files, tests, and crucially a flag if it touched anything risky) rather than a bare "done." And the cultural one: make the agent declare when it needs a human instead of silently waiting. Silence should never be the blocked state.

That stack is basically what Pushary productizes, which is the honest answer to "any solid tools yet." Most people are hand-rolling it with curl pings and log-watchers, and it works until you hit six agents across three tools and your script graveyard becomes its own maintenance job. The pattern is well understood now. The unsolved part is making it work at scale without you babysitting the babysitter.

Funny enough your world might be the next layer down: an agent that's burning tokens or spinning a runaway loop is a cost-observability problem wearing a coding-agent hat. Have you seen anyone tie agent activity to spend in real time, or is that still bill-arrives-and-you-cry?

@veer_singh14 

"Silent killer" is the perfect phrase for it 🎯 — the agent finishes its actual work in 5 minutes and then just... sits there waiting, and you don't find out for half an hour. The work was fast; the waiting on you to notice is what's slow.

Appreciate the read on it being a unified layer rather than another one-off script. That's the bet exactly — everyone's already solved this badly with their own custom ntfy/Pushover hacks, but nobody wants to maintain that glue across Claude Code, Cursor, and Codex. Are you currently running any custom notification scripts yourself, or still in the manual terminal-watching phase? Trying to gauge how many people have already duct-taped a solution vs. just living with it.

@toch_aria 

You basically wrote my product spec, so I'm either flattered or out of a job.

You're right: "done" is the shallow version. What changed, why, what it touched, what needs sign-off, that's the actual signal. The notification is just the courier. The .md-as-audit-trail move is the smart part, because future-you debugging at 2am does not accept "vibes" as a commit message.

That control-while-it-moves-faster-than-you-can-watch problem is the whole reason pushary.com exists. Think of it as a control panel for your agents: status, approvals, and risk flags across Claude Code, Cursor, and Codex, so you stay in the loop without babysitting six terminals.

Quick one back at you: do you prompt for that .md update every time, or have you wired it into a skill so it's automatic? That reliability is load-bearing for the whole thing.

@florent_duthoit 

This is genuinely one of the better setups in the thread, and the insight buried in it is the real gold: "anyone from a company should be able to help it get the work done." That's the part most people miss. Once the agent can route a question to whoever can actually answer it, you've turned a solo bottleneck into a team that happens to be asleep half the time.

The Slack relay is smart, and it's basically Pushary's thesis built by hand. The two places it gets fragile: you had to wire it up per agent, give it Slack access, and format the prompts just so, and the "wait X minutes and check back" loop is polling sneaking back in through the side door. Works great with a cofounder who knows the dance. Gets messy across six agents and a bigger team where you also want to know what it changed, not just answer its question.

Pushary is that pattern as a product instead of a custom integration: structured handoffs with risk flags routed to the right person, no per-agent plumbing, and the relay handles the wait so the agent isn't burning cycles checking back.

You nailed the one honest limitation too. Planning still chains you to the desk. Agreed, and I think that's correct for now. You should be in the room for the plan. It's the babysitting after the plan that shouldn't require a human at all. Curious, does your agent ever ping the wrong person, or have you got the routing dialed in?