How do you stay aware of what your AI coding agents are doing?
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.
Replies
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.
https://github.com/AntoineToussaint/pilot
Pushary
@antoinetoussaint
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.
@aadilghani 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 "@pilot", 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!
@aadilghani But yes, having on the phone is pretty cool. I started working on Slack integration but paused it.
Pushary
@antoinetoussaint
Ha the @pilot 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 🚀
@antoinetoussaint 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.
@waeils 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?
@antoinetoussaint 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.
@waeils 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.
Pushary
@nolan_vu
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.
@aadilghani 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.
Pushary
Pushary
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.
Pushary
@sk_uxpin
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.
@aadilghani fair point!
Humans Not Invited
I first test if they make it through this: https://11111101010.humansnotinvited.com/
Pushary
@damjanski
I'm confused from this, what is your mission?
Great thread — here's my setup across three agents:
Claude Code — /remote-control sends live activity notifications straight to my Claude mobile app.
Codex — Telegram plugin, same concept. Approval needed? It pings me instantly.
Cursor — We solved this with our own product, Auxly-Task — an AI task management extension for VS Code/Cursor that gives you full activity tracking, memory, notification, approval gate and audit trail across sessions.
Funny timing — we're launching Auxly-Memory on Product Hunt today, Your notification problem is real — but there's another problem you didn't mention: every time you jump between agents you're losing context. Claude knows nothing about what Codex just did. That's what we're launching today on Product Hunt — Auxly-Memory. One shared memory vault across local in your machine all your agents. Not a notification tool, but solves the invisible tax you're paying every time you switch.
Would love to see what you're building on the notification side — and if there's appetite, we could explore adding it as an Auxly-Memory add-on. 😉
auxly.io
Pushary
@waeils
Thanks for sharing your setup! Interesting to see the different approaches.
Quick clarification though, Pushary isn't just notifications. The core value is the human-in-the-loop approval gate: your agent hits a sensitive tool call, you get a push notification, you approve or deny from your lock screen in seconds. No terminal required, no Telegram bots to maintain. One MCP connection and it works across Claude Code, Codex, Cursor, and Hermes out of the box.
The context-switching problem is real, but it's a different problem. Notifications and approvals need to be instant and reliable, that's infrastructure, not a feature you bolt on later.
Cool that you're launching today too. Good luck with Auxly-Memory!
I run into this too. The agent can be doing useful work but the annoying part is not knowing whether it finished, got stuck or is waiting for approval. Right now I mostly check manually which breaks focus. A simple notification for needs approval, finished or failed would already make the workflow feel much less messy.
Pushary
@ada_johnsen
You nailed the core problem in one sentence - it's not that the agent isn't working, it's the not knowing which of the three states it's in. "Finished," "stuck," and "waiting for approval" all look identical from across the room, so you end up context-switching just to check, which is the one thing that kills deep focus.
That three-state signal (needs approval / finished / failed) is exactly the minimum viable version of what I'm building - turns out it's also like 90% of the value. Out of curiosity, which of those three would actually save you the most time if it pinged you reliably? My hunch is "needs approval," since that's the one silently burning minutes while you assume it's still running.
I hit the same loop, the worst version is the agent that finished half an hour ago sitting next to the one silently waiting on my approval the whole time. What helped more than notifications was making each agent surface what it changed and what it's blocked on, so coming back is a ten-second scan instead of re-reading the session.
Pushary
@theuniverseson
This is a really sharp distinction and I think you're pointing at something most people (including me at first) conflate. There are actually two separate problems: when to come back (the notification) and how fast you can reorient once you're there (the summary of what changed + what it's blocked on). A notification with no context just teleports you back into a wall of scrollback - you've saved the polling but not the re-reading.
The "ten-second scan instead of re-reading the session" framing is exactly right, and it's making me think the notification and the diff/blocker summary shouldn't be two features - the push should be the summary. Instead of "Agent 3 needs approval," it's "Agent 3 changed X, Y, Z, blocked on: should it touch the auth layer?" so the decision happens at the notification layer, not after you've climbed back into the terminal.
How are you surfacing the "what it changed / what it's blocked on" right now is that baked into your `/handover`-style prompt, a git diff summary, or something the agent writes out on its own at stop time? Curious whether it's reliable enough that you trust the scan, or you still spot-check.
@aadilghani Agreed, the push should be the summary, not a ping. Right now I just have the agent end each run with a plain what-changed and what-it's-stuck-on line, so the call happens at the notification instead of after you climb back into the terminal. Honestly more manual than a real handover so far.
"Agent is working" is not the useful signal for me.
I need the ugly handoff:
- files touched
- commands run
- checks that failed
- checks it skipped
- assumptions it made
- what still needs a human
The chat transcript is where the agent sounds reasonable. The handoff is where you find out whether it actually did the work.
Pushary
@simonkyanite
"The transcript is where it sounds reasonable" should be printed on a t-shirt. That's the whole problem in one line. Agents are great at confidently narrating work they didn't fully do.
The two you listed that nobody surfaces: checks it skipped and assumptions it made. Those are the silent landmines. A green checkmark on the three tests it bothered to run tells you nothing about the two it quietly decided weren't worth it.
That ugly handoff is exactly what pushary.com is built to show: files touched, commands run, what failed, what got skipped, what still needs you. Less "agent is working," more flight recorder for your agents so you find out before production does.
Which line item burns you most in practice, the skipped checks or the unstated assumptions? Curious which one I should make loudest.
I usually provide the AI with an API that logs data in real time. Then I tell the AI to send me a CURL GET request after completing any small step, noting who reported it and what was done. Then I just monitor this file to get a comprehensive overview.
Pushary
@smith2026
That is a genuinely clever hack, and also a slightly cursed one. You basically built your own telemetry pipeline out of curl and willpower. Respect.
The catch is you now own that API, that log file, and the prayer that the agent actually remembers to ping it after every step instead of "forgetting" the one that mattered. It works right up until you're maintaining infrastructure for the thing that was supposed to save you time.
That's the exact duct-tape setup pushary.com replaces: same idea, the agent reports what it did and where it's blocked, but as a hosted control panel across Claude Code, Cursor, and Codex instead of a file you babysit. You keep the comprehensive overview, you drop the plumbing.
Question for you, since you clearly think in systems: does your agent reliably fire that GET on every step, or do you catch it skipping the report when it gets deep into a task?
mostly just accept the wasted time:)
the approval-wait problem is the one that actually stings though.
a finished agent i can recover from.
one that's been sitting on a y/n for 40 minutes while i'm in another tab. that one hurts differently.
curious how you're handling that in pushary: does the agent push the approval request directly, or is there a layer in between?
Pushary
@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.