I usually have two or three Claude Code sessions open: a frontend, an API, sometimes a side project. And the most annoying thing wasn't the model o...
For further actions, you may consider blocking this person and/or reporting abuse
Putting the permission card on the phone too is a nice touch. Most of my lost time is exactly that yellow-dot case.
To your question, from the Auten team (we build a computer-use MCP server, so our sessions click and type on the real screen): what I'd want at a glance is which session is currently driving the mouse and keyboard. Two sessions running a screen-control tool at once fight over focus, and a dot that says "this one holds the screen", plus a way to make the others wait, would save a lot of confusion.
A smaller one: how long each yellow dot has been waiting. Fifteen minutes vs fifteen seconds changes which one I click first.
Can the desktop MCP server see the other sessions' states, or only the windows and scenes?
Thanks, this is really useful.
Waiting time: you're right, the dot only shows the state right now, not how long it's been yellow. 15 s vs 15 min is exactly the difference that matters when three are waiting. I opened an issue for it: github.com/fxd-gif/vibedesk/issues/5 (a 👍 there moves it up the list).
Screen holder: VibeDesk sees every PreToolUse hook, so it knows when a session is calling a tool from a computer-use server. Marking "this one has the screen" and holding the others back until it's done sounds doable. I hadn't thought about two sessions fighting over the mouse, but it makes total sense for your setup.
MCP: in the current release (1.9) the desktop MCP only sees windows, layout and scenes. 2.0 comes out on Nov 1 and adds
desk_sessions(every session with its state: working, waiting for you, done) anddesk_session_send, so one session can hand a task to another one, e.g. "frontend is done, write the matching API in the backend".Thanks for opening the issue, and for the clear answer on the MCP side.
desk_session_send sounds like the interesting part. When frontend hands off to backend, does the receiving session get only the message text, or also something like the sender's last diff or a short state summary? That decides whether the backend session starts from context or from a cold prompt.
Right now it's only the message text. It lands in the other session exactly as if you had typed it, nothing else is attached.
To make that work, the tool description tells the sending Claude that the other session doesn't know its context and that it should write the task so it stands on its own (what changed, which files, what the API should look like). In practice Claude does that pretty well. The receiving session then reads the files itself, so it doesn't start completely cold, but it also doesn't get the sender's reasoning.
Attaching something like the sender's last diff or a short state summary is a good idea though. 2.0 also adds a wrap-up when a session finishes (summary + changed files), so handing that over together with the task would be the natural next step. I'll write it down.
Written down here, if you want to follow it: github.com/fxd-gif/vibedesk/issues/6
Thanks, that makes sense: a self-contained task plus the receiving session reading the files itself already covers most of it. Pairing the 2.0 wrap-up (summary + changed files) with the handoff sounds like the right next step. Following issue 6.
That "Do you want to run npm test?" sitting unseen for 15 minutes is exactly what pushed me to build something too: a Stream Deck where each key turns red when a session needs permission. Approving right from the card goes one step further than just pointing me at the window. Since you own the terminal, do you detect "waiting" from hooks or from the CLI output?
Hooks, not the output. I tried parsing the terminal first and it broke every time Claude Code changed its UI a little.
Every session VibeDesk starts gets its own settings file that sends all hook events (PermissionRequest, Notification, Stop, PreToolUse, ...) to a tiny forwarder. PermissionRequest is the useful one: the hook just stays open until you click Allow or Deny on the card (or on the phone), and the answer goes back as the hook result. Nothing has to "type y" into the terminal. Claude Code still shows its own prompt in the terminal while the hook waits, so you can answer in either place, and the card closes itself when the matching PostToolUse comes in.
A Stream Deck with red keys sounds great btw. Is it public somewhere? I'd love to see it.
That's a clever use of PermissionRequest: holding the hook open and returning the decision means nothing has to type into the terminal. I hadn't thought of answering from the device itself. On a Stream Deck that could be a long-press to allow. It isn't public yet, since the code is still tangled with my own setup, but there's a write-up here: dev.to/altair_alter/which-session-... and a short video of it running (Japanese, but the keys speak for themselves): youtube.com/watch?v=m7cUQ3Owqv0
A permission prompt in a window you aren't watching is a silent fifteen-minute stall.
Exactly, and the worst part is you don't even notice it. You come back, see it's still on step 2 and think the model is slow.
That's the one thing I wanted fixed first: a yellow dot on the card the moment a session waits, a small sound, and the same card on the phone so you can approve from the couch.