AgentManager

Never miss a Claude Code session waiting for your input

Mac

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product Hunt

Been running long Claude Code sessions for my data pipeline work and the "waiting for input" problem is real — I even hacked together my own task-loop script to work around it. Curious how you handle sessions that need permission prompts mid-run? Congrats on the launch!

The realize-ten-minutes-later-it-wanted-a-single-yes thing is my exact daily paper-cut, so this is aimed right at me. The part I'd want to understand is detection: how do you know a session is waiting for input versus mid-thinking, and how does that hold up across iTerm2 / Terminal / a Cursor window, since they don't expose state the same way? The failure mode that kills these tools for me is a "ready!" ping — or a cat-meow — when it's actually about to keep going on its own; one wrong alert and I start ignoring all of them. Are you parsing the terminal buffer, watching the process, or hooking something Claude-Code-specific?

this is exactly the problem with running a few Claude Code sessions in parallel - you either tab through terminals constantly to check status or you get pulled back way too late because you forgot which one was still going. a floating window that only shows up when something actually needs you is the right shape for this, way better than a generic desktop notification that gets lost in the pile. does it distinguish between "needs input" and "just finished, fyi" or is it one signal for both right now?

hooks in ~/.claude/settings.json is the robust call — the seam is that it's one shared file. the other claude code watchers on this page register there too, and an uninstall leaves a stale path still firing on every event.

Mostly Claude Code as the daily driver, with Codex CLI as the second seat and Aider for quick one-off edits. Codex is the one I d want next since it has a hooks/notify config, so a small state-writer there would slot straight into your FSEvents watcher without you inventing anything new. Aider s the weak link: no real lifecycle events, so it d be exactly the guess-from-output case you re right to refuse.

Love this idea, especially the jump-to-terminal one click since that always trips me up. One thing that would seal the deal for me is per project status icons in the floating window itself, like a little red dot or spinner right next to a project name so I can tell at a glance which session needs me without scanning titles. Would also be great if those icons respected Do Not Disturb or hid when a session is just running a long thinking step versus truly waiting on me.

Finally something that solves the "which Claude session is stuck" problem. The floating window just appearing when input is needed is exactly the kind of low-key native touch I want from a Mac utility.

The native Swift choice really shows here — having a floating window that just appears and disappears instead of fighting with another Electron app is such a relief.

Does it track multiple Claude Code sessions at once, or is it one window per session? Wondering if this gets noisy if you're juggling several agents.

this looks super useful for keeping tabs on multiple sessions, honestly the auto-surfacing is a nice touch. one thing though, it would be great if you could pin certain sessions to stay visible even when nothing needs input, so you can monitor like a long-running build or deploy without it disappearing on you

Claude Code sessions that need input mid-task is real pain, especially when you're juggling multiple things. Does it support notifications on iOS or just Mac desktop alerts?

The local hooks approach is the right tradeoff here. Once an agent has access to repos, terminals, and approval prompts, I want the session monitor to be boring infrastructure: local state, no output scraping, no network dependency, and stable session identity so I can trust the jump target.

the hooks-based detection is the right call, way more robust than scraping terminal output. one case I didn't see covered: what happens with a Claude Code session running on a remote box over SSH rather than locally on the Mac - does the hook binary need to be installed remote-side too, or is this strictly for local sessions right now? I run a mix of local and remote-server sessions and that's usually where these menu-bar tools stop working for me.

That's clever. Any plan to support Linux or Windows once Claude Code agents run there?

Honestly this looks super useful since I constantly lose track of which Claude session is actually waiting on me. One thing though, would be great if it could play a subtle sound or send a native macOS notification when a session needs input, kind of like how Messages does it. Sometimes the floating window might be hidden behind another app and I would totally miss it otherwise.

Finally something that solves the constant tab-switching annoyance with Claude Code. The auto-surfacing when input is needed feels genuinely native, not bolted on.

Missing a Claude Code session waiting for input is such a specific but real annoyance once you're running multiple sessions. Does it notify across all active sessions simultaneously, or do you need to check in on each one individually?

A click-to-jump shortcut is great, but it would be even better if I could pin certain sessions to stay visible even when idle, since I often switch between two long-running tasks and lose track of which window belongs to which project.

Congratulations on the launch! One question: does it also notify when a session finishes cleanly, or only when one is blocked waiting for input? I run long pipeline jobs, and knowing when they are done matters as much as knowing when they are stuck.