feature request: repo/branch/agent overview panel

[im-stuff]

I saw the idle indicator in 0.2.6. It seems you might already be going in the direction I’m hoping!

I want to have a single view that shows all terminals and their statuses (idle, busy, needs input, etc) so that I can monitor all of my agents at once.

Perhaps this could be a sticky pane on one side, like a file browser, but in keeping with conduit’s philosophy, it’s a visualization of the repos you have open, the work trees within that repo, and the agents that are currently operating on those worktrees.

here's a mockup of what I'm hoping for:

I could then select from any agent and:

• switch to its tab and activate it
• bring it up in focus mode
• trigger a merge/delete it
• ?????

It would be trivial for a user to give the various CLIs a custom hook for reporting status, or if they don’t have hooks, indicate in the prompt that they should report their status using some conduit CLI report-status function. You could even do custom status types, or ask the cli to report a 40 character descriptive status.

Seeing the structure this way would make it much easier to make sense of the worktrees you have going, and to visualize how the merges will be "rolled up".

I think that this could unlock some major productivity gains in Conduit, while hopefully keeping with the terminal-first and human as the orchestrator concept.

[lostintangent]

Agreed! Ultimately, the goal of Conduit is to create something that can be as simple or as complex as you want, and to allow zooming in and out of your work. And importantly: to enable that in a way that doesn't feel like an obscuring abstraction over your coding agents/CLI.

That said, the view you're describing is the semantic visualization of the fully zoomed out state (as opposed to the pane-structured visualization we already have). And we definitely need this :)

As you guessed, introducing a generic means of detecting idle was a key primitives towards being able to track this. And we have a few other steps we need to nail, that will make composing this sort of view feel really natural.

In particular, we already know the project and branch for each terminal, and we can now track whether they're active or idle. But as you mentioned, we wouldn't currently be able to detect "needs input", since to Conduit that just looks like idle.

However, since we already have the Conduit CLI that can be used to communicate with the environment, you could imagine we introduce a cli command to update the status of a terminal, as a mean to compliment the built-in detection for idle. So I think I'll get this working as a next step, so that we can prove we have a reliable mean of tracking terminal state across tabs. Then we can layer it together in the view you described.

[im-stuff]

Great! I actually came to Conduit looking exactly for this (as a starting point at least). I've found things that are somewhat similar (in that they give an overview of agents), but they're all too opinionated in their approach and even the CLI based ones abstract away the CLI...

Happy to test or give feedback whenever!

[lostintangent]

Update: The latest version of Conduit introduces two new things...

1. When a tab has a terminal that's actively running, the tab's text will display a "shimmer" animation to indicate that status

2. The "conduit notify" command can be used to signal that a terminal is idle due to requiring user attention (as opposed to being done). When a terminal is signaled with this command, its tab will display an orange dot, as opposed to the blue dot (which signals "done and unseen"). This allows you to configure your coding agent to call this command whenever it asks for user input, and have that be translated into this orange dot

Also, I reframed the "show idle indicator" setting to "show tab state", since the tabs can now be idle, idle unseen (blue dot), idle notified (orange dot), or running (shimmer animation). And after a bunch of dogfooding, I decided to enable this setting by default,

If you get a chance to try it, I'd love to hear any feedback. Since as we discussed above, this is the foundation for a broader view.

[im-stuff]

It definitely works. I've got it running on the notificaiton and stop hooks in claude code and so far its working reliably. And I like the shimmer animation.

You didn't mention that you also got the focus terminal feature working! That's great.

[im-stuff]

The notifications from conduit notify seem to be firing with random delays into the 5-10 minute range. The hooks I'm firing (via claude code) are working but I'll randomly get conduit notifications very late, sometimes in the incorrect order.

[lostintangent]

Wierd 🤔 are you seeing the running vs idle vs idle unseen (blue dot on a tab) generally working OK? And the issue you're seeing is primarily with calling "conduit notify" from a CC hook?

Seeing delays in the order of minutes is nuts, so I'll look into this now and see if I can spot anything.

[lostintangent]

Also quick question: are you simply calling "conduit notify"? Or are you calling notify with a message as well?

[im-stuff]

The dot seems to be working ok.

I'm running conduit notify ready 2>/dev/null || true and conduit notify question 2>/dev/null || true for when claude asks a mjultiple choice question. Added the 2>/dev/null || true to suppress errors when using other terminals.

[lostintangent]

Just to confirm: you're seeing the amber dot quickly, and it's the toast notification that is being delayed?

I just ask since I was trying to repo this with just running "conduit notify" (no message) and I'm seeing the tabs being annotated correctly and in real-time (a notification triggers an amber dot on a tab as opposed to the blue). But seeing your scenario, I wonder if the issue is related to the toast notification, so I'll look into that.

[im-stuff]

Its specifically the toast notification that seems to appear late. I'm firing off other hooks at the same time that are working fine so I don't think its that I'm running any blocking hooks.

[lostintangent]

Alright cool, thanks for confirming that! I spent a ton of time optimizing the tab state (running, idle, idle unseen, idle notified), and so I'm glad to hear that part is working. I'll take a look at the toast part specifically and see what might be happening here.

Out of curiosity: would it actually be better if the notify command had a way to indicate the "type" of notification? That way you could delineate between a question or ready state ("conduit notify -t input-required")? For example, showing an amber question mark in the tab vs a dot.

Or would you also want the toast notification? I suppose allowing the delineation between ready and input required would be valuable either way, but I just wanted to ask if you were also wanting to rely on toasts vs tab status.

[im-stuff]

Hm, I definitely like the toast notification but that's partially because it's a one-click teleportation to the relevant pane. I am already essentially doing what you describe, I am firing notify ready as my stop hook and notify question for the notification hook in claude (which inexplicably is what they use for when claude has a multiple choice question...)

In practice though, I haven't been distinguishing much between the two. There's not much difference between ready and needs input. Either way I need to go look to see what it has done or what it needs to get it going again. I think once we've got the overview-view, having some conduit-dictated status types would make more sense since that could have implications on UI styling/badges, contextual actions, or human and/or agent controlled orchestration.