I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
0.6.28
Ollama Version (if applicable)
No response
Operating System
Debian 12
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
Loading the root url is fast. Adding tools is also fast.
Actual Behavior
When navigating to the root url, the chat prompt is dealyed by a spinner. When trying to add a tool, those are also delayed by a spinner.
This is because the call to /api/v1/tools/ takes about 10s and is called both when navigating to the root and when opening the + menu to add tools to the chat.
Steps to Reproduce
Install and run via docker. if it matters the host is debian 12. Potentially relevant I have WEBUI_AUTH=False set.
(Probably) Connect some AI provider, in my case ollama just to make sure that the tools get called
Add an external tool via Admin Panel > Settings > External Tools . I added GitLab with these settings:
Save that and then in a new tab go to the root openwebui view.
Observe undesired behavior. Also open devtools and observe the very slow tools endpoint
Go back to tools and disable the gitlab tool
Problem disappears
Logs & Screenshots
No relevant browser errors were found
For Docker logs, they are far too large, but what I can see in them is that EVERY time the tools endpoint is hit, openwebui is converting the YAML to JSON and dumping it to the logs. Considering the YAML is ~2MB this is not a cheap operation.
Additional Information
I suspect the problem can be solved by asynchronously updating the tool definition, and perhaps not updating it on every call. GitLab has a cache-control header and responds to the If-None-Match header.
Perhaps also a feature request is in order to selectively provide endpoints because, well, 2MB of external tool is probably too much for local LLMs and it has so many endpoints that I don't want to access, but for now the buggos!
Originally created by @jojo2357 on GitHub (Sep 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17522
### 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 am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.6.28
### Ollama Version (if applicable)
_No response_
### Operating System
Debian 12
### 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
Loading the root url is fast. Adding tools is also fast.
### Actual Behavior
When navigating to the root url, the chat prompt is dealyed by a spinner. When trying to add a tool, those are also delayed by a spinner.
This is because the call to `/api/v1/tools/` takes about 10s and is called both when navigating to the root and when opening the `+` menu to add tools to the chat.
### Steps to Reproduce
Install and run via docker. if it matters the host is debian 12. Potentially relevant I have `WEBUI_AUTH=False` set.
(Probably) Connect some AI provider, in my case ollama just to make sure that the tools get called
Add an external tool via Admin Panel > Settings > External Tools . I added GitLab with these settings:
| Setting | Value |
| --- | --- |
| Base Url | `https://gitlab.com` |
| Url Path | `/gitlab-org/gitlab/-/raw/master/doc/api/openapi/openapi_v2.yaml` |
| Auth | *Not Needed* |
| id + name + description | gitlab |
Save that and then in a new tab go to the root openwebui view.
Observe undesired behavior. Also open devtools and observe the very slow tools endpoint
Go back to tools and disable the gitlab tool
Problem disappears
### Logs & Screenshots
<img width="1862" height="244" alt="Image" src="https://github.com/user-attachments/assets/9d1b9eab-c139-46b9-8e92-94dde2e07b1e" />
No relevant browser errors were found
For Docker logs, they are far too large, but what I can see in them is that EVERY time the tools endpoint is hit, openwebui is converting the YAML to JSON and dumping it to the logs. Considering the YAML is ~2MB this is not a cheap operation.
<img width="1859" height="242" alt="The actual request to GitLab showing it is large" src="https://github.com/user-attachments/assets/6b9bad2d-520c-4812-afc0-961651832e1e" />
### Additional Information
I suspect the problem can be solved by asynchronously updating the tool definition, and perhaps not updating it on every call. GitLab has a `cache-control` header and responds to the `If-None-Match` header.
Perhaps also a feature request is in order to selectively provide endpoints because, well, 2MB of external tool is probably too much for local LLMs and it has so many endpoints that I don't want to access, but for now the buggos!
GiteaMirror
added the bug label 2026-05-18 03:16:27 -05:00
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 @jojo2357 on GitHub (Sep 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17522
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.6.28
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Loading the root url is fast. Adding tools is also fast.
Actual Behavior
When navigating to the root url, the chat prompt is dealyed by a spinner. When trying to add a tool, those are also delayed by a spinner.
This is because the call to
/api/v1/tools/takes about 10s and is called both when navigating to the root and when opening the+menu to add tools to the chat.Steps to Reproduce
Install and run via docker. if it matters the host is debian 12. Potentially relevant I have
WEBUI_AUTH=Falseset.(Probably) Connect some AI provider, in my case ollama just to make sure that the tools get called
Add an external tool via Admin Panel > Settings > External Tools . I added GitLab with these settings:
https://gitlab.com/gitlab-org/gitlab/-/raw/master/doc/api/openapi/openapi_v2.yamlSave that and then in a new tab go to the root openwebui view.
Observe undesired behavior. Also open devtools and observe the very slow tools endpoint
Go back to tools and disable the gitlab tool
Problem disappears
Logs & Screenshots
No relevant browser errors were found
For Docker logs, they are far too large, but what I can see in them is that EVERY time the tools endpoint is hit, openwebui is converting the YAML to JSON and dumping it to the logs. Considering the YAML is ~2MB this is not a cheap operation.
Additional Information
I suspect the problem can be solved by asynchronously updating the tool definition, and perhaps not updating it on every call. GitLab has a
cache-controlheader and responds to theIf-None-Matchheader.Perhaps also a feature request is in order to selectively provide endpoints because, well, 2MB of external tool is probably too much for local LLMs and it has so many endpoints that I don't want to access, but for now the buggos!