- Copilot Chat Extension Version: Agent Host / Copilot CLI 1.0.73
- VS Code Version: Code - Insiders build from 2026-07-28 (exact product version was not captured in the exported bundle)
- OS Version: macOS
- Feature (e.g. agent/edit/ask mode): Agents window / Agent Host multi-chat (
create_chat)
- Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): Claude Opus 4.8
- Logs: Agent Host debug export captured on 2026-07-28. The bundle contains sensitive session content and can be shared privately if needed.
Steps to Reproduce:
- Start an Agent Host session and let it become idle. Navigate away or otherwise remove its last subscription so
AgentService evicts its in-memory session state while preserving the durable backend session.
- From another active Agent Host session, invoke the
create_chat server tool targeting the evicted session returned by list_sessions.
- Observe that the provider creates the peer SDK session and the initial prompt is sent, but the peer chat never receives usable protocol state. A permission-requiring tool makes the hang especially clear.
Expected:
The target parent session is restored before the peer chat is created and registered. The first turn starts only after the chat has authoritative state, and any permission request is delivered to the client.
Actual:
The peer SDK session is created, but AgentHostStateManager.addChat() drops registration because the parent session is absent. The first turn is then dispatched and sent against an unknown chat. Progress and permission actions are dropped, leaving the SDK blocked on an unresolved permission request and the UI stuck.
Observed timeline from the debug bundle:
- The target parent session was evicted after its last unsubscribe.
- Roughly 20 seconds later,
create_chat logged Created additional chat ... in session ....
- This was immediately followed by
addChat for unknown session, Action for unknown chat ... chat/turnStarted, and Turn started for session not in state manager.
- The peer SDK session later logged
Requesting confirmation for tool call, but no permission response was ever recorded.
- Restoring the parent reconstructed the peer turn as cancelled/idle, while retries reached
session.send() returned but produced no subsequent assistant events.
Root cause on latest main:
As of 0d66fdd49d0ecc3b2dcdd8ac0dfff9d41215d4fc (2026-08-06), the race remains:
applyCreateChatTool() calls listSessions() and validates durable metadata, but does not materialize the selected session.
AgentService.createChat() invokes the provider without first calling restoreSession() when parent state is absent.
- The provider successfully creates the backing chat.
AgentHostStateManager.addChat() logs and returns undefined for the unknown parent; the failure is ignored.
_startSessionPrompt() still dispatches ChatTurnStarted and routes the prompt to the provider against the unregistered chat.
The lazy peer-chat restoration work in aa23e75a7ae does not cover creation against an evicted parent. Existing createChat tests restore the parent explicitly before creating the peer chat, so this path has no regression coverage.
Suggested fix:
- Restore/materialize the parent session before provider chat creation when it is absent from the state manager.
- Treat failed chat registration as an error and dispose the newly-created provider backing instead of persisting/sending against it.
- Add a regression test that deletes/evicts parent state, calls
createChat() directly without an explicit restore, starts the prompt, and verifies chat registration plus permission delivery.
create_chat)Steps to Reproduce:
AgentServiceevicts its in-memory session state while preserving the durable backend session.create_chatserver tool targeting the evicted session returned bylist_sessions.Expected:
The target parent session is restored before the peer chat is created and registered. The first turn starts only after the chat has authoritative state, and any permission request is delivered to the client.
Actual:
The peer SDK session is created, but
AgentHostStateManager.addChat()drops registration because the parent session is absent. The first turn is then dispatched and sent against an unknown chat. Progress and permission actions are dropped, leaving the SDK blocked on an unresolved permission request and the UI stuck.Observed timeline from the debug bundle:
create_chatloggedCreated additional chat ... in session ....addChat for unknown session,Action for unknown chat ... chat/turnStarted, andTurn started for session not in state manager.Requesting confirmation for tool call, but no permission response was ever recorded.session.send() returnedbut produced no subsequent assistant events.Root cause on latest
main:As of
0d66fdd49d0ecc3b2dcdd8ac0dfff9d41215d4fc(2026-08-06), the race remains:applyCreateChatTool()callslistSessions()and validates durable metadata, but does not materialize the selected session.AgentService.createChat()invokes the provider without first callingrestoreSession()when parent state is absent.AgentHostStateManager.addChat()logs and returnsundefinedfor the unknown parent; the failure is ignored._startSessionPrompt()still dispatchesChatTurnStartedand routes the prompt to the provider against the unregistered chat.The lazy peer-chat restoration work in
aa23e75a7aedoes not cover creation against an evicted parent. ExistingcreateChattests restore the parent explicitly before creating the peer chat, so this path has no regression coverage.Suggested fix:
createChat()directly without an explicit restore, starts the prompt, and verifies chat registration plus permission delivery.