Launching today
AgentManager
Never miss a Claude Code session waiting for your input
80 followers
Never miss a Claude Code session waiting for your input
80 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!
@umechanhika Clean — FSEvents on a hook-written state file is exactly the no-false-positive design I was hoping for. Since it is driven entirely by Claude Code’s hook lifecycle, does that mean only Claude Code sessions surface today, and the Cursor/Codex panes in your pitch need their own hook equivalent — or is there a fallback for agents that do not emit lifecycle hooks?
Custom Browsing History
@noctis06
Sharp read — and yes, Claude Code sessions only today. One clarification on the pitch: Cursor / VS Code appear there as jump targets, not as detected agents — meaning a Claude Code session running inside Cursor's terminal is detected like any other, and the click lands on the right Cursor window. The agent being watched is always Claude Code itself.
And no, there's no fallback for agents that don't emit lifecycle events — deliberately. The only possible fallback is inferring state from output or silence, which is exactly the false-positive machine you were glad this isn't. I'd rather say "not supported" than "supported, sort of, with guesses."
That said, the architecture doesn't actually care who writes the state files — they're just JSON in a watched directory. If another agent CLI exposes a proper hook/event mechanism (or grows one), first-class support is very much on the table. Which agents are in your mix? That tells me where to look first.
'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.
@umechanhika A floating window with per-session state lights is a great visual solution — way less cognitive load than switching between terminal tabs to check status. Does the window scale well once you've got a lot of sessions running, or is there a practical limit before it gets cluttered?
Custom Browsing History
@ark_y_k
Thanks! It scales further than you'd think, because the design leans on two things: each session is a single compact row (the window is a fixed 240pt-wide strip that just grows downward), and the order never changes — sessions stack in launch order, so row 3 stays row 3 all day.
But the honest answer about clutter: you mostly don't read the list at all. The app's whole job is to filter attention for you — when everything's fine the window isn't even visible, and when it surfaces, your eyes go straight to the pulsing amber rows and skip the rest. So cognitive load tracks the number of sessions needing you, not the number running. I built it around my own workflow — several sessions in parallel — and in that range it stays calm. If you're orchestrating dozens of headless agents, that's honestly a fleet dashboard problem and a different tool.
(The pixel-art cat room does get delightfully crowded as sessions grow, though. Some call that clutter. I call it a feature 🐈)
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.
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.
Custom Browsing History
@talhakhalidmtk
One window, all sessions — each gets a row with its own state light, and the list grows as sessions come and go. No per-session windows to manage.
Noise was actually the main design constraint, because the whole point is that you're juggling several agents and the tool shouldn't add to it. So: the window hides itself whenever nothing needs you and only surfaces when a session is waiting or finished. There are no Notification Center banners at all. And the sound alert is a single short meow with a global debounce — if three sessions hit "waiting" at once, you hear one meow, not three. The more agents you run, the more that restraint matters.