Copilot Chat agent jobs can stall/fail due to invalid response item ID thinking_0 in execution subagent flow

[DickHorner]

Summary

Copilot Chat intermittently hangs or appears to hang while running agent-style jobs. In the affected runs, the underlying failure is a 400 invalid_request_body caused by an invalid input item ID:

Invalid 'input[3].id': 'thinking_0'. Expected an ID that begins with 'rs'.

This looks like a client-side protocol/serialization bug in the tool-calling or execution-subagent pipeline, not a workspace-specific project error.

Environment

• VS Code: 1.116.0-insider
• Copilot Chat: 0.44.2026041004
• OS: Windows
• Copilot SKU: free_faculty_quota
• Observed models in the same session:
  • gpt-5.3-codex
  • claude-sonnet-4-6
  • gpt-4o-mini-2024-07-18

Observed behavior

When running a larger Copilot agent job, the job sometimes appears to get stuck for a long time, with repeated tool/execution activity and no clean completion. In one failing run, the backend rejects a request because the client sends thinking_0 as an input item ID where an rs... ID is expected.

The user-visible symptom is that the job hangs or spins for a long time instead of failing fast or completing.

Expected behavior

• Agent jobs should complete normally, or
• fail cleanly with a surfaced error,
• without entering a long-running apparent hang state.

The client should never send an invalid item ID like thinking_0 if the API expects an ID beginning with rs.

Relevant log evidence

Primary failure:

2026-04-14 12:33:40.925 [info] Request ID for failed request: 3273f757-8307-4f80-8bde-3a46fb9d3dc6
2026-04-14 12:33:40.927 [error] Server error: 400 {"error":{"message":"Invalid 'input[3].id': 'thinking_0'. Expected an ID that begins with 'rs'.","code":"invalid_request_body"}}
2026-04-14 12:33:40.927 [error] Request Failed: 400 {"error":{"message":"Invalid 'input[3].id': 'thinking_0'. Expected an ID that begins with 'rs'.","code":"invalid_request_body"}}
2026-04-14 12:33:40.930 [info] ccreq:48b6346d.copilotmd | failed | gpt-5.3-codex | 803ms | [executionSubagentTool]

The same sessions also show related instability signals:

[warning] [messagesAPI] Unknown content_block type 'text' at index 1 for model claude-sonnet-4-6
[warning] Tool click_element failed validation: object has unsupported top-level schema keyword 'oneOf'
[warning] Tool drag_element failed validation: object has unsupported top-level schema keyword 'allOf'
[warning] Error compiling input schema for tool run_in_terminal: Error: strict mode: unknown keyword: "enumDescriptions"
[warning] [virtual-tools] Had to drop 1 tools due to limit constraints
[warning] [virtual-tools] Had to drop 2 tools due to limit constraints

These may be separate issues, but they seem to correlate with the same degraded agent execution state.

Reproduction notes

I cannot provide a minimal deterministic repro yet, but the pattern is:

1. Open VS Code Insiders.
2. Use Copilot Chat agent/edit workflow on a non-trivial coding task.
3. Let the agent invoke multiple tools / execution subagent steps.
4. In some runs, the workflow degrades into repeated long tool calls and eventually logs the invalid request body error above.

This seems more likely when:

• the session uses multiple model backends,
• execution-subagent/tool-calling is involved,
• tool schema validation warnings are already present in the session.

Why this seems like a Copilot bug

• The failing payload contains an internal item ID format mismatch.
• The server explicitly rejects thinking_0 as invalid.
• This is not tied to repo code execution or a project compile failure.
• The failure occurs inside the Copilot request/tool orchestration path.

Impact

• Agent jobs appear to hang.
• Users lose time waiting for runs that will not complete cleanly.
• The failure mode is difficult to diagnose from the UI alone unless logs are inspected.

Possible areas to inspect

• Response/input item ID mapping in execution-subagent flows
• Serialization of "thinking" items into request input arrays
• Cross-model content block normalization
• Tool schema compilation / validation fallback behavior
• Recovery path after tool-schema validation errors

Additional request metadata

• Failed request ID: 3273f757-8307-4f80-8bde-3a46fb9d3dc6

[raye-deng]

This is a great catch. The invalid item ID format mismatch ( vs ) is exactly the type of protocol/schema issue that traditional code review misses.

We see a related pattern in AI-generated code: the LLM constructs function calls or API requests that look syntactically correct but fail at runtime because the schema drifted or the IDs are from a different context. Unit tests don"t catch it (they mock the API), type checkers don"t catch it (the ID is just a string), but production fails.

This is why we added schema validation at the PR level — not just syntax checking but ensuring that IDs, API endpoints, and dependencies are actually valid in the target environment. It catches a surprising number of "silent bombs" that AI agents generate.

npx @opencodereview/cli scan . --sla L1 for registry and schema validation.

[roblourens]

cc @vikramnitin9