Agent Host client tool hangs after active client removal; browser click invoked with empty args

[digitarald]

Summary

A browser clickElement tool call can get stuck in Preparing after the Agent Host removes the active client. The click never reaches Playwright; the workbench invokes the browser tool with {} parameters and crashes during tool preparation.

Observed

In an Agents/Copilot CLI session using built-in browser tools:

1. openBrowserPage succeeds.
2. clickElement on the initial Start button succeeds.
3. screenshotPage succeeds.
4. The next clickElement on the board's Run button stays stuck at Preparing.

The session event stream ends with:

tool.execution_start clickElement
permission.requested clickElement
# no permission.completed
# no tool.execution_complete

Key log evidence

The model requested valid arguments:

{
  "element": "Run button on Research Agent",
  "pageId": "<page-id>",
  "ref": "e200"
}

But the workbench invoked the underlying browser tool with empty parameters:

[AgentHost] Invoking client tool: clickElement
[LanguageModelToolsService#invokeTool] Invoking tool click_element with parameters {}
[error] Cannot read properties of undefined (reading 'toString')
    at createBrowserPageLink(...)
    at ClickBrowserTool.prepareToolInvocation(...)

The AHP sequence for the same tool call was:

chat/toolCallStart clickElement
chat/toolCallReady confirmed="not-needed"           # no toolInput
chat/toolCallComplete success=false error="Client <client-id> disconnected before completing clickElement"
chat/toolCallReady confirmation UI with real toolInput

About 6 seconds earlier, the same session received:

session/activeClientRemoved clientId=<client-id>

Suspected cause

This looks like an Agent Host/client-tool lifecycle race:

• The active client is removed from session state while the UI/client connection is still participating in the turn.
• A later client-contributed browser tool call is treated as orphaned/disconnected.
• The synthetic toolCallReady without toolInput is consumed by the workbench client-tool handler.
• The handler falls back to {} and invokes click_element before the later toolCallReady containing the real toolInput arrives.
• ClickBrowserTool.prepareToolInvocation assumes pageId is present, calls createBrowserPageLink(undefined), throws, and the original Copilot tool execution remains stuck waiting for completion/permission state.

Relevant code paths:

• src/vs/platform/agentHost/node/protocolServerHandler.ts
  • disconnected client tool call handling emits synthetic ready/complete events
• src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionHandler.ts
  • missing toolInput falls back to {} once status is not Streaming
• src/vs/workbench/contrib/browserView/electron-browser/tools/clickBrowserTool.ts
  • prepareToolInvocation assumes pageId is defined

Expected

A disconnected/orphaned client-tool call should fail cleanly and unblock the model/UI, or be retried with a replacement active client. It should not invoke the local browser tool with {} parameters or leave the tool call stuck in Preparing.

Possible fixes

• Do not invoke client tools from toolCallReady events that lack toolInput when the tool has required arguments or _meta.toolArguments exists.
• Ensure disconnected-client synthetic toolCallReady/toolCallComplete ordering cannot race with later confirmation UI events for the same tool call.
• Harden browser tool prepareToolInvocation against missing pageId so malformed protocol state becomes a clean tool error.
• Investigate why session/activeClientRemoved fired while the client was still successfully confirming/completing tool calls in the same session.

[RyanEwen]

Seeing this too, and I think I can add one useful data point: for me it only happens in remote windows. The same repo, same client, same request works in a local window and hangs in both WSL Remote and Dev Containers.

Window	Result
Local Windows folder	works
WSL Remote	hangs
Dev Container (compose)	hangs

Environment: VS Code 1.133.0 stable and Insiders (both affected), Windows arm64 client, WSL2 Ubuntu, Docker Desktop. Copilot Chat with the Claude harness. The Anthropic Claude Code extension is not installed, so this reproduces with no third-party chat extension involved.

Symptom matches the report: the first browser tool call succeeds, then the turn never completes. In my case there is no error at all, the agent host log simply stops:

[AgentSideEffects] Forwarding client tool completion: source=server-envelope, session=claude:/<id>
[AgentSideEffects] Forwarding client tool completion: source=client-dispatch, session=claude:/<id>
   (nothing further - no error, no timeout)

Consistent with the activeClientRemoved lifecycle race in the report, I also see client/session state desync in the same sessions:

[AgentHostStateManager] Action for unknown session: claude:/<id>, type=session/metaChanged
[AgentSideEffects] sendMessage failed for session=ahp-chat://default/<b64>: code=undefined, message=Canceled: Canceled, type=Canceled

Two sessions get created seconds apart and the older one is then unknown to the agent host.

Possibly related, and remote-specific: every session in a remote window logs a pair of file-watcher failures on the workspace URI, which never occur locally:

CodeExpectedError: ENOPRO: No file system provider found for resource
  'vscode-remote://dev-container%2B<hex>/workspace/<repo>'
    at Ms.withProvider (.../agentHostMain.js)
    at async Ms.doWatch (.../agentHostMain.js)

The same URI also fails for <workspace>/.claude. In the same remote windows, chat session history never lists, which may be the same root cause and looks like #328736.

Ruled out by experiment, in case it saves anyone time:

• MCP servers: rebuilt with zero MCP servers registered (verified in the MCP Servers view) and it still hangs.
• File checkpointing: setting fileCheckpointingEnabled: false did not help and made it hang earlier.
• Auth/models: healthy throughout, [Claude] Models refreshed (merged). Count: 4.
• Agent SDK download: cache warm, no download during the failing turns.

Happy to gather more logs or run a specific build if that helps.

[RyanEwen]

Root cause found, with a reliable reproduction rule and instrumented evidence. Correcting the "suspected cause" in the original report: the active-client removal is incidental, not the trigger.

Reproduction rule

With a client-contributed tool (the built-in browser tools), in a dev container (remote) window:

Permission path	Result
Approved inline in the chat	works, turn continues
Approved in the confirm dialog	stalls
Auto-approved (auto mode / not-needed)	stalls

The confirm dialog involves the same human delay as the inline prompt and still stalls, so this is not a timing race. What matters is which side owns the call.

Mechanism

A client tool call produces two chat/toolCallReady events: one from the stream mapper at content_block_stop, and one from the SDK permission flow (carries confirmationTitle).

When permission is requested inline, the SDK has genuinely invoked the tool, so its in-process MCP handler is registered and waiting. The result is delivered and the turn continues.

When no permission is requested, only the stream-mapper ready exists. The workbench executes the tool anyway and reports chat/toolCallComplete, but the SDK never invoked it, so nothing is waiting for the result. ClaudeAgentSession.completeClientToolCall calls PendingRequestRegistry.respond, which drops a result with no registered entry, and the turn waits forever for a call the model's runtime never made.

Evidence

Probe on completeClientToolCall, logging whether the id matched a registered handler, alongside every id passed to register():

STALLED  id=toolu_01EQdcdF...  matched=false
         registered=["toolu_01UUfx...","toolu_0161bL...","toolu_011Pmh..."]
         (the id is absent, and never appears in any later line)

WORKED   id=toolu_015SZeT...   matched=true
         registered=[...,"toolu_015SZeTNzfwyZtXqcYGe8NTd"]

The stalled id is never registered, before or after. Confirmed across many runs: matched=true implies the turn continues, matched=false (for a client tool result) implies it parks.

AHP sequences for the two cases:

WORKED   toolCallReady  confirmationTitle=yes  -> inputNeededSet -> confirmed=user-action -> complete (matched)
STALLED  toolCallReady  confirmationTitle=no   -> confirmed=not-needed -> complete (dropped)

Ruled out by experiment

• Empty tool-result content. Real and worth fixing separately (the workbench sends {success:false, error:{message}} with no content, and convertToolCallResult reads only content, so the model receives an empty result, see Surface a client tool's error when it returns no content #330709), but patching it did not affect the stall.
• Buffering the result (respondOrBuffer instead of respond). Cannot help, because _earlyResults is only collected by register(), which is never called for the stalled id.
• Active client removal. Appears in only one of the stalled runs.
• Duplicate client tool invocation (Do not run a client tool twice when a tool call is readied twice #330683). Fixed separately and verified; the stall reproduces with exactly one invocation.

Why remote-specific

On a local window the same client tools work. The stall needs the workbench to execute off the stream-mapper ready without an SDK invocation, which is far more likely when the client tool round trip crosses the websocket transport used by a remote window.

Suggested direction

A client-contributed tool should not execute until the agent host has a pending invocation for that tool call. The stream-mapper ready is enough to render the call, but not to run it.

[RyanEwen]

Correction to my previous comment, and a fix: #330730.

I claimed the SDK "has no record of the call at all" and that the workbench executes a tool the SDK never invokes. That was wrong. The SDK does invoke the tool and register its handler, just after the workbench has already finished the tool and reported the result.

The instrumentation that showed this: logging every id passed to PendingRequestRegistry.register alongside each completion.

stalled  id=toolu_01EQdcdF...  matched=false  registered=[...]
         (the id is absent when the result arrives, and present seconds later)

So the sequence is:

1. The workbench starts the client tool from the streamed tool call (content_block_stop ready) and finishes it in milliseconds.
2. ClaudeAgentSession.completeClientToolCall calls respond, which drops a result nothing is parked on.
3. The SDK invokes the tool and registers its handler moments later.
4. That handler waits forever for a result that was already discarded.

CopilotAgentSession already uses respondOrBuffer on the same path, so it survives the same ordering. The fix brings Claude in line.

This also explains the permission split reported above without needing a separate mechanism: auto-approval leaves nothing to delay the workbench so it always loses the race, while approving inline in the chat usually gives the SDK enough time to register first.

Two things in my earlier comments that remain correct: the active client removal is incidental, and the empty tool-result content is a real but separate defect (#330709).

Verified live on 1.133.0 with the change patched into a running agent host: auto mode recovered from a failed browser tool, reported the cause, and completed the turn.