Attachments are silently ignored when using the /fleet command

[DonJayamanne]

Summary

When a message includes attachments (for example an image, a file or folder
reference, selected code, or large pasted content) and that message uses the
/fleet command, the attachments are not delivered to the agent. Fleet runs
using only the typed text, and the user is given no indication that the
attached context was dropped.

Steps to reproduce

1. Open an agent session (Copilot).
2. Add one or more attachments to the message (e.g. paste an image, attach a
   file, or add a file/folder reference).
3. Start the message with the /fleet command, e.g.
   /fleet analyze the attached screenshot and split the work.
4. Send the message.

Expected behavior

Either:

• the attachments are made available to Fleet just as they are for a normal
  message, or
• if attachments cannot be used with /fleet, the user is clearly told before
  the run starts (so they can resend without /fleet or adjust their request).

Actual behavior

• The attachments are silently discarded.
• Fleet proceeds using only the typed prompt text.
• There is no warning, error, or other signal that the attachments were ignored.

Impact

• The agent can produce confident but wrong results because it never received
  context the user explicitly attached and referred to.
• The loss is invisible: users reasonably assume attachments were included,
  since they are included for normal (non-/fleet) messages.
• This is most damaging when the request directly depends on the attachment
  (e.g. "analyze this screenshot", "refactor the attached file").

Possible resolutions

1. Support forwarding attachments to Fleet so /fleet behaves like a normal
   message with attachments.
2. If attachments can't be supported, surface a clear, upfront message when a
   /fleet message includes attachments, instead of silently dropping them.

Notes

• Reproducible with the /fleet command specifically; normal messages deliver
  attachments as expected.
• Severity is "silent data/context loss," which is easy to miss and hard to
  diagnose after the fact.

Environment

• VS Code version:
• OS:

[github-actions]

Investigation Findings

Label applied: bug

What I investigated

• nodejs/src/generated/rpc.ts — the FleetStartRequest interface and the session.fleet.start RPC definition
• nodejs/test/e2e/rpc_shell_and_fleet.e2e.test.ts — existing fleet tests
• nodejs/src/client.ts — the SDK client surface

Root cause

The FleetStartRequest interface (in rpc.ts) only defines a single optional prompt?: string field:

export interface FleetStartRequest {
  prompt?: string;
}

There is no attachments field. When the Copilot UI processes a /fleet message that includes attachments, it calls session.fleet.start with the typed prompt but has nowhere to pass attachments — so they are silently discarded.

By contrast, the normal session.send request (SessionSendParams, line ~13663 in rpc.ts) does include attachments?: Attachment[].

Conclusion

This is a genuine bug / missing feature in the protocol schema. The FleetStartRequest type needs an attachments?: Attachment[] field analogous to what SessionSendParams already supports. Until that field is added to the schema and the fleet handler is updated to forward those attachments, any context attached to a /fleet message is dropped with no warning — matching the silent data-loss behavior the reporter describes.

The fix requires:

1. Adding attachments?: Attachment[] to FleetStartRequest in the RPC schema.
2. Updating the fleet handler to forward those attachments into the orchestration prompt.
3. (Optional but recommended) Adding a client-side or server-side warning when attachments are present but cannot be forwarded, as a fallback until the full fix ships.

Generated by Bug Handler for #2349 · sonnet46 25.8 AIC · ⌖ 5.18 AIC · ⊞ 5.9K · ◷