[awf] copilot-harness: GPT-5.4 edit tool fails with null tool_call type (400 error)

[lpcox]

Problem

When running agentic workflows with GPT-5.4 via copilot-cli, the edit tool triggers a 400 error: Invalid type for 'messages[N].tool_calls[N].type': expected one of 'function', 'alltools', or 'custom', but got null. This causes repeated retries and workflow failure. The same workflow succeeds with Claude Sonnet 4.6.

Context

Reported in gh-aw#31695. Introduced between v0.68.3 (working) and v0.71.5 (broken), also reproduced on v0.72.1. The isNullTypeToolCallError=true flag is detected by the harness, which discards history and retries fresh — but the retry also fails identically.

Root Cause

The OpenAI API response (or the Copilot proxy layer) is returning a tool_calls[].type field as null instead of the required string "function". This corrupted history is then sent in subsequent requests, causing the 400. Likely a serialization bug in the Copilot CLI when constructing multi-turn conversation history for GPT-5.4.

Proposed Solution

1. In copilot-harness, sanitize outgoing message history before each API call: strip or normalize any tool_calls entries where type is null.
2. Investigate whether the null value originates from the Copilot proxy (server-side) or from the CLI's local message history serialization.
3. Add a regression test with a mocked 400 response to cover this null-type code path.

Generated by Firewall Issue Dispatcher · ● 13.3M · ◷