Intermittent 400 internal server error on response continuation after tool output #5116

Describe the bug

Copilot CLI intermittently terminates an otherwise healthy multi-step session with:

Execution failed: 400 internal server error

The failure occurs while submitting a continuation through the Responses API using previous_response_id. In the latest occurrence, the continuation contained a successful function_call_output with its matching call ID. More than 30 model/tool continuations had succeeded on the same WebSocket request chain before the service returned a structured HTTP 400.

The CLI debug log records only the response shape because the body is intentionally omitted:

Upstream model error response shape (body content omitted)
{"status":400,"body_bytes":100,"json_body":true,"structured_error":true,"error_details":false}

The command/tool itself completed successfully; the 400 happened when its result was sent back to the model. The failure arrived about 3.2 seconds after the continuation was submitted.

Latest occurrence:

• Request ID: 00000-d3a14fa6-0cf2-4f16-ac6e-5530303b8b7e
• UTC timestamp: 2026-10-11T20:27:07.911Z
• Model: gpt-6-astra
• Continuation input: function_call_output
• Previous successful response usage: 119,430 total tokens

I found 12 structured HTTP-400 responses in local logs from October 9-11. Eight were user-visible interactive failures sharing the continuation-state pattern; six of the previous seven occurred directly after successful tool output, and one occurred on a new message against an existing previous_response_id. The latest occurrence is another tool-output continuation failure.

The interactive failures span multiple sessions and both gpt-5.6-sol and gpt-6-astra. Previous successful response sizes ranged from about 58k to 126k total tokens, so context pressure may increase the likelihood but a simple fixed context-limit threshold does not explain all occurrences.

Interactive request IDs available for server-side correlation:

• 00000-d3a14fa6-0cf2-4f16-ac6e-5530303b8b7e
• 00000-cbbe8d72-559c-4457-a7f4-6917f8a850f4
• 00000-80fa7038-2b72-4c4f-8034-1dc5cd011ab3
• 00000-d72f71c9-e14e-4904-97d7-821e46c013cc
• 00000-1cf1c521-7da1-4bab-adc2-77fc6fd8e8ba
• 00000-1c0b4648-3361-49f8-8963-618aa514981c
• 00000-e3ef89e6-a120-4790-91ed-9a2a2c5be492
• 00000-89a14090-5f54-4706-9661-8422d4b867ef

Authentication remains valid, TLS/WebSocket setup succeeds, and successful model calls occur immediately before each failure. No custom COPILOT_PROVIDER_* or COPILOT_MODEL configuration is present. GitHub Status showed Copilot and its model providers operational during the latest occurrences.

This appears distinct from #2171 and #2859, which report generic CAPI 400 failures without the repeated mid-chain continuation signature, and from #4946, which has an explicit DeepSeek thinking-block validation error.

Affected version

GitHub Copilot CLI 1.0.95

Steps to reproduce the behavior

The issue is intermittent rather than deterministic:

1. Start an interactive Copilot CLI session using the default GitHub-hosted provider.
2. Run a long, multi-step task that invokes tools and sends their results back to the model.
3. Observe many successful model/tool continuations.
4. Eventually, submission of a successful tool result using previous_response_id may terminate with Execution failed: 400 internal server error.
5. Retrying in a new turn or starting a new/forked session generally recovers.

Expected behavior

A valid tool result should continue the existing response chain. If the server-side continuation state is no longer usable, the CLI should recover by starting a new response chain or return a specific actionable validation error rather than a terminal generic internal-server-error message.

Additional context

• OS: Windows x64
• Shell: PowerShell
• Provider: standard GitHub Copilot service, not BYOK
• Current release: 1.0.95
• The same 100-byte structured error body is returned across the interactive occurrences.
• Full debug logs are available privately if GitHub staff need them; they are not attached because they contain prompts and repository content.