Resumed session retains stale connection item IDs after interrupted response

Describe the bug

After reopening and resuming an existing Copilot CLI session, every prompt fails with:

Execution failed: CAPIError: 400 input item ID does not belong to this connection

The affected session does not recover after retrying. Forking it with /fork also does not help: prompts in the fork fail with the same error. A separate new Copilot CLI session works normally.

This appears to be a regression of #2147, which was closed as fixed in v1.0.10. The reported root cause there was stale WebSocket state being reused after a reconnection.

Affected version

GitHub Copilot CLI 1.0.81-0

Steps to reproduce the behavior

I am not certain of the exact trigger, but the likely sequence was:

1. Use an existing Copilot CLI session normally.

2. Exit or close the CLI while the agent is about to respond or while a response is in progress.

3. Reopen Copilot CLI and resume the existing session.

4. Enter a prompt such as continue.

5. Observe:

   Execution failed: CAPIError: 400 input item ID does not belong to this connection
   (Request ID: 00000-ed11ed35-1761-4d58-95f1-7f22a29c4556)
   

6. Retry the prompt and receive the same error with a new request ID:

   Execution failed: CAPIError: 400 input item ID does not belong to this connection
   (Request ID: 00000-b4c9a489-fc2f-4b5f-921f-13a2e409f386)
   

7. Run /fork and try another prompt in the fork. The error persists.

8. Start a separate new session. The new session works normally.

Expected behavior

Copilot CLI should discard or reconstruct connection-bound response state after reconnecting. An interrupted response should not permanently make a persisted session, or a fork of that session, unusable.

Additional context

• Operating system: Windows
• CPU architecture: ARM64
• Shell: PowerShell 7
• The original session log shows the old Copilot process shutting down and cleaning up the persisted session before it was reopened.
• The failure is isolated to the affected conversation and forks made from it.
• Restarting/reconnecting and retrying do not recover the conversation.
• A comment on #2147 reports the same failure on v1.0.79-4, suggesting the issue may have regressed before v1.0.81-0.
• I have not attached the complete session log because it contains conversation and tool history.

Investigated and filed with assistance from GitHub Copilot CLI.

未指定源文件或测试。首先跟踪持久化会话的恢复/重新连接流程，包括 /fork 路径以及中断响应后的清理；使用报告中的复现步骤和会话日志上下文，定位被复用的连接绑定状态。完成标准是恢复的会话及其 fork 不再因 stale input item ID error 失败，同时新会话继续正常工作。