issue: edit_image cannot load this instance's own /api/v1/files URLs unless the host matches request.base_url

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 have checked whether this issue is already fixed on the dev branch or in the latest source.
• I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

0.11.1

Ollama Version (if applicable)

0.33.1

Operating System

Ubuntu 24.

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

The edit_image tool should be able to retrieve images from Open WebUI's own file storage without failing due to authentication, since this is an internal, same-instance request.

Actual Behavior

The fetch fails with a 400 error indicating the image could not be loaded, despite the URL being valid and correctly formatted, and despite the file being confirmed to exist and be accessible via the same endpoint when authenticated.

Steps to Reproduce

1. Configure Settings → Images → Image Editing with a self-hosted backend (in my case, ComfyUI) and a custom ComfyUI workflow (Flux Kontext).
2. Set Function Calling to a mode that exposes native system tools (Default/Native) for a vision-capable model.
3. Upload an image in a chat and ask the model to edit it (e.g., "remove X from this image").
4. Observe the model calling edit_image with image_urls pointing to http://<host>:<port>/api/v1/files/{file_id}/content.
5. The tool call returns: {"error": "400: [ERROR: Error loading image]"}.
6. Manually open the exact same URL in a logged-in browser tab — the image loads and downloads correctly.
7. (Optional, to confirm the auth hypothesis) Open the same URL in a private/incognito window with no active session — it fails to return the raw image.

Logs & Screenshots

2026-08-29 183419.774335-03002026-0..log

Additional Information

• Installation method: Docker / TrueNAS SCALE App
• Image editing backend: ComfyUI (self-hosted, custom workflow — Flux Kontext)
• Function Calling mode: Default
• Model used: Qwen3-VL-30B-A3B (via Ollama)
• The first attempts by the model used incorrect/hallucinated paths (e.g., /mnt/uploads/{filename}), which correctly returned 404. After manually supplying the correct /api/v1/files/{id}/content URL, the error changed from 404 (not found) to 400 (found, but failed to load as an image) — pointing specifically to an authentication or fetch-implementation issue rather than a URL-format issue.
• Happy to provide backend container logs for the failing request if useful.

Start by tracing the edit_image tool's handling of image_urls and the request to /api/v1/files/{file_id}/content, using the supplied reproduction steps and logs. Verify how authentication and request.base_url are applied when the URL targets the same Open WebUI instance; done means valid internal file URLs load successfully without requiring a matching host.