Repository navigation
Copilot Responses tool continuations emit ctc_call IDs rejected by the endpoint #64282
Description
Summary
Sandboxed engine: copilot workflows using a GPT model correctly route through the
OpenAI Responses API, but fail on the first tool continuation. Copilot CLI emits a
ctc_call_* tool-call ID and the Responses endpoint rejects it because it requires an
fc* ID.
400 Invalid 'input[8].id': 'ctc_call_…'. Expected an ID that begins with 'fc'.
This is distinct from the historical /chat/completions routing failures: the
Responses transport is selected successfully before this failure occurs.
Reproduction
- Run a strict, sandboxed
gh-awworkflow withengine.id: copilot,
copilot-requests: write, a GPT Responses-model, and an allowed file edit. - Let the agent read the file and issue its first
Edittool call. - The edit is reflected in the workspace, but the next continuation request fails
with the ID validation error above. Harness--continueretries replay the same
invalid ID and cannot recover.
Independent evidence
This reproduces across model and CLI-version variations:
| Model | Copilot CLI | Result |
|---|---|---|
copilot/gpt-5.3-codex |
default 1.0.87 |
Fails after the first permitted edit |
copilot/gpt-5.6-terra |
default 1.0.87 |
Fails after the first permitted edit |
copilot/gpt-5.6-terra |
explicitly pinned 1.0.90-2 |
Same failure |
Sanitized GitHub Actions evidence:
- https://github.com/ford-protech/ai-in-sdlc/actions/runs/36564085304
- https://github.com/ford-protech/ai-in-sdlc/actions/runs/36565809110
The failure also already occurred repeatedly in gh-aw's own PR Code Quality
Reviewer runs:
As a transport control, the same bounded remediation workflow ran successfully with
copilot/claude-opus-5: it used tools, created and validated the remediation patch,
and handed it to Safe Outputs without the ctc_call_* failure. Its later inability to
open a PR was an unrelated repository Actions policy restriction.
Expected behavior
A Copilot GPT model configured for the documented Responses wire API can execute a
file-edit tool call and one or more subsequent tool continuations in a sandboxed
gh-aw workflow.
Requested investigation
Please determine which integration component must preserve or normalize the tool-call
identifier at the Copilot CLI → AWF API proxy → Responses boundary. The issue should
not be addressed by forcing GPT models back to /chat/completions; recent routing work
correctly identifies Responses as the required transport for these models.
Suggested regression coverage
Add a sandboxed Copilot GPT Responses test that performs a file edit followed by a
second tool/action turn, and assert that the continuation succeeds rather than rejecting
a ctc_call_* ID.
Activity
anthonyhull-ford commentedon Sep 29, 2026
Resolved: the regression was caused by the consuming workflow pinning
gh-aw-firewallv0.28.23, which predates the exact compatibility fix in github/gh-aw-firewall#8944. That fix shipped in v0.28.25.Validated with a live sandboxed
copilot/gpt-5.6-terraworkflow after upgrading the generated lock togh-awv0.89.22 / AWF v0.28.25: the client emitted a replayedcustom_tool_call/apply_patchitem with actc_call_*ID, the workflow completed successfully, all 7 Responses calls returned HTTP 200, and the artifact contains noExpected an ID that begins with 'fc'or upstream-error record.The consumer branch now pins v0.28.25 across both checked-in agentic workflow locks. This was a stale firewall release-consumption issue, not a reason to route GPT models back to
/chat/completions.Live validation: https://github.com/ford-protech/ai-in-sdlc/actions/runs/36580873456