bug: @mention subagent with attached image in Web UI — image not forwarded to multimodal subagent #25553

Activity

1. github-actions

   assigned

   jlongster

   on May 3, 2026
2. github-actions commented on May 3, 2026

   

   github-actionsBot

   on May 3, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Bug: opencode-go/kimi-k2.6 fails in child sessions with "image.png" error #24454: Same error message ("Cannot read 'image.png' (this model does not support image input)") occurring in child/subagent sessions — very similar root cause
   • Error: "this model does not support image input" with paid providers (GitHub Copilot, Anthropic, etc.) but works with free models #16468: Same error message when dragging/dropping images, model incorrectly reported as not supporting image input
   • Text-only models still receive image read attachments in prompt context #17205: Text-only models receiving image attachments in prompt context — related to how image data propagates through the message-building path

   Please review these issues to see if your report overlaps, and consider linking or closing if they address the same underlying problem.
3. 21pounder commented on Jun 14, 2026

   

   21pounder

   on Jun 14, 2026

   Contributor

   More actions

   I reproduced this on the latest dev branch using bun dev serve.

   The main failing path is the Web UI style request shape: the user message contains text + agent + file, where @vision is sent as an agent part, not a subtask part.

   Reproduction

   1. Create a session

   POST http://localhost:4096/session
   Content-Type: application/json
   
   {
     "agentID": "build"
   }

   This returned session ses_13f04e5f9ffeU50f57Km5Zc5Yb.

   2. Send one message containing @vision and an image attachment

   POST http://localhost:4096/session/ses_13f04e5f9ffeU50f57Km5Zc5Yb/message
   Content-Type: application/json
   
   {
     "model": { "providerID": "deepseek", "modelID": "deepseek-v4-pro" },
     "parts": [
       {
         "type": "text",
         "text": "@vision describe this image"
       },
       {
         "type": "agent",
         "name": "vision",
         "source": { "value": "@vision", "start": 0, "end": 7 }
       },
       {
         "type": "file",
         "url": "data:image/png;base64,...",
         "mime": "image/png",
         "filename": "image.png"
       }
     ]
   }

   The request payload shows the expected text + agent + file shape:
   

   3. Inspect the stored session messages

   GET http://localhost:4096/session/ses_13f04e5f9ffeU50f57Km5Zc5Yb/message

   The stored message history shows that the parent session received the image together with the agent part:

   

   4. Inspect the server log for this request

   The relevant log block for the same request is:

   level=INFO  message=process  session.id=ses_13f04e5f9ffeU50f57Km5Zc5Yb  messageID=...
   level=INFO  message=stream   providerID=deepseek  modelID=deepseek-v4-pro
                              session.id=ses_13f04e5f9ffeU50f57Km5Zc5Yb
                              small=false  agent=build  mode=primary
   ...
   level=INFO  message="exiting loop"  session.id=ses_13f04e5f9ffeU50f57Km5Zc5Yb
   

   The log shows the parent session runs on deepseek-v4-pro, but there is no child session creation and no vision subagent execution in the same request path:

   

   What this confirms

   This reproduces the issue on the main path that users hit from the app:

   1. The user message contains an image attachment.
   2. The @vision mention is persisted as an agent part.
   3. The parent session processes the request with the primary model (deepseek-v4-pro in this repro).
   4. The log does not show a vision child session being created or streamed for this request.

   So the image is admitted into the parent message, but it does not make it into a multimodal vision subagent turn.

   Root cause

   There are two gaps in the current flow.

   First, the app builds the request as text + agent + file:

   • packages/app/src/components/prompt-input/build-request-parts.ts

   The backend then handles the agent part by appending synthetic text instructing the parent model to call the task tool:

   • packages/opencode/src/session/prompt.ts:957
   • packages/opencode/src/session/prompt.ts:968

   That means this path goes through the parent model first. It is not a direct subtask admission path.

   Second, TaskTool.execute only reconstructs child prompt parts from params.prompt:

   • packages/opencode/src/tool/task.ts:187

   resolvePromptParts(params.prompt) can resolve file references embedded in the prompt string, but it has no access to the already-admitted image file part from the parent user message. So even if the parent model does call the task tool, the attachment is not available to the child session unless it is explicitly threaded through.

   Fix approach

   I think the fix needs to cover the agent + file path directly, not only the direct subtask path.

   1. When a task is spawned from a user message that includes media attachments, the task execution path should forward those file parts to the child prompt explicitly instead of relying only on params.prompt.
   2. The forwarded attachments should be rebuilt as fresh child prompt parts rather than reusing persisted parent message part identities.
   3. This fix can stay scoped to the case where the subagent is actually spawned and only needs the attachment handoff to be preserved across that boundary.
4. 21pounder commented on Jun 17, 2026

   

   21pounder

   on Jun 17, 2026

   Contributor

   More actions

   Hi @jlongster,

   I have submitted a PR (#32302) to address this issue.

   As detailed in my reproduction steps above, the root cause is that TaskTool.execute in packages/opencode/src/tool/task.ts only reconstructs child prompts from params.prompt, which completely leaves behind the original image/media file parts attached to the parent user message.

   The PR fixes this by explicitly forwarding parent media attachments to the spawned subagent's prompt context.

   Could you please take a look when you have a moment? Thank you!
5. CSWNDQTJ-Kenny commented on Jul 28, 2026

   

   CSWNDQTJ-Kenny

   on Jul 28, 2026

   More actions

   Cross-linking the root cause analysis I posted on #34409 / #36020 / #32302:

   The image not being forwarded is because TaskTool.runTask builds the child subagent prompt only from params.prompt via resolvePromptParts, which never reads ctx.messages. So the file part attached to the parent user message is silently dropped before the subagent is spawned — regardless of Web UI vs CLI, and regardless of whether the parent LLM is multimodal.

   Minimal fix (matches #32302, which closes this issue but has been stalled since June):

   const parts6 = await ops.resolvePromptParts(params.prompt);
   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);
   await ops.prompt({ parts: parts6 });

   A companion fix to unsupportedParts is also needed for config-defined OpenAI-compatible providers (doubao, kimi-vision, MiMo) — see #34409 comment for details. Both patches verified working on 1.17.20.
6. github-actions commented on Sep 27, 2026

   

   github-actionsBot

   on Sep 27, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
7. github-actions

   closed this as not plannedon Sep 27, 2026