BYOK Responses API path does not stream `apply_patch` argument deltas to the tool UI

Type: Bug

Summary

When using the BYOK / OpenAI-compatible Responses API path in VS Code Copilot, streaming tool-call argument deltas for apply_patch appear to be received by the endpoint stream, but they are not reflected in the tool UI until the final response.output_item.done event arrives.

This makes apply_patch look buffered: the patch generation UI does not update incrementally, and the file-edit tool only appears to start once the full arguments payload is complete.

This seems specific to the BYOK / Responses API path. The upstream SSE stream contains both:

• response.output_item.added
• response.function_call_arguments.delta
• response.function_call_arguments.done
• response.output_item.done

but the incremental argument stream does not seem to reach the pending tool invocation / handleToolStream path for apply_patch.

Expected behavior

For a streamed apply_patch function call, VS Code should:

1. Receive response.output_item.added for the function_call.
2. Start a pending tool invocation for apply_patch.
3. Accumulate response.function_call_arguments.delta events by output_index and/or item_id.
4. Forward partial arguments to the tool stream UI.
5. Call ApplyPatchTool.handleToolStream(...) with partial raw input so the UI can update while the patch is being generated.
6. Invoke the tool normally after response.output_item.done.

The actual file edit can still happen after the patch is complete. The issue is that the streaming UI is not updated during argument generation.

Actual behavior

The BYOK / Responses API stream forwards argument deltas, but the UI remains effectively buffered until the final completed tool call arrives.

Observed behavior:

• response.function_call_arguments.delta events are streamed continuously.
• The deltas include output_index and item_id.
• The final response.output_item.done contains item.type = "function_call", item.name = "apply_patch", call_id, and the full completed arguments.
• The apply_patch UI does not appear to receive incremental raw input before the final output_item.done.

Reproduction outline

Use a BYOK / OpenAI-compatible /v1/responses endpoint that forwards Responses API SSE events unchanged.

Trigger an agent edit that uses apply_patch.

The stream contains events shaped like this:

{
  "type": "response.output_item.added",
  "output_index": 4,
  "item": {
    "id": "fc_...",
    "type": "function_call",
    "status": "in_progress",
    "call_id": "call_...",
    "name": "apply_patch",
    "arguments": ""
  }
}

followed by many events like:

{
  "type": "response.function_call_arguments.delta",
  "output_index": 4,
  "item_id": "fc_...",
  "delta": "..."
}

and then:

{
  "type": "response.function_call_arguments.done",
  "output_index": 4,
  "item_id": "fc_...",
  "arguments": "{...full arguments...}"
}

and finally:

{
  "type": "response.output_item.done",
  "output_index": 4,
  "item": {
    "id": "fc_...",
    "type": "function_call",
    "call_id": "call_...",
    "name": "apply_patch",
    "arguments": "{...full arguments...}"
  }
}

Despite the delta events being present, the visible apply_patch tool UI behaves as if the arguments were only available at the final response.output_item.done.

Suspected cause

The Responses API processor appears intended to support this flow:

• response.output_item.added stores tool call state by output_index
• response.function_call_arguments.delta appends to the stored arguments
• it emits copilotToolCallStreamUpdates
• response.output_item.done emits the completed copilotToolCalls

However, in the BYOK path, the incremental copilotToolCallStreamUpdates do not appear to be connected to the pending VS Code tool invocation update path for apply_patch.

The suspected break is somewhere between:

OpenAIResponsesProcessor.push()
  -> IResponseDelta.copilotToolCallStreamUpdates
  -> chat stream adapter
  -> LanguageModelToolsService.updateToolStream(...)
  -> ApplyPatchTool.handleToolStream(...)

Possible failure points:

1. beginToolCalls is not creating a pending tool invocation for apply_patch in the BYOK path.
2. copilotToolCallStreamUpdates are being dropped or ignored.
3. updateToolStream(...) is not called for streamed BYOK Responses API function-call argument deltas.
4. updateToolStream(...) is called, but the partial raw input shape is not compatible with ApplyPatchTool.handleToolStream(...).
5. The implementation only handles the final copilotToolCalls event and not the streaming update event.

Why this matters

For large patches, this makes the tool appear frozen or buffered even though the model is actively streaming apply_patch arguments. The final edit succeeds, but the UX differs from the native Copilot path where tool generation progress is visible.

Relevant areas to inspect

Likely relevant code paths:

• extensions/copilot/src/platform/endpoint/node/responsesApi.ts

  • OpenAIResponsesProcessor
  • response.output_item.added
  • response.function_call_arguments.delta
  • copilotToolCallStreamUpdates

• src/vs/workbench/contrib/chat/browser/tools/languageModelToolsService.ts

  • beginToolCall(...)
  • updateToolStream(...)

• extensions/copilot/src/extension/tools/node/applyPatchTool.tsx

  • ApplyPatchTool.handleToolStream(...)

Additional notes

This does not appear to be caused by the proxy endpoint buffering SSE chunks. The proxy logs show response.function_call_arguments.delta events being received and forwarded continuously before the final response.output_item.done.

The issue appears to be that the BYOK / Responses API path does not propagate these streamed argument deltas into the VS Code pending tool invocation UI for apply_patch.

VS Code version: Code - Insiders 1.125.0-insider (8f1df1b21594e1b5a1453388c028256f2d851f0d, 2026-06-12T08:56:22Z)
OS version: Windows_NT x64 10.0.26200
Modes:

vsliv368cf:30146710
pythonvspyt551:31249597
nativeloc1:31118317
dwcopilot:31158714
dwoutputs:31242946
copilot_t_ci:31333650
g012b348:31231168
pythonrdcb7:31268811
pythonpcpt1cf:31399617
6518g693:31302842
82j33506:31327384
6abeh943:31336334
envsactivate1:31349248
editstats-enabled:31346256
cloudbuttont:31366566
3efgi100_wstrepl:31403338
cp_cls_t_966_ss:31526232
4je02754:31455664
8hhj4413:31478653
ge8j1254_inline_auto_hint_haiku:31490507
cp_cls_c_1081:31454833
conptydll_true:31485575
ia-use-proxy-models-svc:31446143
e9c30283:31453065
test_treatment2:31471001
c9b86496:31447327
idci7584:31454084
e3e4d672:31454087
ei9d7968:31462942
nes-extended-on:31455475
89g7j272:31506658
7e884298:31462391
7e187181:31482583
i2gc6536:31472020
52612955:31508042
h08i8180:31475367
23c7c724:31520045
ddid_c:31478205
hmra_i5g22:31518061
ja75b849:31531032
61f49681:31505879
7df3h592:31491241
pro_large_t:31499377
cp_cls_t_1082:31516087
logging_enabled_new:31490725
jb_cp_cls_t_632:31524805
32d76977:31503652
ha629193:31508444
cdk-lw-on:31524445
f9bf7985:31531254
31fi7170_t:31517328
jh5f2457_c:31531021
api_cot_ctrl:31509853
hgf2d445:31510900
prpt_ctrl:31513638
jbcp_cls_pctr_t:31531130
gf14b233:31526830
nes-curr-leftover-1000:31527876
h561g132:31531234