Agent Host: Copilot chat remains in progress when SDK queue processing loses a resumed session

[ulugbekna]

• Copilot Chat Extension Version: N/A — built-in Agent Host Copilot provider; exported session reports Copilot runtime version 1.0.73
• VS Code Version: 1.134.0-insider (0f3c3b53028901b912211a99b23232b76017bcfc)
• OS Version: macOS 26.6.1 (arm64)
• Feature (e.g. agent/edit/ask mode): Agents Window → local Agent Host → Copilot session, interactive mode
• Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): GPT-5.6 Sol (gpt-5.6-sol)
• Logs: Exported Agent Host Debug Logs were analyzed locally. The bundle is not attached because it contains prompts, paths, and other sensitive data; sanitized excerpts and correlation IDs are included below.

Steps to Reproduce:

1. Open an existing local Agent Host Copilot chat whose SDK backing session must be resumed.
2. Complete a turn successfully in the resumed session.
3. Send another request after the SDK has lost the resumed session from its live session registry.
4. Observe that the request remains in progress indefinitely. Cancelling and retrying, or reloading the window, recreates/reconnects to another empty active turn instead of surfacing an error.

Expected behavior

If the SDK cannot process the queued request because the backing session no longer exists, one of the following should happen:

• session.send() rejects and Agent Host recovers by invalidating and resuming the stale cached session; or
• the SDK emits a terminal error/idle event for the turn, allowing AHP and the chat UI to leave the in-progress state.

The user should receive a visible error or an automatic retry, not an indefinitely spinning response.

Actual behavior

CopilotAgentSession.send() awaits the SDK's session.send() call, which resolves successfully. The SDK then fails asynchronous queue processing with Session not found, abandons the queue drain, and emits no assistant event, usage, error, or idle event for the request.

Because no terminal AHP action is produced, ChatState.activeTurn remains populated and its status remains SessionStatus.InProgress. On window reload, AgentHostSessionHandler correctly hydrates that stale activeTurn as a pending chat request, making the chat appear active forever.

The stuck active turn had:

• status 8 (SessionStatus.InProgress)
• zero response parts
• no usage record
• no subsequent protocol progress action

Correlated timeline

All timestamps below are UTC on 2026-08-14.

• 15:54:22 — the previous live SDK session 3ae7e60d… is closed as part of a configuration refresh.

• 15:54:33 — that same SDK session ID is resumed.

• 15:54:41 — session.send() returns for a request.

• 15:55:04 — the response completes normally and the SDK emits idle.

• 15:58:34.244 — the next session.send() returns, but the SDK immediately logs:

  Scheduled queue processing failed; retrying once: Request session.queue.process failed with message: Session not found for sessionId: 3ae7e60d…
  Scheduled queue processing failed after retry; queue drain abandoned: Request session.queue.process failed with message: Session not found for sessionId: 3ae7e60d…
  

  No turn-start, response, usage, error, or idle event follows.

• 16:10:26 — the user cancels the stuck turn.

• 16:10:31.049 — retrying produces the same two session.queue.process failures.

• 16:10:33 — the user cancels again.

• 16:10:37.806 — a second retry produces the same failures.

• 16:10:45 — a newly connected client receives an AHP snapshot containing active turn request_98fcc60c…, started at 16:10:37.440, with no response parts or usage.

• 16:10:46 — the renderer logs that it is reconnecting to that active turn.

• 16:11:43 — cancelling the reconnected turn finally dispatches chat/turnCancelled and changes the chat status back to idle, but the cached SDK session remains stale for future sends.

Relevant code paths

• src/vs/platform/agentHost/node/copilot/copilotAgentSession.ts
  • send() treats resolution of _wrapper.session.send(...) as success.
  • The later SDK queue-processing failure is not observable here.
• src/vs/platform/agentHost/common/state/protocol/channels-chat/reducer.ts
  • Any activeTurn derives SessionStatus.InProgress until chat/turnComplete, chat/turnCancelled, or chat/error arrives.
• src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionHandler.ts
  • Restore correctly converts sessionState.activeTurn into pending request/response history and reconnects to it.
• src/vs/platform/agentHost/node/agentSideEffects.ts
  • Client cancellation finalizes the protocol turn and asynchronously aborts the provider session, but does not invalidate the stale cached Copilot SDK session.

Suspected root cause

The Copilot SDK's queued-send API has split success semantics: session.send() resolves after scheduling work, while session.queue.process can fail asynchronously without propagating the failure or emitting a terminal session event. Agent Host therefore cannot distinguish a successfully scheduled request from an abandoned queue drain and retains an orphaned AHP active turn.

The SDK also appears to have lost a recently resumed session from its live registry without a corresponding close/destroy event after its last successful response.

Suggested fix direction

1. Have the Copilot SDK propagate queue-processing failure to the initiating send() call, or emit a turn/session error followed by idle.
2. In Agent Host, invalidate and resume a cached CopilotAgentSession when the SDK reports that its session no longer exists.
3. Consider a defensive pending-turn watchdog: if a send produces no first SDK event and no terminal event, fail the AHP turn rather than preserving it indefinitely.
4. Ensure cancel/retry cannot reuse a known-stale SDK session after abort fails to drive the SDK to idle.

Impact and workaround

The UI remains indefinitely busy, retries repeat the failure, and a window reload reconnects to the orphaned turn. The reliable workaround is Developer: Restart Local Agent Host, which clears the stale in-memory SDK wrapper before the session is used again.

[connor4312]

I had my agent build a POC against the SDK that exhibited this behavior, and it was able to repro, but it looks like this is already fixed in the runtime main where stuff got ported to Rust and cleaned up a bit. Identified SDK fix: github/copilot-sdk#2336