fix(opencode): forward parent attachments to subagents

[21pounder]

Issue for this PR

Closes #25553

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This fixes the attachment handoff for @mention subagents in the task path.

In the failing #25553 flow, the parent agent could spawn the subagent, but TaskTool only rebuilt child prompt parts from params.prompt, so the image attached to the parent user message never reached the child session.

This change forwards file parts from the triggering parent user message into the child prompt, but only when that parent message explicitly targets the same subagent. That keeps the fix scoped to the actual handoff boundary and lets multimodal subagents receive the attached image once they are spawned.

This does not try to solve cases where the parent LLM does not choose to call task at all. That routing decision is upstream model behavior, not something this patch can make deterministic.

sequenceDiagram
    participant U as User
    participant P as Parent session
    participant B as build model
    participant T as TaskTool
    participant V as Child subagent

    U->>P: text + @vision + image
    P->>B: parent message
    B->>T: call task(subagent, prompt)
    T->>V: child prompt from params.prompt only
    Note over V: image missing

Loading

sequenceDiagram
    participant U as User
    participant P as Parent session
    participant B as build model
    participant T as TaskTool
    participant V as Child subagent

    U->>P: text + @vision + image
    P->>B: parent message
    B->>T: call task(subagent, prompt)
    T->>T: collect file parts from the triggering parent user message
    T->>V: child prompt + forwarded image
    V-->>P: image analysis result

Loading

How did you verify your code works?

• Sent one POST /session/:id/message request with text + agent + file parts
• Confirmed via GET /session/:id/message that the session stored the @vision mention and the image attachment
• Confirmed in the server log that a child session was created with agent=vision
• Confirmed in the server log that the child session streamed with agent=vision and mode=subagent
• Ran bun typecheck from packages/opencode
• Ran bun test --timeout 15000 test/tool/task.test.ts from packages/opencode

Screenshots / recordings

POST request with text + agent + file parts:

Stored session message with @vision and image attachment:

Child session creation for the subagent:

Child subagent stream:

Regression test passing:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[ChanGarcia10]

@rekram1-node This is a something that is needed in opencode right now. Right now it strips out the path, it's annoying to be working with agents that need the whole path for image reading. Can you take a look at this?
Thanks

[qiming-zhao]

Hi, this issue also affects me on Windows CLI (opencode TUI). I'm using @Vision subagent with attached images and the images never get forwarded. The parent model can't process images and the vision subagent receives text-only context.

[CSWNDQTJ-Kenny]

This PR's approach matches what I independently arrived at — extract image/file parts from the triggering parent message and forward them into the child subagent prompt. Confirming it's the right fix and adding two notes that may help it land:

1. Source of parts — ctx.messages vs. triggering user message

Your PR description says "collect file parts from the triggering parent user message". Equivalent and slightly more general: collect from ctx.messages (the full message array passed to TaskTool.execute). This also covers cases where the image arrived in an earlier turn but the parent LLM only just decided to spawn the subagent:

const imageParts = (ctx.messages ?? [])
  .flatMap((m) => m.parts ?? [])
  .filter((p) => p.type === "file" && p.mime?.startsWith("image/"))
  .map((p) => ({ type: "file", mime: p.mime, url: p.url, filename: p.filename }));
if (imageParts.length > 0) parts6.push(...imageParts);

If you want to stay scoped to "only the triggering message" that's fine too — both unblock the reported bugs.

2. Companion fix needed: unsupportedParts modalities format

Even with this PR merged, custom OpenAI-compatible providers (doubao, kimi-vision, MiMo via config) still fail because unsupportedParts assumes capabilities are an array:

model.capabilities.modalities.input.includes("image")  // throws on {image:true} objects

Config-defined providers get capabilities built as a boolean object in the configProviders loop:

{ input: { image: true, text: true }, output: { text: true } }

So .includes() fails and the image is stripped before reaching the child model. Needs dual-format handling:

const input = model.capabilities?.modalities?.input ?? {};
const supportsImage = Array.isArray(input)
  ? input.includes("image")
  : input.image === true;

This is also tracked in #30071. Without this companion fix, this PR alone won't unblock the doubao/kimi/MiMo reporters in #34409, #36020, #25553.

Status check

PR's been open since 2026-06-14 with 3 comments — is there anything blocking review? Happy to help drive it forward.

[wstuckey]

This is solid. Can we please get this merged?