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
0.8.6
Ollama Version (if applicable)
Latest
Operating System
Win
Browser (if applicable)
No response
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
On prior versions, there was some fixes that made it that each new image that been uploaded to chat can be edited by the LLM, but on latest version whenever user upload a second image to chat and ask for editing, the LLM references the old image that he edited before.
Actual Behavior
LLM always referenced the first image that has been already edited
Steps to Reproduce
Upload one image and ask for a change and then upload the second image and ask for a different change
Checked with many LLMs and with comfyui as the image backend
Logs & Screenshots
Additional Information
No response
Originally created by @iChristGit on GitHub (Feb 23, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21806
### 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
0.8.6
### Ollama Version (if applicable)
Latest
### Operating System
Win
### Browser (if applicable)
_No response_
### 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
On prior versions, there was some fixes that made it that each new image that been uploaded to chat can be edited by the LLM, but on latest version whenever user upload a second image to chat and ask for editing, the LLM references the old image that he edited before.
### Actual Behavior
LLM always referenced the first image that has been already edited
### Steps to Reproduce
Upload one image and ask for a change and then upload the second image and ask for a different change
Checked with many LLMs and with comfyui as the image backend
### Logs & Screenshots
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-18 04:59:37 -05:00
<!-- gh-comment-id:3947942939 -->
@iChristGit commented on GitHub (Feb 23, 2026):
https://github.com/open-webui/open-webui/issues/20754
Older related issue, was working on 0.8.0
how do you use these models? For the builtin image editing, it works fine for me.
<!-- gh-comment-id:3954904603 -->
@Classic298 commented on GitHub (Feb 24, 2026):
how do you use these models? For the builtin image editing, it works fine for me.
how do you use these models? For the builtin image editing, it works fine for me.
First uploaded image indeed get edited (Using native tool calling gpt:oss-20b and comfyui backend)
Second image user uploads do not go to the LLM, it keeps using the first uploaded image, user can just copy the ID of the new image and give it to LLM and it does work, so its just about passing the correct "image_url" id string.
<!-- gh-comment-id:3955996671 -->
@iChristGit commented on GitHub (Feb 25, 2026):
> how do you use these models? For the builtin image editing, it works fine for me.
First uploaded image indeed get edited (Using native tool calling gpt:oss-20b and comfyui backend)
Second image user uploads do not go to the LLM, it keeps using the first uploaded image, user can just copy the ID of the new image and give it to LLM and it does work, so its just about passing the correct "image_url" id string.
We'll either need a more detailed instructions on how to reproduce, or a screenrecording, we're unable to reproduce.
<!-- gh-comment-id:3961542116 -->
@tjbck commented on GitHub (Feb 25, 2026):
We'll either need a more detailed instructions on how to reproduce, or a screenrecording, we're unable to reproduce.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @iChristGit on GitHub (Feb 23, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21806
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
0.8.6
Ollama Version (if applicable)
Latest
Operating System
Win
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
On prior versions, there was some fixes that made it that each new image that been uploaded to chat can be edited by the LLM, but on latest version whenever user upload a second image to chat and ask for editing, the LLM references the old image that he edited before.
Actual Behavior
LLM always referenced the first image that has been already edited
Steps to Reproduce
Upload one image and ask for a change and then upload the second image and ask for a different change
Checked with many LLMs and with comfyui as the image backend
Logs & Screenshots
Additional Information
No response
@iChristGit commented on GitHub (Feb 23, 2026):
https://github.com/open-webui/open-webui/issues/20754
Older related issue, was working on 0.8.0
@Classic298 commented on GitHub (Feb 24, 2026):
how do you use these models? For the builtin image editing, it works fine for me.
@iChristGit commented on GitHub (Feb 25, 2026):
First uploaded image indeed get edited (Using native tool calling gpt:oss-20b and comfyui backend)
Second image user uploads do not go to the LLM, it keeps using the first uploaded image, user can just copy the ID of the new image and give it to LLM and it does work, so its just about passing the correct "image_url" id string.
@tjbck commented on GitHub (Feb 25, 2026):
We'll either need a more detailed instructions on how to reproduce, or a screenrecording, we're unable to reproduce.