Launching today
AgentManager
Never miss a Claude Code session waiting for your input
66 followers
Never miss a Claude Code session waiting for your input
66 followers
A floating macOS window for every Claude Code session. The moment one needs your input, it surfaces — and hides when all is clear. Jump to the exact terminal in one click. Native Swift, notarized, 7-day free trial.
Custom Browsing History
The 'waiting for input' detection is the whole value here — auto-surfacing and jumping to the exact iTerm2/Cursor pane is what I'd actually use daily. How does it read session state under the hood: scraping terminal output / the TTY, or hooking the Claude Code process directly? Mostly wondering how it avoids false 'waiting' signals when a session is just mid-stream on a long tool call.
Custom Browsing History
@noctis06
Great question! It's neither — no TTY scraping, no process hooking. AgentManager uses Claude Code's official hooks: it registers them in ~/.claude/settings.json, Claude Code invokes a tiny binary on every lifecycle event (prompt submit, tool use, notifications, stop…), that writes per-session state to a local JSON file, and the app watches it with FSEvents. No polling, no daemon, no network — everything stays on your Mac.
False "waiting" can't really happen because state is never inferred from output or silence. "Waiting" only comes from explicit signals — a permission prompt, a plan-approval dialog, or an AskUserQuestion call. A long tool call just fires PreToolUse and stays "processing" until it finishes, no matter how long it streams. Trickiest edge case was background subagents that outlive the main response — those are tracked too, so sessions don't flip to "done" early.
Happy to go deeper if you're curious!
'hides when all is clear' is the half most tools skip, they just add alerts. with several sessions waiting at once, does it rank which to surface first?
Custom Browsing History
@andrewzakonov
Thanks — "hides when all is clear" was actually the starting point of the whole app. The alert part is easy; the quiet part is what makes it livable.
Honest answer: no ranking. All sessions live in one list in a stable order (by launch time), and rows never reorder on state changes — waiting ones just light up with a pulsing amber stripe. That's deliberate: with a handful of parallel sessions, reordering would break your spatial memory of "top row = the refactor, second = the tests", and you'd misclick jumps. A stable list you can scan in a second beat every ranking scheme I tried.
In practice you glance at the amber rows, click the one you care about, and you're in the right terminal. If you'd find explicit prioritization (e.g. "waiting longest first") genuinely useful though, I'm open to it — that's exactly the kind of feedback I'm here for.
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.
Custom Browsing History
@alieksia
Thank you! 🙌 And yes — a clean finish is a first-class event, not just blocked-waiting. When a session finishes, its row turns green and the floating window surfaces the same way it does for waiting; it only hides when there's nothing left that needs your attention. The menu bar also shows a live count per state, so you can see "2 running, 1 done" at a glance.
One detail that matters for long pipeline jobs: "done" isn't premature. If the main response stops but background subagents are still working, the session stays "processing" and only flips to done when the last one actually finishes.
The only thing reserved for waiting is the sound alert — a finished session surfaces silently, so a long run ending doesn't interrupt whatever you switched to. If you'd want an optional sound for completions too, that's an easy toggle to consider — tell me and I'll put it on the list!
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?
Custom Browsing History
@ark_y_k
Exactly the annoyance that made me build it 😄 And no individual checking needed — every session registers automatically and they all live in one floating window, each with its own state light. The moment any of them starts waiting, the window surfaces with that row pulsing amber; when nothing needs you, it hides itself. The menu bar shows a live count too, so even with the window hidden you can see "3 running, 1 waiting" at a glance.
Small detail I'm fond of: if several sessions hit "waiting" at nearly the same time, the sound alert has a global debounce so you get one meow, not a chorus. From the window it's one click to jump to the exact terminal (iTerm2 pane, VS Code window, etc.) that needs the answer.
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.
Custom Browsing History
@galdayan
Honest answer: strictly local right now. The hook fires on the machine where Claude Code runs, so in an SSH session it would run remote-side and write its state file to the remote filesystem — which the Mac app never sees, since it just watches a local directory. So installing the binary remotely wouldn't help today; you'd get state files stranded on the server.
Could it work? Partially, in principle. Detection is just JSON files in a directory, so a synced/mounted ~/.claude/agent-manager/sessions/ could carry remote state to the Mac — that half is plumbing. The hard half is the jump: locally the hook walks the process tree to find the exact terminal pane, and that chain breaks at the SSH boundary. Mapping a remote session back to the local terminal that's SSH'd into it needs a different mechanism, and I'd rather not ship a jump that lands on the wrong window.
You're right that this is where menu-bar tools usually stop, and a local+remote mix is a real workflow — it's on my radar. Out of curiosity: are your remote sessions inside tmux/screen on the server, or plain SSH in a local terminal tab? That changes which approach would actually be reliable.
This is exactly the annoying Claude Code failure mode. The floating session state is useful, but the one-click jump back to the right terminal is the part that makes it feel workflow-native instead of just another alert layer.
Also love the cat room, as long as Simple mode exists for when I need to pretend I am serious.
Custom Browsing History
@aditya_harish_2002
Thank you! And you nailed the design bet — alerts alone just move the problem ("now I have unread alerts"). The jump is what closes the loop, so I spent a silly amount of time on precision: iTerm2 lands on the exact pane, Terminal and Ghostty on the tab, VS Code / Cursor / Zed on the right project window.
And yes, Simple mode exists precisely for screen-sharing-with-your-manager moments 😄 The cats will wait for you.