Repository navigation
Source selections attached while a Copilot SDK agent is running don’t reach the model #2838
Agent suggestions
Public previewDescription
Activity
Thanks for the detailed report and repro.
What I checked: the SDK send path (
nodejs/src/session.ts,types.tsMessageOptions). The SDK just forwardsattachmentsandmode("enqueue"/"immediate") to the runtime via JSON-RPC, with no mode-specific attachment handling. Your finding that theuser.messageevent persists the selection is consistent with this: the SDK delivers it intact.Conclusion: the loss happens after the SDK, in the runtime (Copilot CLI), where immediate/steering messages are turned into the model request. Per your table, text blobs are rendered on that path and selections aren't. That is a genuine inconsistency rather than intended design. The visible chips promise context the model never receives, so I'm labeling this
bug.Next step: the fix belongs in the runtime's steering-message rendering, so it will likely need to be routed to the runtime/CLI owners. Ideally it would use the same selection rendering as the idle path, with a regression test sending a selection during a tool call. I couldn't reproduce it here, since that needs the runtime and a paused-tool setup.
Generated by Bug Handler for #2838 · copilot · auto · 15.4 AIC · ⌖ 0.469 AIC · ⊞ 7.5K · ◷
I ran into this while dogfooding a language-model provider for Vercel AI Gateway I'm working on, using a Copilot chat.
While the agent was working, I attached a few source selections and asked whether some verbose validation code would benefit from Zod or another approach. The selections appeared as attachment chips in my message, but the agent asked which file I meant. When I pointed out that the selections were attached, it said it had received only a browser-page attachment.
That was confusing: from my perspective, I’d already supplied exactly the context it was asking for.
What we found
I worked with an agent to trace the selections through the installed VS Code agent host. It forwards their text, file paths and ranges to the SDK, and the SDK persists them in its
user.messageevent. However, they’re absent from the request that reaches our model provider.We then reproduced the behavior using the installed SDK/runtime directly, with synthetic model responses and no VS Code or Vercel provider involved:
mode: "immediate"during a tool callBoth cases persist the attachments correctly. The comparison reproduced twice.
Reproduction
selectionattachment with text, file path and range, plus a text-blob attachment as a control.The steering message and text blob are present, but the selection is missing. Sending those same attachments while idle includes the selected code and its location.
Tested with the versions bundled in my VS Code installation:
1.0.17-unstable.37397886721.gad270aa1.0.92-4.unstable.r37397886721.gad270aaExpected behavior
I’d expect source selections attached to a steering message to reach the model just as they do when sent while idle.
Reviewing code while an agent continues working feels like a pretty normal use of steering. Ideally, selection rendering would follow the same path for both delivery modes, with a regression test covering attachments sent during a tool call. The visible attachment chips should accurately represent the context the agent receives.