github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 14:39:31 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24532] issue: image_gen is exposed to the model even when image generation is disabled, and calling it causes HTTP 400 in both default and native modes #107317

New Issue
Closed
opened 2026-05-18 06:04:48 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-18 06:04:48 -05:00
Owner
Copy Link

Originally created by @CoronaAustralis on GitHub (May 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24532

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.9.2

Ollama Version (if applicable)

No response

Operating System

windows 11

Browser (if applicable)

chrome 145

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When image generation is disabled in the UI, the model should not see or be able to call image_gen.
If image_gen is exposed to the model, it should be callable successfully.
Tool visibility should match the actual enabled/disabled state of image generation.

Actual Behavior

In default mode, image generation is handled directly by OpenWebUI and does not go through the chat model first.
However, even when image generation is disabled in the UI, the model can still see image_gen.
If the model is explicitly forced to call image_gen, the request fails with HTTP 400.

Steps to Reproduce

Open OpenWebUI chat window and image is disabled in the tool UI intergrations.
Use default function calling mode.
Start a chat and ask the model which tools it can see.
Observe that the model can still see image_gen even though image generation is disabled.
Explicitly instruct the model to call image_gen.
Observe that the request fails with HTTP 400 and returns:

400, message:
Got more than 131072 bytes when reading: b'data: {"id":"resp_0ddeb49b26c121170169f07fc8f1c0819190517c0a0e3592c5","object":"chat.completion.chun...'

Switch to native mode.
Start a new chat or repeat the same test.
Explicitly instruct the model to call image_gen.
Observe that it fails again with the same HTTP 400 error.

Logs & Screenshots

400, message:
Got more than 131072 bytes when reading: b'data: {"id":"resp_0ddeb49b26c121170169f07fc8f1c0819190517c0a0e3592c5","object":"chat.completion.chun...'

Additional Information

This issue is specifically about image_gen.
I already understand that in default mode, OpenWebUI directly triggers image generation rather than routing it through the chat model.
The problem is that image_gen still appears to be exposed to the model even when image generation is turned off.
This creates a mismatch between UI state and model-visible tools.
It also means the model can be forced to call image_gen even though that path does not work correctly.
From testing, this does not seem to be limited to default mode, because calling image_gen in native mode also produces the same 400 error.
In native mode, model can see generate_image tool，and ask the model to call generate_image, observe that it succeeds.

Originally created by @CoronaAustralis on GitHub (May 10, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24532 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.9.2 ### Ollama Version (if applicable) _No response_ ### Operating System windows 11 ### Browser (if applicable) chrome 145 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When image generation is disabled in the UI, the model should not see or be able to call image_gen. If image_gen is exposed to the model, it should be callable successfully. Tool visibility should match the actual enabled/disabled state of image generation. ### Actual Behavior In default mode, image generation is handled directly by OpenWebUI and does not go through the chat model first. However, even when image generation is disabled in the UI, the model can still see image_gen. If the model is explicitly forced to call image_gen, the request fails with HTTP 400. ### Steps to Reproduce Open OpenWebUI chat window and image is disabled in the tool UI intergrations. Use default function calling mode. Start a chat and ask the model which tools it can see. Observe that the model can still see image_gen even though image generation is disabled. Explicitly instruct the model to call image_gen. Observe that the request fails with HTTP 400 and returns: ``` 400, message: Got more than 131072 bytes when reading: b'data: {"id":"resp_0ddeb49b26c121170169f07fc8f1c0819190517c0a0e3592c5","object":"chat.completion.chun...' ``` Switch to native mode. Start a new chat or repeat the same test. Explicitly instruct the model to call image_gen. Observe that it fails again with the same HTTP 400 error. ### Logs & Screenshots 400, message: Got more than 131072 bytes when reading: b'data: {"id":"resp_0ddeb49b26c121170169f07fc8f1c0819190517c0a0e3592c5","object":"chat.completion.chun...' ### Additional Information This issue is specifically about `image_gen`. I already understand that in default mode, OpenWebUI directly triggers image generation rather than routing it through the chat model. The problem is that image_gen still appears to be exposed to the model even when image generation is turned off. This creates a mismatch between UI state and model-visible tools. It also means the model can be forced to call image_gen even though that path does not work correctly. From testing, this does not seem to be limited to default mode, because calling `image_gen` in native mode also produces the same 400 error. In native mode, model can see `generate_image` tool，and ask the model to call `generate_image`, observe that it succeeds.
GiteaMirror added the bug label 2026-05-18 06:04:48 -05:00
GiteaMirror commented 2026-05-18 06:04:56 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 10, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #23723 issue: Image generation enabled doesn't respect setting
    Related because it is also about image generation state not being respected. That issue reports the feature being automatically turned off when unavailable, while this one reports the inverse mismatch: image_gen remains exposed even when image generation is disabled.
    by xNissX233 · bug

  2. 🟣 #24265 issue: Image generation reports aiohttp ServerDisconnectedError as HTTP 400
    Related because both issues concern image generation tool-call failures surfacing as HTTP 400. This one specifically documents the same 400-class error wrapping for backend image-generation failures.
    by belugaming · bug

  3. 🟣 #22545 issue: Certain Builtin Tools Not Available
    Related because it shows builtin tool visibility depending on integration/menu state. It is not about image generation specifically, but it matches the broader problem of enabled/disabled builtin tools not matching what the model can actually see.
    by pdp-oui · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4414896405 --> @owui-terminator[bot] commented on GitHub (May 10, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#23723](https://github.com/open-webui/open-webui/issues/23723) **issue: Image generation enabled doesn't respect setting** *Related because it is also about image generation state not being respected. That issue reports the feature being automatically turned off when unavailable, while this one reports the inverse mismatch: `image_gen` remains exposed even when image generation is disabled.* *by xNissX233 · `bug`* 2. 🟣 [#24265](https://github.com/open-webui/open-webui/issues/24265) **issue: Image generation reports aiohttp ServerDisconnectedError as HTTP 400** *Related because both issues concern image generation tool-call failures surfacing as HTTP 400. This one specifically documents the same 400-class error wrapping for backend image-generation failures.* *by belugaming · `bug`* 3. 🟣 [#22545](https://github.com/open-webui/open-webui/issues/22545) **issue: Certain Builtin Tools Not Available** *Related because it shows builtin tool visibility depending on integration/menu state. It is not about image generation specifically, but it matches the broader problem of enabled/disabled builtin tools not matching what the model can actually see.* *by pdp-oui · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-18 06:04:57 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 10, 2026):

We do not have image_gen as built-in tool.

<!-- gh-comment-id:4415819553 --> @tjbck commented on GitHub (May 10, 2026): We do not have `image_gen` as built-in tool.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#107317
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?