Gemini with code execution and image return with out correct url #946

New Issue

2026-02-16T10:21:05-05:00

yindo commented

2026-02-16 10:21:05 -05:00

Originally created by @sweetwxh on GitHub (Jan 22, 2026).

Self Checks

I have read the Contributing Guide and Language Policy.
This is only for bug report, if you would like to ask a question, please head to Discussions.
I have searched for existing issues search for existing issues, including closed ones.
I confirm that I am using English to submit this report, otherwise it will be closed.
【中文用户 & Non English User】请使用英语提交，否则会被关闭：）
Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I am using Gemini-3-Pro with code execution enabled, allowing it to output Matplotlib charts to render data. However, in the final chat dialog, the image sometimes displays correctly and sometimes does not — for example, the image path appears as sandbox:/mnt/data/medical_aesthetics_analysis.png, and this behavior is highly random. The image returned by the model is actually stored as base64 in inline_data. How is this handled after it reaches Dify? How can I ensure a stable and correct image path in the dialog? Or is there any configuration for this?

✔️ Expected Behavior

URL like this can work:

❌ Actual Behavior

No response

Originally created by @sweetwxh on GitHub (Jan 22, 2026). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.11.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I am using Gemini-3-Pro with code execution enabled, allowing it to output Matplotlib charts to render data. However, in the final chat dialog, the image sometimes displays correctly and sometimes does not — for example, the image path appears as sandbox:/mnt/data/medical_aesthetics_analysis.png, and this behavior is highly random. The image returned by the model is actually stored as base64 in inline_data. How is this handled after it reaches Dify? How can I ensure a stable and correct image path in the dialog? Or is there any configuration for this? ### ✔️ Expected Behavior URL like this can work: ![](http://mydomain.com/files/tools/17fd9bac-f0b1-4ed5-a600-7f4e7d555653.png?timestamp=1769143497&nonce=9c8d292cd46bd2af1c001055d4181fed&sign=c0qnN56pIdoqoUMCJnn6wF7LYh3nYO3d4ZlwQaIEMpE=) ### ❌ Actual Behavior _No response_

yindo added the bug label 2026-02-16 10:21:05 -05:00

yindo commented

2026-02-16 10:21:05 -05:00

@dosubot[bot] commented on GitHub (Jan 22, 2026):

The root cause is that Dify’s code execution (e.g., Matplotlib in Gemini-3-Pro) runs in a sandbox and returns output as plain stdout—so image paths like sandbox:/mnt/data/... are not automatically converted to stable URLs or inline images in chat dialogs. Unless the model emits a proper URL or base64 object, you’ll see these internal paths, which aren’t accessible outside the sandbox and lead to inconsistent rendering source.

To ensure stable, correct image URLs in chat dialogs, you should convert base64 image data to a file and generate a signed URL using Dify’s file manager. Here’s the recommended workflow source:

import base64
from dify.api.core.tools.tool_file_manager import ToolFileManager

# Decode base64 to bytes
image_bytes = base64.b64decode(base64_data)

# Save file to Dify storage
tool_file = ToolFileManager().create_file_by_raw(
    user_id=user_id,
    tenant_id=tenant_id,
    conversation_id=conversation_id,
    file_binary=image_bytes,
    mimetype="image/png",  # or "image/jpeg"
    filename="image.png"
)

# Generate signed URL
signed_url = ToolFileManager.sign_file(tool_file_id=tool_file.id, extension=".png")

Make sure your Docker .env sets FILES_URL to an externally accessible address and restart containers after changes. Signed URLs expire quickly for security, so regenerate if longer access is needed.

You can also control image rendering with the MULTIMODAL_SEND_IMAGE_FORMAT (or MULTIMODAL_SEND_FORMAT) config: set to 'url' for signed URLs, or 'base64' for inline data URIs source.

Known limitations: Gemini plugins may not handle multi-turn image generation due to missing thought_signature tokens, causing abnormal output after the first image source. For reliable multi-turn image output, consider starting a new conversation for each image or using models/plugins that support inline file handling (e.g., gemini-3-flash-preview with use_inline_file parameter) source.

If you need to render large images, avoid embedding huge base64 strings directly in chat—this can freeze the frontend. Use URLs for safer rendering source.

