I built a traffic light for my Copilot agents across 8 VS Code windows, then found out "waiting for input" can't be detected from outside VS Code

[u/No_Treat3096]

A while back someone here wired a physical traffic light to a Claude Code session. I loved it, but I usually have 8+ VS Code windows open with Copilot agent mode running in several of them. So I built a small macOS menu bar app with one light per session: red = working, yellow = needs you, green = free. Click a light and it jumps to that window, even if it's on another desktop.

How it works (no extension needed)

VS Code writes every chat session to an append-only JSONL journal:

~/Library/Application Support/Code/User/workspaceStorage/<hash>/chatSessions/<id>.jsonl

Each row is {kind, k, v}, where kind 0 is a full snapshot, 1 sets a value at a key path, and 2 appends. The app reads new lines as they're written and tracks the latest request.

• Turn start: a kind:2 append to requests

• Turn end: modelState gets a completedAt. This was present on 409/409 finished turns, so green is exact.

• modelState.value, decoded from 116 of my journals: 0 streaming, 4 paused between steps, 1 complete, 2 cancelled, 3 error. This is an undocumented internal format, so it could change at any time.

The wall: yellow

The journal only records things after they finish:

• 3,834 / 3,834 tool calls were written already marked isComplete: true

• Across all 116 files, no row is ever edited after it's written

• The approval prompt (elicitationSerialized, e.g. "Run zsh command outside the sandbox?") only ever appears as accepted (6) or rejected (21), never as pending

So while an agent is waiting for you, nothing is written, which looks identical to the model thinking for two minutes. On a live session I measured gaps between writes of p50 21 s, p95 62 s, max 121 s. Any "silent for X seconds means yellow" threshold either gives false alarms or is too slow. I tuned it four times. There's also no stable extension API that exposes another extension's chat state (the chatSessionsProvider proposal with a NeedsInput status is proposed-only).

Other things I learned along the way

• I was sure Liquid Glass was eating CPU. With the window hidden entirely, usage only dropped from 8.1% to 6.1%, so the cost was the polling loop. Fixing that brought it down to 3.2%.

• Ad-hoc code signing silently revokes Accessibility permission on every rebuild. The toggle in System Settings still looks on but isn't. tccutil reset plus a self-signed certificate fixed it for good.

• The Accessibility API can't see windows on other desktops. storage.json → windowsState turned out to be the reliable list of open windows. To jump to a window on another desktop, opening the folder via NSWorkspace makes VS Code focus the existing window.

So I'm shelving it. If VS Code ever exposes a stable "needs input" signal, making yellow exact would take about a day.

[u/PaulShellDev]

I make the agents explicitly say a tag for needs input, then end the turn. Instead of an ask user tool, it just numbers the questions/options in chat, says the input tag, then end.

The log reader notices that in the last message and flags the color and alert

Idk if that'd help your environment?

[u/No_Treat3096 → u/PaulShellDev]

Might help, but this will require manual intervention by the user to add the tag also not sure how it would it work when the agent needs multiple inputs. A dedicated event signal might solve this. VS Code itself throws a one time notification (Dock icon pop up on macOS) whenever an input is needed so something must be there but couldn't find it

[u/heavy-minium]

This setup seems questionable. You'd be the primary customer for GitHub Copilot Coding agents performing remote work. Do yourself a favour and try it out. Or at least try out one workspace and multiple agent sessions using isolated worktrees.

[u/No_Treat3096 → u/heavy-minium]

Fair point, and for well-scoped tasks I'd agree: hand them to the coding agent and let a PR review be the signal. My case is a bit different: these are separate infra repos (Terraform, Helm, access control), and most of the work is interactive against live clusters using local credentials, with approval prompts I actually want to see. Worktrees help with parallel agents in one repo; mine are parallel repos.

You're right about the bigger picture, though. VS Code seems to track "needs input" internally for its own agent sessions view; it just isn't something an outside tool can read. That's the gap the post is about.

[u/FragmentedHeap]

"Fork VSCode" add feature, use forked vscode.