Let me know if you need more details or code samples for your specific workflow.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Jan 22, 2026):  The root cause is that Dify’s code execution (e.g., Matplotlib in Gemini-3-Pro) runs in a sandbox and returns output as plain stdout—so image paths like `sandbox:/mnt/data/...` are not automatically converted to stable URLs or inline images in chat dialogs. Unless the model emits a proper URL or base64 object, you’ll see these internal paths, which aren’t accessible outside the sandbox and lead to inconsistent rendering [source](https://github.com/langgenius/dify/blob/b3a869b91b49530808ce76c88cb142c0543f2687/api/core/helper/code_executor/code_executor.py#L33-L157). To ensure stable, correct image URLs in chat dialogs, you should convert base64 image data to a file and generate a signed URL using Dify’s file manager. Here’s the recommended workflow [source](https://github.com/langgenius/dify/issues/30424): ```python import base64 from dify.api.core.tools.tool_file_manager import ToolFileManager # Decode base64 to bytes image_bytes = base64.b64decode(base64_data) # Save file to Dify storage tool_file = ToolFileManager().create_file_by_raw( user_id=user_id, tenant_id=tenant_id, conversation_id=conversation_id, file_binary=image_bytes, mimetype="image/png", # or "image/jpeg" filename="image.png" ) # Generate signed URL signed_url = ToolFileManager.sign_file(tool_file_id=tool_file.id, extension=".png") ``` Make sure your Docker `.env` sets `FILES_URL` to an externally accessible address and restart containers after changes. Signed URLs expire quickly for security, so regenerate if longer access is needed. You can also control image rendering with the `MULTIMODAL_SEND_IMAGE_FORMAT` (or `MULTIMODAL_SEND_FORMAT`) config: set to `'url'` for signed URLs, or `'base64'` for inline data URIs [source](https://github.com/langgenius/dify/issues/14245#issuecomment-2677675371). Known limitations: Gemini plugins may not handle multi-turn image generation due to missing `thought_signature` tokens, causing abnormal output after the first image [source](https://github.com/langgenius/dify/issues/31272). For reliable multi-turn image output, consider starting a new conversation for each image or using models/plugins that support inline file handling (e.g., `gemini-3-flash-preview` with `use_inline_file` parameter) [source](https://github.com/langgenius/dify/issues/31082). If you need to render large images, avoid embedding huge base64 strings directly in chat—this can freeze the frontend. Use URLs for safer rendering [source](https://github.com/langgenius/dify/issues/22618). Let me know if you need more details or code samples for your specific workflow.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5b6a23df-2171-47be-a2d0-f3f2a9628b55?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20root%20cause%20is%20that%20Dify%E2%80%99s%20code%20execution%20%28e.g.%2C%20Matplotlib%20in%20Gemini-3-Pro%29%20runs%20in%20a%20sandbox%20and%20returns%20output%20as%20plain%20stdout%E2%80%94so%20image%20paths%20like%20%60sandbox%3A/mnt/data/...%60%20are%20not%20automatically%20converted%20to%20stable%20URLs%20or%20inline%20images%20in%20chat%20dialogs.%20Unless%20the%20model%20emits%20a%20proper%20URL%20or%20base64%20object%2C%20you%E2%80%99ll%20see%20these%20internal%20paths%2C%20which%20aren%E2%80%99t%20accessible%20outside%20the%20sandbox%20and%20lead%20to%20inconsistent%20rendering%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/b3a869b91b49530808ce76c88cb142c0543f2687/api/core/helper/code_executor/code_executor.py%23L33-L157%29.%0A%0ATo%20ensure%20stable%2C%20correct%20image%20URLs%20in%20chat%20dialogs%2C%20you%20should%20convert%20base64%20image%20data%20to%20a%20file%20and%20generate%20a%20signed%20URL%20using%20Dify%E2%80%99s%20file%20manager.%20Here%E2%80%99s%20the%20recommended%20workflow%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/30424%29%3A%0A%0A%60%60%60python%0Aimport%20base64%0Afrom%20dify.api.core.tools.tool_file_manager%20import%20ToolFileManager%0A%0A%23%20Decode%20base64%20to%20bytes%0Aimage_bytes%20%3D%20base64.b64decode%28base64_data%29%0A%0A%23%20Save%20file%20to%20Dify%20storage%0Atool_file%20%3D%20ToolFileManager%28%29.create_file_by_raw%28%0A%20%20%20%20user_id%3Duser_id%2C%0A%20%20%20%20tenant_id%3Dtenant_id%2C%0A%20%20%20%20conversation_id%3Dconversation_id%2C%0A%20%20%20%20file_binary%3Dimage_bytes%2C%0A%20%20%20%20mimetype%3D%22image/png%22%2C%20%20%23%20or%20%22image/jpeg%22%0A%20%20%20%20filename%3D%22image.png%22%0A%29%0A%0A%23%20Generate%20signed%20URL%0Asigned_url%20%3D%20ToolFileManager.sign_file%28tool_file_id%3Dtool_file.id%2C%20extension%3D%22.png%22%29%0A%60%60%60%0A%0AMake%20sure%20your%20Docker%20%60.env%60%20sets%20%60FILES_URL%60%20to%20an%20externally%20accessible%20address%20and%20restart%20containers%20after%20changes.%20Signed%20URLs%20expire%20quickly%20for%20security%2C%20so%20regenerate%20if%20longer%20access%20is%20needed.%0A%0AYou%20can%20also%20control%20image%20rendering%20with%20the%20%60MULTIMODAL_SEND_IMAGE_FORMAT%60%20%28or%20%60MULTIMODAL_SEND_FORMAT%60%29%20config%3A%20set%20to%20%60%27url%27%60%20for%20signed%20URLs%2C%20or%20%60%27base64%27%60%20for%20inline%20data%20URIs%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/14245%23issuecomment-2677675371%29.%0A%0AKnown%20limitations%3A%20Gemini%20plugins%20may%20not%20handle%20multi-turn%20image%20generation%20due%20to%20missing%20%60thought_signature%60%20tokens%2C%20causing%20abnormal%20output%20after%20the%20first%20image%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31272%29.%20For%20reliable%20multi-turn%20image%20output%2C%20consider%20starting%20a%20new%20conversation%20for%20each%20image%20or%20using%20models/plugins%20that%20support%20inline%20file%20handling%20%28e.g.%2C%20%60gemini-3-flash-preview%60%20with%20%60use_inline_file%60%20parameter%29%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31082%29.%0A%0AIf%20you%20need%20to%20render%20large%20images%2C%20avoid%20embedding%20huge%20base64%20strings%20directly%20in%20chat%E2%80%94this%20can%20freeze%20the%20frontend.%20Use%20URLs%20for%20safer%20rendering%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/22618%29.%0A%0ALet%20me%20know%20if%20you%20need%20more%20details%20or%20code%20samples%20for%20your%20specific%20workflow.) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/31433)

yindo commented

2026-02-16 10:21:05 -05:00

@sweetwxh commented on GitHub (Jan 23, 2026):

@dosu
Not every time does it end up as sandbox:/mnt/data/medical_aesthetics_analysis.png; sometimes a correct link is generated, e.g.
http://mydify.com/files/tools/17fd9bac-f0b1-4ed5-a600-7f4e7d555653.png?timestamp=1769143497&nonce=9c8d292cd46bd2af1c001055d4181fed&sign=c0qnN56pIdoqoUMCJnn6wF7LYh3nYO3d4ZlwQaIEMpE=.

I also looked at the Gemini plugin for Dify. When the model returns an image, the plugin extracts the data, builds an ImagePromptMessageContent object, and passes it back. What happens after that, however, is unclear—sometimes it works, sometimes it doesn’t.

Here is the relevant snippet from the Gemini plugin:

ImagePromptMessageContent(
    format=mime_subtype,
    base64_data=base64.b64encode(data).decode(),
    base64_data=base64.b64encode(data).decode(),
    mime_type=mime_type,
    detail=ImagePromptMessageContent.DETAIL.HIGH,
)

@sweetwxh commented on GitHub (Jan 23, 2026): @dosu Not every time does it end up as `sandbox:/mnt/data/medical_aesthetics_analysis.png`; sometimes a correct link is generated, e.g. `http://mydify.com/files/tools/17fd9bac-f0b1-4ed5-a600-7f4e7d555653.png?timestamp=1769143497&nonce=9c8d292cd46bd2af1c001055d4181fed&sign=c0qnN56pIdoqoUMCJnn6wF7LYh3nYO3d4ZlwQaIEMpE=`. I also looked at the Gemini plugin for Dify. When the model returns an image, the plugin extracts the data, builds an `ImagePromptMessageContent` object, and passes it back. What happens after that, however, is unclear—sometimes it works, sometimes it doesn’t. Here is the relevant snippet from the Gemini plugin: ```python ImagePromptMessageContent( format=mime_subtype, base64_data=base64.b64encode(data).decode(), base64_data=base64.b64encode(data).decode(), mime_type=mime_type, detail=ImagePromptMessageContent.DETAIL.HIGH, ) ```

yindo commented

2026-02-16 10:21:05 -05:00

@dosubot[bot] commented on GitHub (Jan 23, 2026):

After the Gemini plugin returns an ImagePromptMessageContent with base64 image data, Dify tries to persist that image using its ToolFileManager. If the backend receives valid base64 image data, it saves the file and generates a signed URL (like the working example you saw). If it only receives a sandbox path or the upload logic fails (often due to misconfigured FILES_URL or INTERNAL_FILES_URL, or port 5001 not being exposed in Docker), Dify can't generate a URL and just shows the sandbox path instead. This is a known, unresolved bug that affects both self-hosted and cloud setups, and is often triggered by plugin upload failures or missing environment variables.

To ensure consistent image URLs: double-check that both FILES_URL and INTERNAL_FILES_URL are set to externally accessible addresses, port 5001 is exposed in your Docker config, and your images are in a supported format. If you still see sandbox paths, check your logs for file upload or access errors. More details and troubleshooting steps are available in these discussions: file upload config and errors, Docker port exposure, and ToolFileManager logic.

Recent Dify updates also changed how URLs are generated, prioritizing INTERNAL_FILES_URL over FILES_URL, so make sure both are set correctly and restart your containers after any changes PR langgenius/dify#29962, PR langgenius/dify#30598.

If you want a visual, here's the pipeline:

graph LR
    A["Gemini Plugin returns ImagePromptMessageContent"] --> B{"Valid base64 image data?"}
    B -- "Yes" --> C["ToolFileManager saves file & generates signed URL"]
    C --> D["Chat dialog shows correct image URL"]
    B -- "No or upload fails" --> E["No ToolFile created"]
    E --> F["Chat dialog shows sandbox:/mnt/data path"]

Let me know if you want help interpreting logs or have more questions about your setup.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Jan 23, 2026):  After the Gemini plugin returns an ImagePromptMessageContent with base64 image data, Dify tries to persist that image using its ToolFileManager. If the backend receives valid base64 image data, it saves the file and generates a signed URL (like the working example you saw). If it only receives a sandbox path or the upload logic fails (often due to misconfigured FILES_URL or INTERNAL_FILES_URL, or port 5001 not being exposed in Docker), Dify can't generate a URL and just shows the sandbox path instead. This is a known, unresolved bug that affects both self-hosted and cloud setups, and is often triggered by plugin upload failures or missing environment variables. To ensure consistent image URLs: double-check that both FILES_URL and INTERNAL_FILES_URL are set to externally accessible addresses, port 5001 is exposed in your Docker config, and your images are in a supported format. If you still see sandbox paths, check your logs for file upload or access errors. More details and troubleshooting steps are available in these discussions: [file upload config and errors](https://github.com/langgenius/dify-official-plugins/issues/2343), [Docker port exposure](https://github.com/langgenius/dify-official-plugins/issues/1816), and [ToolFileManager logic](https://github.com/langgenius/dify/blob/fa92548cf628b30ea44fa05378867c50ba4e0700/api/core/tools/tool_file_manager.py#L36-L150). Recent Dify updates also changed how URLs are generated, prioritizing INTERNAL_FILES_URL over FILES_URL, so make sure both are set correctly and restart your containers after any changes [PR langgenius/dify#29962](https://github.com/langgenius/dify/pull/29962), [PR langgenius/dify#30598](https://github.com/langgenius/dify/pull/30598). If you want a visual, here's the pipeline: ```mermaid graph LR A["Gemini Plugin returns ImagePromptMessageContent"] --> B{"Valid base64 image data?"} B -- "Yes" --> C["ToolFileManager saves file & generates signed URL"] C --> D["Chat dialog shows correct image URL"] B -- "No or upload fails" --> E["No ToolFile created"] E --> F["Chat dialog shows sandbox:/mnt/data path"] ``` Let me know if you want help interpreting logs or have more questions about your setup.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c8062ca5-7f88-4540-86a4-ddaeca55787d?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=After%20the%20Gemini%20plugin%20returns%20an%20ImagePromptMessageContent%20with%20base64%20image%20data%2C%20Dify%20tries%20to%20persist%20that%20image%20using%20its%20ToolFileManager.%20If%20the%20backend%20receives%20valid%20base64%20image%20data%2C%20it%20saves%20the%20file%20and%20generates%20a%20signed%20URL%20%28like%20the%20working%20example%20you%20saw%29.%20If%20it%20only%20receives%20a%20sandbox%20path%20or%20the%20upload%20logic%20fails%20%28often%20due%20to%20misconfigured%20FILES_URL%20or%20INTERNAL_FILES_URL%2C%20or%20port%205001%20not%20being%20exposed%20in%20Docker%29%2C%20Dify%20can%27t%20generate%20a%20URL%20and%20just%20shows%20the%20sandbox%20path%20instead.%20This%20is%20a%20known%2C%20unresolved%20bug%20that%20affects%20both%20self-hosted%20and%20cloud%20setups%2C%20and%20is%20often%20triggered%20by%20plugin%20upload%20failures%20or%20missing%20environment%20variables.%20%0A%0ATo%20ensure%20consistent%20image%20URLs%3A%20double-check%20that%20both%20FILES_URL%20and%20INTERNAL_FILES_URL%20are%20set%20to%20externally%20accessible%20addresses%2C%20port%205001%20is%20exposed%20in%20your%20Docker%20config%2C%20and%20your%20images%20are%20in%20a%20supported%20format.%20If%20you%20still%20see%20sandbox%20paths%2C%20check%20your%20logs%20for%20file%20upload%20or%20access%20errors.%20More%20details%20and%20troubleshooting%20steps%20are%20available%20in%20these%20discussions%3A%20%5Bfile%20upload%20config%20and%20errors%5D%28https%3A//github.com/langgenius/dify-official-plugins/issues/2343%29%2C%20%5BDocker%20port%20exposure%5D%28https%3A//github.com/langgenius/dify-official-plugins/issues/1816%29%2C%20and%20%5BToolFileManager%20logic%5D%28https%3A//github.com/langgenius/dify/blob/fa92548cf628b30ea44fa05378867c50ba4e0700/api/core/tools/tool_file_manager.py%23L36-L150%29.%0A%0ARecent%20Dify%20updates%20also%20changed%20how%20URLs%20are%20generated%2C%20prioritizing%20INTERNAL_FILES_URL%20over%20FILES_URL%2C%20so%20make%20sure%20both%20are%20set%20correctly%20and%20restart%20your%20containers%20after%20any%20changes%20%5BPR%20%2329962%5D%28https%3A//github.com/langgenius/dify/pull/29962%29%2C%20%5BPR%20%2330598%5D%28https%3A//github.com/langgenius/dify/pull/30598%29.%0A%0AIf%20you%20want%20a%20visual%2C%20here%27s%20the%20pipeline%3A%0A%0A%60%60%60mermaid%0Agraph%20LR%0A%20%20%20%20A%5B%22Gemini%20Plugin%20returns%20ImagePromptMessageContent%22%5D%20--%3E%20B%7B%22Valid%20base64%20image%20data%3F%22%7D%0A%20%20%20%20B%20--%20%22Yes%22%20--%3E%20C%5B%22ToolFileManager%20saves%20file%20%26%20generates%20signed%20URL%22%5D%0A%20%20%20%20C%20--%3E%20D%5B%22Chat%20dialog%20shows%20correct%20image%20URL%22%5D%0A%20%20%20%20B%20--%20%22No%20or%20upload%20fails%22%20--%3E%20E%5B%22No%20ToolFile%20created%22%5D%0A%20%20%20%20E%20--%3E%20F%5B%22Chat%20dialog%20shows%20sandbox%3A/mnt/data%20path%22%5D%0A%60%60%60%0A%0ALet%20me%20know%20if%20you%20want%20help%20interpreting%20logs%20or%20have%20more%20questions%20about%20your%20setup.) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/31433)

yindo commented

2026-02-16 10:21:05 -05:00

@crazywoola commented on GitHub (Feb 3, 2026):

Hi @sweetwxh, thanks for opening this issue.

Why this is being closed

Dify issue tracking requires English-only issue title and description for consistent collaboration.

Next steps

Please open a new issue in English and include clear details so maintainers can help efficiently.

Thanks for understanding and for your support.

@crazywoola commented on GitHub (Feb 3, 2026): Hi @sweetwxh, thanks for opening this issue. ### Why this is being closed Dify issue tracking requires English-only issue title and description for consistent collaboration. ### Next steps Please open a new issue in English and include clear details so maintainers can help efficiently. Thanks for understanding and for your support.

yindo referenced this issue

2026-02-16 10:23:32 -05:00

[PR #946] [MERGED] revert(siliconflow): tool-call features #1633

Sign in to join this conversation.

Branches Tags

main

feat/3479-gemini-flash-models

dependabot/uv/tools/chart/uv-cdf8d38825

feat/moonshot-kimi-k3-k27-code

feat/gemini-system-instruction-semantics

fix/gemini-text-system-parts

dosu/doc-update-3436

feat/openai-gpt-5-6-support

fix/outlook-trigger-readme-permissions

fix/microsoft-oauth-datasource-tenant

fix/byteplus-api-base-url-label

feat/ark-video-generation-custom-models

fix/openai-stream-reasoning-thinking

fix/skip-live-tests-missing-keys

codex/enhance-discord-integrations

codex/harden-trigger-oauth-permissions

update-lemonade-default-port

codex/fix-pr-review-ci

feat/ark-multimodal-polling

copilot/update-mineru-3x-plugin-file-types

feat/action-security-fix

feat/claude-fable5

codex/fix-ollama-model-category

codex/upgrade-ollama-latest

feat/minimax-m3

codex/refine-plugin-readmes

fix/fireworks-model-label-zh-hans

chore/version-bump-plugins-batch-06

chore/version-bump-plugins-batch-05

chore/version-bump-plugins-batch-04

chore/version-bump-plugins-batch-03

chore/version-bump-plugins-batch-02

fix/plugin-sdk-i18n-fields

chore/version-bump-plugins-batch-01

chore/dependencies-high-priority

chore/dependencies-medium-priority

chore/dependencies-low-priority-clean

chore/dependencies-low-priority

fix/tongyi-align-deepseek-model-metadata

codex/update-openrouter-models

codex/azure-ai-studio-cjk-version-bump

feat/ernie-image-tool

claude/cranky-thompson-b6a281

fix/remove-unavailable-volcengine-models

fix/legacy-plugin-daemon-compatibility

copilot/add-deepseek-v4-to-openrouter

codex/merge-tongyi-tts-prs

codex/depot-runners

chore/migrate-selected-plugins-to-uv-lock

fix/repair-failed-plugin-deploys

ci/fix-plugin-change-detection

chore/migrate-aws-s3-storage-to-uv-lock

chore/migrate-somark-dependencies-to-uv-lock

ci/uv-lock-dependency-validation

fix/2911-openai-api-compatible-tool-call-content

chore/remove-deprecated-plugins

copilot/add-more-models-openrouter-provider

copilot/fix-error-connecting-fireworks-ai

fix/openai-compatible-max-completion-tokens-validation

fix/gemini-lockfile

chore/add-React-fallback-desc

feat/add-gemini-embedding-2-preview

copilot/add-claude-sonnet-opus-4-6

codex/update-xai-models-2721

fix/remove-sentence-transformer-for-hubspot

feat/add-gpt-5.4

copilot/fix-ci-errors-and-bump-version

copilot/fix-security-errors-combined

copilot/update-gemini-model-version

fix/anthropic-parallel-tool-call

codex/fix-azure-ai-studio-azure-core-1-38

codex/fix-azure-blob-azure-core-1-38

codex/fix-azure-openai-azure-core-1-38

gitlab-credentials-c

fix/openrouter-validation-model

fix/gemini-null-checks

fix/deepseek-tool-message-ignore

fix/gemini-dependencies

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: langgenius/dify-official-plugins#946