GitHub 需求雷达 Opportunity Radar

### 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 Docker ### Open WebUI Version 0.96 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### Browser (if applicable) Chrome ### 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 web search toggle is active and a question that requires current information is asked (e.g. "What's the weather in Milan today?"), the model should receive the search results as context and use them to formulate a response. This worked correctly in v0.9.5. ### Actual Behavior After upgrading from v0.9.5 to v0.9.6, web search results are fetched successfully from SearXNG (confirmed in logs: "added 9 items to collection web-search-...") but are not passed to the model as context. The model responds as if no search was performed. Toggle is active. SearXNG URL is correct. Worked in v0.9.5. Config: Docker, SearXNG self-hosted, OpenRouter models. ### Steps to Reproduce Prerequisites: - Open WebUI v0.9.6 running in Docker - SearXNG self-hosted running in Docker (accessible at http://host.docker.internal:8888) - Web search enabled in Admin Settings with SearXNG as provider - OpenRouter configured as model provider Steps to reproduce: 1. Open a new chat in Open WebUI v0.9.6 2. Enable the web search toggle in the chat 3. Ask a question that requires current web data (e.g. "What is the weather in Milan today?") 4. The model responds as if no search was performed, without using any search results Additional evidence: - Docker logs confirm that search IS being executed successfully: "added 9 items to collection web-search-e51138a673bc56ff486ee4baa6b0ad510636da0a3e865aaedcaf" - SearXNG returns valid JSON results when tested via curl from inside the Open WebUI container - The same configuration worked correctly in v0.9.5 before the upgrade - The issue occurs with multiple different models via OpenRouter Environment: - Host OS: Ubuntu 24.04 LTS - Docker version: latest - Search provider: SearXNG (self-hosted, Docker) - Model provider: OpenRouter - Browser: Chrome stable, Firefox ### Logs & Screenshots Docker logs showing web search is executed and results are stored: 2026-06-02 00:46:12.237 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:1412 - Using markdown header text splitter 2026-06-02 00:46:12.249 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:1490 - generating embeddings for web-search-e51138a673bc56ff486ee4baa6b0ad510636da0a3e865aaedcaf 2026-06-02 00:4

### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Open WebUI reconstructs chat history from stored `output` items and may **reinject reasoning/thinking** (e.g. `<think>...</think>`) back into the next-turn `messages` (via `convert_output_to_messages(..., raw=True)`). For some providers/models, once these tags appear in history, the model starts **imitating/amplifying** them (multiple/nested/variant thinking tags), which can eventually **break frontend reasoning parsing/rendering** (thinking blocks leak into normal text, duplicated blocks, malformed markdown/artifacts, etc.). ### Screenshots The content has been incorporated into the thought block: <img width="832" height="204" alt="Image" src="https://github.com/user-attachments/assets/1e0d71e4-254d-409b-9ed8-d06ed1464688" /> <img width="2010" height="542" alt="Image" src="https://github.com/user-attachments/assets/75e6199b-4834-4ff7-abd8-077123e1923f" /> The reason is: if you pass the thought process to the LLM with a <think> tag as the main text, the LLM will attempt to mimic it and also output a fake <think> tag. <img width="1606" height="168" alt="Image" src="https://github.com/user-attachments/assets/9562362f-8b00-4b21-bc90-293c0a8ac01f" /> ### Desired Solution you'd like - By default, Open WebUI should **NOT** reinject reasoning/thinking into the prompt history. - Users can opt-in per model if they explicitly need reasoning reinjection. ### Alternatives Considered Add a **model-level toggle** (advanced setting), e.g. `reinject_reasoning` / `include_reasoning_in_history`: - **Default: OFF** - When OFF: keep tool call structure, but do not add reasoning/thinking blocks back into `messages`. - When ON: preserve current behavior for users/providers that require it. ### Additional Context **Relevant code (for maintainers)** - `backend/open_webui/utils/middleware.py`: `process_messages_with_output()` uses `convert_output_to_messages(..., raw=True)` - `backend/open_webui/utils/misc.py`: `convert_output_to_messages(..., raw=True)` appends reasoning as `<think>...</think>`

### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description I want to develop a MCP server for a service that does not support OAuth / is not integrated with OAuth yet and supports only Basic Auth. For now, MCP configuration in Open WebUI supports supplying only the global API token to the server (and starting from 0.6.37 other custom headers thanks to #18918 ). I'd like to allow each user to supply their own credentials to work with the service through MCP server. ### Desired Solution you'd like As a user, I'd like to be able to use my own API key (and preferably set custom headers) when enabling the globally configured MCP server as a tool in the conversation - something like the scope configuration that happens when you enable OAuth MCP server as a user. Something like user valves, but for MCP / tools servers. I know that there is a possibility for each user to configure their own tools server but: 1) I want the overall configuration to be managed globally by the admin 2) There is no possibility to add MCP servers that way (they can be configured only globally) ### Alternatives Considered _No response_ ### Additional Context _No response_

### 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 Other ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) llama.cpp ### Operating System openweb UI docker container (k8s helm chart 14.8), llama.cpp on cachyos 0821c5fcfd729af70037bc1e9e60769d42c081ba ### Browser (if applicable) firefox 151 ### 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 I type in a simple query to chat. It searches and fails w/ the given logs. It should "just work". Last working version with my setup was 0.9.4 ### Actual Behavior <img width="1444" height="610" alt="Image" src="https://github.com/user-attachments/assets/9174e89d-757a-4cab-80b9-3bb2b59cf043" /> (see pod logs too) ### Steps to Reproduce 1. cachyos w/ the llama.cpp server version indicated 2. run `unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q6_K` 3. searxng hooked up, container version/tag `2026.2.16-8e824017d` 4. authentik OIDC version `2026.2.2` 5. hook up into openweb-ui 0.9.6 6. send a query to chat ### Logs & Screenshots ``` 2026-06-04 14:30:16.113 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:1536 - embeddings generated 468 for 468 items 2026-06-04 14:30:16.123 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:1548 - adding to collection web-search-63d4d8854c3969446c9fc30eca4c719b7dac905c7ebc7c359ae6 2026-06-04 14:30:17.138 | INFO | open_webui.retrieval.vector.dbs.pgvector:insert:331 - Inserted 468 items into collection 'web-search-63d4d8854c3969446c9fc30eca4c719b7dac905c7ebc7c359ae6'. 2026-06-04 14:30:17.142 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:1554 - added 468 items to collection web-search-63d4d8854c3969446c9fc30eca4c719b7dac905c7ebc7c359ae6 2026-06-04 14:30:18.356 | ERROR | open_webui.main:process_chat:2060 - Error processing chat payload: Invalid url value ``` <img width="1444" height="610" alt="Image" src="https://github.com/user-attachments/assets/e57d2394-a993-4a74-8815-7b69e2840750" /> ### Additional Information my helm charts here: https://github.com/chr0n1x/rpi-talos/tree/main/k8s/argocd-deploy last working helm **CHART** version `14.4.0` https://github.com/chr0n1x/rpi-talos/commit/04dcad5dd2d4aab56bf85f0b42978061126b4b17 llama.cpp server command: ```sh llama-server \ -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q6_K \ --n-cpu-moe 10 \ --host :: \ --port 8000 \ --n-gpu-layers all --ctx-size 250000 \ --cache-type-v q8_0 --cache-type-k q8_0 \ --mlock \ --flash-attn on \ --threads-batch 8 --th

### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.15 (latest dev) ### Ollama Version (if applicable) _No response_ ### Operating System MacOS 15.5 ### Browser (if applicable) Edge 133 ### 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 1. OpenWebUI with direct connection mode enabled 2. Multiple backend workers (workers > 1) 3. WebSocket + SSE communication flow ### Actual Behavior When using "direct connection" mode with multiple backend workers, chat requests may timeout due to WebSocket and API request routing to different worker instances. 1. Requests get stuck without responses 2. Eventually timeout with error messages 3. Issue occurs intermittently when multiple workers are deployed ### Steps to Reproduce 1. Configure OpenWebUI with multiple workers (workers > 1) .env ``` ENABLE_WEBSOCKET_SUPPORT=true WEBSOCKET_MANAGER=redis REDIS_URL=redis://default:password@localhost:6379/1 WEBSOCKET_REDIS_URL=redis://default:password@localhost:6379/1 ``` ```bash $ uvicorn open_webui.main:app --host 0.0.0.0 --port 8080 --forwarded-allow-ips '*' --log-config ./uvicorn_config.json --workers 8 ``` 2. Enable direct connection mode 3. Send direct connection chat request 4. Observe that some requests timeout without responses ### Logs & Screenshots  ### Additional Information The current architecture has the following flow: 1. Frontend sends request to `/api/v1/completions` 2. Backend responds via WebSocket, instructing frontend to send SSE request to direct connection address `/completions` 3. Frontend forwards received data back through WebSocket 4. Backend starts listening for WebSocket messages from the initial request **Problem**: When `workers > 1`, the WebSocket connection and the `/api/v1/completions` API request may be routed to different worker instances, causing the system to wait indefinitely for responses that will never arrive.

### 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 Docker ### Open WebUI Version v0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### 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 After editing an Azure OpenAI connection in Admin Panel → Settings → Connections (e.g. adding or removing a model ID), the connection should continue to work normally and models should be listed correctly. ### Actual Behavior After saving any change to an Azure OpenAI connection, all Azure models stop loading with the following error: ``` ERROR | open_webui.routers.openai:get_models:685 - Unexpected error: External Error: {'code': '404', 'message': 'Resource not found'} ``` The issue affects all connections on the instance. The UI shows "Not resource found" on a new chat, and any attempt to recreate the connection also fails immediately. ### Steps to Reproduce 1. Have a working Azure OpenAI connection configured in Open WebUI (with azure: true in api_configs) 2. Go to Admin Panel → Settings → Connections 3. Edit the Azure connection (e.g. add or remove a model ID from the list) 4. Save the connection 5. Open WebUI rewrites the connection config replacing "azure": true with "provider": "azure" and drops the azure flag entirely 6. All Azure models now return 404 Resource not found This was also reproduced simply by upgrading Open WebUI to v0.9.5, which rewrites the connection config on startup. ### Logs & Screenshots In open_webui/routers/openai.py, the get_models function branches based on the azure flag in api_config: ``` if api_config.get('azure', False): # Returns model_ids directly from config — no HTTP call made models = { 'data': api_config.get('model_ids', []) or [], 'object': 'list', } else: # Falls through to a generic HTTP GET to {url}/models # This endpoint does not exist on Azure → 404 async with session.get(f'{url}/models', ...) as r: ... ``` When the UI saves a connection with provider: "azure" but without azure: true, the code falls into the else branch and makes an HTTP GET to {base_url}/models, which is not a valid Azure OpenAI endpoint, resulting in a 404. Before edit: api_configs["0"] contains "azure": true → works correctly After edit: api_configs["0"] contains "provider": "azure" but no "azure": true → broken Logs : ``` 2026-05-26 09:33:21.167 | ERROR | open_webui.routers.openai:get_models:685 - Un

### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description When using the Pyodide code interpreter, files uploaded via the normal chat input automatically appear at `/mnt/uploads/` and the model can immediately access them with code. This works seamlessly. When using Open Terminal instead, files uploaded via the normal chat input go into Open WebUI's internal storage (with RAG extraction), but they never appear on the terminal's filesystem. The model gets terminal tools like `execute_command` and `read_file`, but can't find the uploaded files. Users can work around this by uploading through the Files tab in the sidebar, but there's no indication that the normal upload won't work. This creates a confusing experience — a user connects a terminal, uploads a CSV via the chat input, asks the model to analyze it, and the model can't find the file. With Pyodide it just works; with Open Terminal it silently doesn't. ### Desired Solution you'd like When a terminal is connected, uploaded files could be synced to the terminal's filesystem (via its `/files/upload` API) so the model can access them through terminal tools — similar to how Pyodide automatically loads them into `/mnt/uploads/`. A smaller improvement would be to surface a hint or redirect to the Files tab when a user uploads a file with a terminal connected. As a related UX note: auto-connecting to the terminal when only one is configured (currently requires clicking the cloud icon on every new chat) would also reduce friction. ### Alternatives Considered - Uploading files exclusively through the Files tab in the sidebar — works, but is non-obvious and a separate flow from the standard chat upload. - Using the Pyodide code interpreter instead — handles file uploads well, but lacks a real Linux environment, persistent filesystem, networking, and full package support. - Disabling the `file_context` model capability to skip RAG injection — files still go to Open WebUI storage, not the terminal filesystem. ### Additional Context The Pyodide file sync works because the middleware sends uploaded file references back to the browser via the `execute:python` socket event, the frontend fetches the file content via `getFileContentById()`, and loads it into the Pyodide WASM filesystem. There's no equivalent pipeline for Open Terminal.

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System windows 10 ### 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 A skill attached to a model via meta.skillIds should: - Appear in the system prompt only as a manifest entry (<available_skills> → id/name/description). - Have its full content loaded on demand by the model calling the view_skill built-in tool. - Full-content injection should be reserved for skills the user explicitly selects in the chat (via $-mention or the integrations menu toggle). ### Actual Behavior - The full skill content is injected into the system prompt on every request, even when the skill is only attached at the model level and was never explicitly selected by the user. - The view_skill tool is never registered/offered, so it cannot be called (with native function calling and builtin_tools enabled.) - For models with larger skills, this makes skills effectively unusable: every request balloons the context with full skill content instead of a small manifest, blowing up token usage (and cost/latency) and risking context-limit errors. ### Steps to Reproduce 1. Open OWUI, add a skill 2. Attach skill to a model (Admin Settings -> Models -> Model Builder), turn on Builtin / native FC. 3. Prompt the model with something that should invoke the skill 4. Notice no tool call is made to read skill, skill is already in context You can also just make a very large skill with junk data, attach it to a model, and notice that skill context is injected into chat with a 'hello' prompt. It will not be possible to invoke 'View Skill' ### Logs & Screenshots No errors ### Additional Information _No response_

### 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.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System linux ### Browser (if applicable) firefox ### 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 Openwebui should boot. ### Actual Behavior Openwebui fails to boot with ValueError: No embedding model is loaded. Set RAG_EMBEDDING_MODEL to a valid SentenceTransformer model name, or configure an external RAG_EMBEDDING_ENGINE (ollama, openai, azure_openai). ### Steps to Reproduce Run 0.9.5 it works Run 0.9.6 it doesn't ### Logs & Screenshots [log.0.9.5.works.txt](https://github.com/user-attachments/files/28532148/log.0.9.5.works.txt) [log.0.9.6.fail.txt](https://github.com/user-attachments/files/28532152/log.0.9.6.fail.txt) ### Additional Information _No response_

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) 0.30.0 and 0.23.0 ### Operating System docker ### 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 Text in UI, ollama works with its self. Yesterday was working, updated an hour ago and nothing. I don't see much API in the logs never chat complete. ### Actual Behavior Nothing, stuck on loading in UI ### Steps to Reproduce Update, use ollama ### Logs & Screenshots Ollama 0.23.0-rc0 (working yesterday) ``` source=server.go:1432 msg="llama runner started in 2.31 seconds" 172.17.0.1 | POST "/api/chat" 172.17.0.1 | POST "/api/chat" 172.17.0.1 | GET "/api/tags" 172.17.0.1 | GET "/api/ps" 172.17.0.1 | GET "/api/tags" 172.17.0.1 | GET "/api/ps" 172.17.0.1 | POST "/api/chat" ``` OWUI ``` GET /_app/immutable/nodes/3.Rf483QC1.js HTTP/1.1" 304 GET /_app/immutable/nodes/9.BU7GWhNy.js HTTP/1.1" 304 GET /ollama/api/version HTTP/1.1" 200 GET /api/version/updates HTTP/1.1" 200 GET /_app/version.json HTTP/1.1" 304 ``` edit: after 10 minutes uvicorn.protocols.http.httptools_impl:send:483 - IP - "POST /api/chat/completions HTTP/1.1" 200 How ever it still "loading" in UI ### Additional Information _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description ## Summary Open WebUI does not support PostgreSQL authentication via short-lived tokens (e.g. Azure Managed Identity / Azure AD token-based authentication for Azure Database for PostgreSQL). The `DATABASE_URL` is captured once at process startup and baked into the SQLAlchemy engine. When the token expires (~1 hour for Entra tokens), all new database connections fail with an authentication error and the application cannot recover without a full process restart. ## Background / Use Case When deploying Open WebUI on an Azure VM with a Managed Identity, the recommended (and in many organisations, mandatory) authentication pattern for Azure Database for PostgreSQL is: 1. Fetch a short-lived OAuth2 access token from the Azure IMDS endpoint 2. Use that token as the PostgreSQL password in the connection string 3. Periodically refresh the token before it expires (~60 min lifetime) This is the zero-credential, zero-secret authentication pattern — no passwords stored anywhere, fully auditable, and enforced by Azure security policy in many enterprise environments. The same pattern applies to: - AWS RDS IAM authentication (15-minute tokens) - GCP Cloud SQL IAM authentication - Any PostgreSQL deployment using pg_ident / LDAP / PAM with rotating credentials ## Current Behaviour In `backend/open_webui/env.py`: DATABASE_URL = os.getenv('DATABASE_URL', f'sqlite:///{DATA_DIR}/webui.db') In `backend/open_webui/internal/db.py`, the async engine is created immediately at module import time using the captured `DATABASE_URL` string. The connection URL — including the token embedded as the password — is permanently fixed for the lifetime of the process. SQLAlchemy's `pool_pre_ping=True` detects dead TCP connections and creates new ones, but those new connections use the same expired token, so they fail authentication too. **There is no code path that re-reads `DATABASE_URL` from the environment after startup.** The only workaround today is to restart the uvicorn process every ~45 minutes, which causes a service interruption for all connected users. ### Proposed Solution ### Option A — `DATABASE_PASSWORD_CMD` (simplest) When set, Open WebUI executes this shell command each time a new connection is needed and uses its stdout as the password, similar to how Docker secrets work or how `.pgpass` works: DATABASE_PASSWORD_CMD=curl -sH "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://ossrdbms-aad.database.windows.net" \ | python -c "import sys,json; print(json.load(sys.stdin)['access_token'])" ### Option B — SQLAlchemy `creator` function (most robust) SQLAlchemy's `create_engine()` / `create_async_engine()` accepts a `creator` callable that is invoked for each new connection. This is the canonical pattern for token-based authentication: # In db.py, for PostgreSQL connections when DATABASE_ROTATING_CREDENTIALS=true: import os, psycopg from urllib.parse import urlparse def _make_pg_creator(base_url: str): def creator(): # Re-read the full URL (or just the password) at connection time. # An external refresh script updates DATABASE_URL in the environment. current_url = os.environ.get('DATABASE_URL', base_url) p = urlparse(current_url) return psycopg.connect( host=p.hostname, port=p.port or 5432, dbname=p.path.lstrip('/'), user=p.username, password=p.password, sslmode='require', ) return creator if _is_postgres_url(DATABASE_URL) and os.getenv('DATABASE_ROTATING

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 with WSL 2 (Ubuntu 26.04 LTS) ### Browser (if applicable) Edge 149.0.4022.52 ### 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 After [PR #24690](https://github.com/open-webui/open-webui/pull/24690) (merged into v0.9.6), `handle_authorize` should include the `scope` parameter in the OAuth authorize URL when using MCP with OAuth 2.1 (Static) and an IdP that requires scopes (e.g. Azure Entra ID). ### Actual Behavior `handle_authorize` (`open_webui/utils/oauth.py`, ~line 960) generates an authorize URL **without** `scope`, causing the IdP to reject the request (Entra: `AADSTS900144`). Debug logging at `handle_authorize` proves: ``` client_info.scope=None client_kwargs={'follow_redirects': True, 'token_endpoint_auth_method': 'client_secret_post'} kwargs={} ``` The scope is correctly discovered from `/.well-known/oauth-protected-resource` and correctly built in `get_oauth_client_info_with_static_credentials` ([PR #24690](https://github.com/open-webui/open-webui/pull/24690)), but is **not present** in `client_info` when `handle_authorize` runs. Hardcoding `kwargs["scope"]` before `authorize_redirect` immediately resolves the issue (Entra accepts the request). Additionally, `_preflight_authorization_url` calls `create_authorization_url(redirect_uri=redirect_uri)` **without** `scope`, which causes the preflight check against Entra to fail with the same error before `handle_authorize` is even reached. **File**: `open_webui/utils/oauth.py` The scope is lost in the persistence/loading chain: 1. **Build** ✅ — `get_oauth_client_info_with_static_credentials` (~line 529) builds `OAuthClientInformationFull` with `scope` from `get_protected_resource_metadata` (PR #24690) 2. **Persist** ✅ — The `OAuthClientInformationFull` object is encrypted and stored as a blob in the connection config (`info.oauth_client_info`) 3. **Load** ❌ — `ensure_client_from_config` (~line 691) calls `resolve_oauth_client_info` which decrypts the blob into a dict, then constructs `OAuthClientInformationFull(**dict)`. If the blob was created **before** PR #24690, the `scope` field is missing from the dict → `scope=None` 4. **Register** ❌ — `add_client` (~line 633) only sets `client_kwargs.scope` if `oauth_client_info.scope` is truthy: `**({'scope': oauth_client_info.scope} if oauth_client_info.scope else {})`

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 26.04 ### 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 When uploading a file whose name is too long to store, the UI should show a clear, actionable error such as: "File name is too long (maximum 218 bytes). Please rename the file and try again." — or the upload should succeed by truncating the on-disk name (the original name is already stored separately in the file record's meta.name). ### Actual Behavior The upload fails with a generic toast in the top-right of the chat page: [ERROR: Error uploading file] The user gets no hint that the filename length is the problem. The real cause (OSError: ENAMETOOLONG) is only visible in the server logs. This is especially confusing for CJK users: because the 255-byte filesystem limit applies to UTF-8 bytes (3 bytes per CJK character), a perfectly normal-looking ~73-character Chinese/Japanese document title triggers the failure. ### Steps to Reproduce Environment: any default Open WebUI install (no special configuration needed). Reproduced on v0.9.6 with the default LocalStorageProvider (STORAGE_PROVIDER unset). S3/GCS/Azure providers are equally affected because they write to local storage first (backend/open_webui/storage/provider.py). 1. Create a small test file with a 250-character name (254 bytes including ".txt"): python3 -c 'open("a"*250 + ".txt", "w").write("test")' (Alternative, CJK variant — 73 chars = 223 bytes: python3 -c 'open("文"*73 + ".txt", "w").write("test")' ) 2. Log in to the Web UI as any user, open a chat with any model. 3. Click the "+" button in the message input → "Upload Files", and select the file created in step 1 (drag-and-drop reproduces it too). 4. Observe the toast "[ERROR: Error uploading file]" appear in the top right; the file chip disappears from the input. API-level reproduction (no UI needed): curl -s -w "\nHTTP %{http_code}\n" -X POST "http://localhost:8080/api/v1/files/" \ -H "Authorization: Bearer $TOKEN" \ -F "file=@test.txt;filename=$(python3 -c 'print("a"*250+".txt")')" Returns: {"detail": "Error uploading file"} with HTTP 400. Note the threshold: failures begin at original filenames > 218 bytes, not 255, because upload_file_handler (backend/open_webui/routers/files.py) prefixes the st

### 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. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker (Kubernetes) ### Open WebUI Version v0.9.6 (v1.13.0 deployment) ### Ollama Version (if applicable) _No response_ ### Operating System Linux (Ubuntu 22.04) ### Browser (if applicable) Chrome ### 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 Docker volume/bind mount used in my setup.** ### Description The admin feedback list endpoint `GET /api/v1/evaluations/feedbacks/list?page=1&limit=5` returns HTTP 502. The root cause is in `backend/open_webui/models/feedbacks.py`, method `get_feedback_items()` at line 254: ```python count_result = await db.execute(select(func.count()).select_from(stmt.subquery())) total = count_result.scalar() ``` The `stmt` at this point is a `select(Feedback, User).join(User, ...)` with potential ORDER BY on JSON fields (e.g., `Feedback.data['model_id'].as_string()`). Wrapping this complex JOIN + JSON-ORDER statement in `.subquery()` and then counting it can produce invalid SQL or cause database errors, especially with PostgreSQL. ### How to reproduce 1. Deploy Open WebUI v0.9.6 with PostgreSQL backend 2. Login as admin 3. Navigate to Admin Panel → 模型评价 → 反馈 (Evaluations → Feedback) 4. The page shows a loading spinner indefinitely 5. Check the API: `GET /api/v1/evaluations/feedbacks/list?page=1&limit=5` returns 502 ### Related context - The user-scoped endpoint `/api/v1/evaluations/feedbacks/user?page=1&limit=5` works fine (returns 200 with `{items:[], total:0}`) - The leaderboard endpoint also works correctly (returns 200 with 88 entries) - The bug was introduced in commit `25898116ea` (async DB migration, April 12, 2026) which converted the sync `query.count()` to the async subquery pattern ### Suggested fix Replace the subquery count with a lightweight count that avoids wrapping the full JOIN + ORDER BY statement: ```python # Build a separate count statement with just the JOIN and filters, no ORDER BY count_stmt = ( select(func.count(Feedback.id)) .join(User, Feedback.user_id == User.id) ) # Re-apply only the WHERE filters (not ORDER BY) from the original stmt if filter: model_id = filter.get('model_id') if model_id: count_stmt = count_stmt.filter(Feedback.data['model_id'].as_string() == model_id) count_result = await db.execute(count_stmt) total = count_result.scalar() ``` This mirrors the pattern used in `backend/open_webui/models/knowledge.py` (lines 360-383) where the count query was correctly separated from the main query during the same async migration. ### Related issues - #22206 (OOM on bulk endpoints) — related but different root cause. That issue is about loading full datasets into memory; this is a SQL generation bug in the count query.

### 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 Docker ### Open WebUI Version v0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System MacOS Sonoma ### Browser (if applicable) Zen Browser 1.19.12b (Firefox 150.0.2) (aarch64) ### 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 I submit a prompt, the response starts generating and completes successfully. ### Actual Behavior The response continues for a variable amount of tokens before interrupting with the following UI error: ```text Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'> ``` Re-generating the response incurs in the same error. The logs show a similar error: ```text ERROR | open_webui.main:process_chat:2013 - Error processing chat payload: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'> ``` Just once, no other relevant error log can be found around it. ### Steps to Reproduce Details: - Replicated with v0.9.3, v0.9.4, and v0.9.5. I don't have a backup for pre-v0.9.3 so I can't rollback the breaking release with DB migrations. - Using a custom agent based on GLM-5.1 from Z.ai (`open.bigmodel.cn` OpenAI-compatble endpoint), with streaming and native function calling enabled. - It usually starts happening after the first couple of prompts in a chat, with 20/30k tokens of context including multiple tool calls. Failing responses do start, generate a few lines of output, then drop. ### Logs & Screenshots UI error: <img width="945" height="95" alt="Image" src="https://github.com/user-attachments/assets/998c4e9e-bd2b-41ec-b0b7-7a52dd9ce6f6" /> Logs snippet, redacted: ```text 2026-05-11T02:52:18.708990072+02:00 2026-05-11 02:52:18.708 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:53:19.340890117+02:00 2026-05-11 02:53:19.340 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:53:44.424531037+02:00 2026-05-11 02:53:44.424 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/chat/completions HTTP/1.1" 200 2026-05-11T02:53:44.485731402+02:00 2026-05-11 02:53:44.485 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/v1/chats/<UUID> HTTP/1.1" 200 2026-05-11T02:53:44.503369741+02:00 202

### 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. Searched terms include `DEFAULT_MODEL_PARAMS`, `default parameters max_tokens`, `default model params`, `max_tokens not applied`, `default sampling params`, `apply_model_params_to_body`, `model_info_params`, `global default ignored`. Closest existing reports are not duplicates: - #21837 / discussion #21839 — `DEFAULT_MODEL_PARAMS` ignored when set via env var with `ENABLE_PERSISTENT_CONFIG=false` (env-parse path, different code path; in this report the value IS persisted and visible via `/api/v1/configs/export`). - #19214 — chat-control overrides being beaten by per-model admin defaults (precedence inversion, opposite direction; in this report the per-chat overrides do work — only the global default is dropped). - #17131 — per-user "Settings → Advanced Parameters" sending args that break some models (different UI surface, different field on the config). - Discussion #8368 — user-settings context limit not applied to Ollama (v0.5.4, user-level not admin-level, only Ollama). ### Installation Method Docker ### Open WebUI Version `main` (verified against current HEAD `d47c88f`, 2026-05-20). The bug is also present in the latest release v0.9.5. ### Ollama Version (if applicable) Not applicable — bug is server-side and reproducible against any OpenAI-compatible upstream that honours `max_tokens`. The Ollama router has the same shape and is likely affected (see "Logs & Code references" below). ### Operating System Not OS-dependent — bug is in `backend/open_webui` Python code. ### Browser (if applicable) Not applicable — bug is server-side. Outbound chat-completion request payload is wrong regardless of client. ### 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**. Relevant configuration: `DEFAULT_MODEL_PARAMS` set via the admin UI ("Settings → Models → Default Parameters"), persisted to the config table (visible via `/api/v1/configs/export` as `models.default_params.*`). No env-var overrides for `DEFAULT_MODEL_PARAMS`. The active model's stored `info.params` JSON does NOT contain a `max_tokens` key (only e.g. `function_calling`, `custom_params`). Provider is an OpenAI-compatible endpoint (also reproduces against Amazon Bedrock via the bedrock-access-gateway, which simply forwards `max_tokens`). ### Expected Behavior Setting `Default Parameters → max_tokens` in the admin UI should apply that value to outbound chat-completion requests for any model whose own `params` object does not specify `max_tokens`. The intuitive precedence (which the admin UI implies) is: ``` per-chat override > per-model `params` > global `DEFAULT_MODEL_PARAMS` > hardcoded fallback ``` This should hold for all provider sampling parameters: `max_tokens`, `temperature`, `top_p`, `top_k`, `frequency_penalty`, `presence_penalty`, `seed`, `stop`, etc. ### Actual Behavior The global default is persisted correctly and even merged into an in-memory `model_info_params` dict in `main.py`, but the merged d

# Socket.IO emits grow O(N²) during LLM streaming: full message is re-serialized on every token Thanks to @ShirasawaSama !! ## Simple TLDR: TLDR: Open WebUI re-sends and re-renders the whole chat on every single token, so CPU, RAM, bandwidth, and Redis all explode exponentially in CPU and memory and bandwith usage as the conversation grows. Gets even worse with high concurrency and long chats. ## Summary During an LLM streaming response, the backend re-serializes the **entire** accumulated output (all prior text, reasoning blocks, tool calls, images, sources) into one HTML string and emits it via Socket.IO **on every SSE event**. As a response grows, each WebSocket frame grows with it, so total bytes on the wire for an N-token response scale as **O(N²)**. The cost is then amplified by Socket.IO's Redis pub/sub fan-out (× Redis nodes × workers) and again by the frontend Markdown parser, which re-parses the whole content string on each update. This is visible in devtools → Network → WS frames on any long streaming response: `chat:completion` frame sizes climb steadily (e.g. 3014 → 3037 → 3073 → 3092 → … bytes) as the response streams in. ## Reproduction 1. Run the current `dev` branch backend and frontend. 2. Open any chat and send a prompt that produces a long response (e.g. "write a 2000-word essay about X"). 3. Open browser devtools → Network → filter WS → click the Socket.IO frame → watch the "Messages" tab. 4. Observe each `events` frame carrying `type: "chat:completion"` — note that the `content` field grows by the *entire response so far* every single frame, not by the delta. 5. For extra impact: enable a model with reasoning or tool calling. Every text token re-sends the reasoning block and every prior tool call. ## Root cause All primary offenders live in `backend/open_webui/utils/middleware.py` inside `streaming_chat_response_handler` / `stream_body_handler`. #### `serialize_output()` — re-serializes the whole output list on every call `backend/open_webui/utils/middleware.py:404-453` ```python def serialize_output(output: list) -> str: """ Convert OR-aligned output items to HTML for display. For LLM consumption, use convert_output_to_messages() instead. """ content = '' # ... loops EVERY item in the output list (text, function_call, # function_call_output, reasoning, ...) and concatenates them into one # HTML string, every time it's called. for idx, item in enumerate(output): ... ``` #### `full_output()` — always cumulative `backend/open_webui/utils/middleware.py:3603-3604` ```python def full_output(): return prior_output + output if prior_output else output ``` #### Tool-call emit — full re-serialize on each tool-call delta `backend/open_webui/utils/middleware.py:3872-3879` ```python await event_emitter( { 'type': 'chat:completion', 'data': { 'content': serialize_output(full_output() + pending_fc_items), }, } ) ``` #### Main text-delta emit — full re-serialize on each token `backend/open_webui/utils/middleware.py:4080-4106` ```python if ENABLE_REALTIME_CHAT_SAVE: await Chats.upsert_message_to_chat_by_id_and_message_id( metadata['chat_id'], metadata['message_id'], { 'content': serialize_output(full_output()), 'output': full_output(), }, ) else: data = { 'content': serialize_output(full_output()), } if delta: delta_count += 1 last_delta_data = data if delta_count >= delta_chunk_size: await flush_pending_delta_data(delta_chunk_size) ``` #### `delta_chunk_size` only batches frequency, not payload size `backend/open_webui/utils/middleware.py:3645-3663` The existing `delta_chunk_size` / `flush_pending_delta_data` mechanism reduces *how often* emits are sent, but each emit still carries `serialize_output(full_output())` — i.e. the full blob. So increasing `delta_chunk_size` trades latency

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) 0.30.5 ### Operating System Debian 13 ### Browser (if applicable) Brave ### 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 I have always seen a green dot in the language model selection drop down box indicating which model is loaded into Ollama/VRAM. now as of the latest version of OpenWebUI, it disappeared. Was this feature removed? i dont see any indication of that in the version log ### Actual Behavior A green icon showing which model is loaded in VRAM. This feature is both necessary and very important because. 1. without this you're blind, you dont know which model is hot and ready for use 2. you cant easily see or confirm if Ollama or your settings are correctly leaving the model in VRAM indefinitely(the way i like it) 3. you cant see if another user is constantly switching to a model different than the one your using 4. i detected an open firewall port and prevented unauthorized access solely because that green dot kept jumping around when i knew it should have been. Why would this feature be removed? It's obviously very useful and a fundamental troubleshooting indicator. ### Steps to Reproduce log into OpenWebUI and ask any model a question ### Logs & Screenshots model is loaded in memory via OpenWebUI query: <img width="626" height="62" alt="Image" src="https://github.com/user-attachments/assets/94f12a0e-2952-4617-a14c-6094d94b83c0" /> OpenWebUI shows no indication that this model is loaded despite being used just seconds earlier <img width="765" height="370" alt="Image" src="https://github.com/user-attachments/assets/8f38cf50-bc27-4d77-a760-993df8383f3e" /> ### Additional Information _No response_

### 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 Docker ### Open WebUI Version v0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### Browser (if applicable) Chrome 148.0 ### 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 using Open WebUI behind a reverse proxy for trusted header authentication, the reverse proxy server redirects the client to an identity provider if a request is made after the user session expires. This is expected behavior, and the browser should follow this redirect. The problem is that background requests are blocked from redirecting clients by default, so the user never reaches the identity provider for reauthentication. The frontend errors and sends the user to the “Open WebUI Backend Required” page. This problem has been brought up in a past issue here: #21072. A commit containing a fix was added here: 24370d5 which closed that issue, but the bug is still present. I had submitted a potential fix for that issue in a PR here: #22942 which contains some additional context. ### Actual Behavior As described above, users get sent to the “Backend Required” page and get stuck there when redirection to the identity provider fails. This only happens with unauthenticated requests to endpoints on the following paths: (/api, /ollama, /openai, /ws) since calls to those are only triggered by fetches and never explicitly navigated to by the user. Here’s an example browser log that shows the CORS violation: <img width="461" height="61" alt="Image" src="https://github.com/user-attachments/assets/dd6054e4-e973-4946-9989-8a7ec7a5e2f4" /> ### Steps to Reproduce You can reproduce the bug locally using the `docker-compose.yml` file and `nginx.conf` file included below. This setup works by using an nginx container to mock the reverse proxy and identity provider as shown in the nginx.conf file. When a background request comes in and the “authenticated” state is false, the reverse proxy redirects the client to the mock identity provider’s login endpoint. The “authenticated” state is then set to true, but only for 15 seconds. This essentially simulates a token with a short 15 second lifespan needed for observing the issue. Mock authentication is also only applied to background requests here in order to isolate the bug. This testing setup is used in the video below which highlights the bug. As shown in the video, you can try navigating to localhost:8080 after spinning up the docker compose and

## Bug Report ### Version Open WebUI v0.9.2 ### Description After upgrading from v0.9.1 to v0.9.2, MCP tool call results are being wrapped in a RAG citation template and displayed visibly in the chat as raw `<source>` blocks, instead of being processed silently and used by the model to compose a natural response. The chat displays a block like: ``` ### Task: Respond to the user query... <source> ... raw MCP tool result JSON ... </source> ``` This appears to be a side effect of the MCP asyncio cancellation fix introduced in v0.9.2. ### Steps to Reproduce 1. Register any MCP server in Admin Panel → Settings → Integrations 2. Assign it to a model via `toolIds` in the model config 3. Start a conversation and trigger a tool call (e.g. ask the model to read a file or fetch data) 4. Observe: tool result is rendered as a visible `### Task: Respond to the user query...` + `<source>` block in the chat ### Expected Behaviour MCP tool results are processed silently in the background. The model uses the tool result data to compose a natural language response, with no raw JSON or citation blocks visible to the user. ### Actual Behaviour The full RAG citation template is rendered visibly in the chat, including raw `<source>` XML blocks containing the tool result JSON. This makes MCP-enabled agents unusable as the chat is flooded with raw tool output. ### Environment - Open WebUI: v0.9.2 - MCP servers: FastMCP 3.x (Python), transport=`streamable-http`, `stateless_http=True` - Deployment: Docker container (colima VM on Mac Mini M4) - Models tested: claude-sonnet-4-6, claude-haiku-4-5, llama3.1:8b (all affected) ### Workaround Attempted Setting `RAG_TEMPLATE` env var to empty string does not persist — `PersistentConfig` reverts to the default template on every container restart, so this cannot be patched via environment variable. ### Additional Context This regression was not present in v0.9.1 (though v0.9.1 had the separate CPU/spinning conversation bug that v0.9.2 fixed). The MCP asyncio cancellation fix in v0.9.2 appears to have changed how tool results are routed through the response pipeline, causing them to pass through the RAG citation renderer instead of the tool result handler. All MCP tool calls fire correctly and return valid data — the issue is purely in how the results are presented in the UI.

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### 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 The pending screen should handle sign-out exactly like the main UI (UserMenu.svelte). It needs to hit the backend to invalidate the JWT, clear all cookies, and handle the OAuth redirect properly. ### Actual Behavior When a user logs in via OAuth but their account is pending (role is neither user nor admin), the AccountPending overlay is triggered https://github.com/open-webui/open-webui/blob/main/src/lib/components/layout/Overlay/AccountPending.svelte. Currently, the Sign Out button in AccountPending.svelte executes the following: ```typescript localStorage.removeItem('token'); location.href = '/auth'; ``` The user is not redirected to the OIDC end_session_endpoint, meaning their Google/Azure AD/etc. session remains active. ### Steps to Reproduce 1. Login via OAuth without user or admin role 2. Press signout button 3. Change user rights with OAuth provider (add user or admin role according to your actual setup) 4. Login again ### Logs & Screenshots **Patch example** <img width="1349" height="842" alt="Image" src="https://github.com/user-attachments/assets/75e2ab6e-2216-4144-a5a2-5152b110bd6f" /> ### Additional Information _No response_

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22 ### 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 With **Image Prompt Generation** enabled, both **create** (`image_generations`) and **edit** (`image_edits`) should use the refined prompt from the task model before calling the image backend. ### Actual Behavior - **Create path**: prompt is refined via `generate_image_prompt()`. - **Edit path**: `prompt` is set from `get_last_user_message()` and passed directly to `image_edits()`. ### Steps to Reproduce 1. Admin → **Images**: enable **Image Prompt Generation** and configure **Image Prompt Generation Prompt** (Interface / Tasks settings). 2. Enable **Image Edit** and configure an edit engine (e.g. ComfyUI edit workflow). 3. In a chat with image generation enabled, send a message that creates an image (no image in history yet). 4. Observe logs/network: `/api/v1/tasks/image_prompt/completions` (or equivalent) runs before generation. 5. Send a follow-up message asking to modify the image 6. Observe: edit is invoked with the literal user text; image prompt generation task does **not** run. ### Logs & Screenshots <img width="3363" height="1196" alt="Image" src="https://github.com/user-attachments/assets/effac998-f2ae-413f-b203-ce1d37edb290" /> ### Additional Information In `chat_image_generation_handler` (`backend/open_webui/utils/middleware.py`), `ENABLE_IMAGE_PROMPT_GENERATION` / `generate_image_prompt()` lives only in the `else` branch (create). The `if len(input_images) > 0 and ENABLE_IMAGE_EDIT` branch (edit) calls `image_edits()` immediately with the user message. Relevant structure on `main`: ```python if len(input_images) > 0 and request.app.state.config.ENABLE_IMAGE_EDIT: images = await image_edits(..., prompt=prompt, ...) # no generate_image_prompt() else: if request.app.state.config.ENABLE_IMAGE_PROMPT_GENERATION: res = await generate_image_prompt(...) images = await image_generations(...) ``` Run the image prompt generation block before the create/edit branch so both image_generations() and image_edits() receive the same refined prompt. The builtin edit_image tool (backend/open_webui/tools/builtin.py) also passes the tool prompt directly to image_edits() without prompt generation; that may be a separate enhancement if native function calling i

### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description I have different LLM models on my local set up that are better at different things. I'd like to specify individual models for each of the "task model" features in the Settings > Interace > Tasks section. Right now it only lets you specify 1 local and/or external model to cover all tasks. ### Desired Solution you'd like Could these settings please be broken out to let us select different models per task? For example, I'd like to use a tiny fast model for "Title Generation" because I don't especially care how accurate it is, it's more important that it not use many system resources for very long. Whereas I want a very capable model to do the task "Web Search Query Generation" and "Retrieval Query Generation". It would be great if the "Current model" option were available for each tasks, because there might be some tasks where I want the current model to do the thing (e.g. a great thinking model might be better for a strong web search query on a complex discussion, so I might leave that set to "Current model" so web search quality varies by my conversation model). ### Alternatives Considered I've tried using a tiny model for all tasks, but it does an awful job at web search queries and retrieval tasks, although it's fine for title generation. I've tried using the current model I'm working with (i.e. if you don't specify a task model), but sometimes it's way overkill for title generation (e.g. if I'm using DeepSeek R1 then title generation takes forever). So I'd really like to be able to specify what models to use for each task type. ### Additional Context _No response_

### 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. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) n/a ### Operating System Ubuntu 24.04 (server), `ghcr.io/open-webui/open-webui:v0.9.6` ### Browser (if applicable) Any (reproduced in Chrome 137 and with plain `curl`) ### 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.** - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation.** ### Expected Behavior Opening the chat **“Attach files”** picker fetches a lightweight file *list* (id, filename, meta) — a few KB. ### Actual Behavior The picker calls `GET /api/v1/files/search?filename=*&skip=0&limit=50`, and the backend serializes **`data.content` (the full extracted text) of every listed file** into the response. On our instance (165 files, some large PDFs/DOCX): | Request | Response size | Time | |---|---|---| | `GET /api/v1/files/search?filename=*&skip=0&limit=50` | **63,570,528 bytes (~64 MB)** | 1.96 s | | `GET /api/v1/files/search?filename=*&skip=0&limit=50&content=false` | **27,522 bytes (~27 KB)** | 1.54 s | That is a ~2,300× payload difference for a UI that only renders filenames. The same request is re-issued for every search-input change in the picker, so each picker interaction can transfer hundreds of MB. `GET /api/v1/files/` has the same issue (~23 MB here), affecting other list consumers. ### Steps to Reproduce 1. Run `ghcr.io/open-webui/open-webui:v0.9.6` (stock config; ours uses pgvector + an OpenAI-compatible embedding endpoint, but that is irrelevant — any deployment reproduces it). 2. Upload ~50+ documents with substantial text (multi-MB PDFs/DOCX/XLSX). 3. Open a chat, click **+** → **Attach files** (the in-app file picker, not OS upload). 4. In browser DevTools → Network, observe `GET /api/v1/files/search?filename=*&skip=0&limit=50` transferring tens of MB. Type in the picker’s search box and observe a similarly sized response per query change. ### Root Cause The backend already supports skipping content — `search_files` has `content: bool = Query(True)` and strips `data.content` when `false` (`backend/open_webui/routers/files.py`, `/search` route). The frontend just never passes it: `searchFiles()` in `src/lib/apis/files/index.ts` builds the query from `filename`, `skip`, `limit` only. ### Suggested Fix - Pass `content=false` from `searchFiles()` (and `getFiles()` where the caller only renders a list), **or** - flip the `/search` default to `content=false`, since returning the full extracted text of *all* files by default is rarely the intent of a search/list call (note: it also returns content of other users’ files for admins with `BYPASS_ADMIN_ACCESS_CONTROL`). Happy to submit a PR for either variant if maintainers indicate the preferred direction. ### Logs No backend errors — the requests succeed (`200`); the issue is payload size/latency. Container log excerpt showing the picker traffic: ``` GET /api/v1/files/search?filename=*&skip=0&limit=50 HTTP/1.1" 200 GET /api/v1/files/search?filename=*&skip=0&limit=50 HTTP/1.1" 200 (×8 within one session) ``` ### Workaround (for other affected users) Reverse-proxy level: append `content=false` to `/api/v1/files/search` whe

### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description gemma4 just released - with combined audio and vision support Im sure there will be multiple changes required in OpenWebUI for taking fully advantage. ### Desired Solution you'd like I guess there will be multiple changes required in OpenWebUI for taking fully advantage of the new gemma4: - Another seperate way to interact with audio directly - this would make things probably easier and more intuitive as the the whisper dictate is a replacement for the keyboard and can stay as such. And probably users wat to continue to use speech recognition instead of typing but still prefer text to be sent to gemma4 via chat. OR (but i think this is worse: - When a model with native audio capability is detected ar configured as such in the Admin UI audio should not be sent to whisper. ### Alternatives Considered _No response_ ### Additional Context _No response_

## Bug Summary `get_protected_resource_metadata()` in `backend/open_webui/utils/oauth.py` only attempts RFC 9728 Protected Resource Metadata (PRM) discovery when the anonymous `initialize` probe returns **401** with a `WWW-Authenticate` header. Some remote MCP servers answer **200** to an anonymous `initialize` and only enforce authorization at `tools/call` time. Google's hosted Workspace MCPs behave this way (e.g. `https://gmailmcp.googleapis.com/mcp/v1`), while still publishing a perfectly valid PRM document at the RFC 9728 §4.2 well-known URI: ``` $ curl -s https://gmailmcp.googleapis.com/.well-known/oauth-protected-resource/mcp/v1 {"authorization_servers":["https://accounts.google.com/"], "resource":"https://gmailmcp.googleapis.com/mcp/v1", "scopes_supported":["https://mail.google.com/","https://www.googleapis.com/auth/gmail.modify", ...]} ``` Because the probe returns 200, Open WebUI never fetches this document: `scopes_supported` and `authorization_servers` stay empty, so the OAuth flow requests no scopes and the connection cannot be authorized correctly. ## Steps to Reproduce 1. Admin Settings → Tool Servers → add an MCP connection to `https://gmailmcp.googleapis.com/mcp/v1` with OAuth 2.1 (static client credentials from a Google Cloud project with the Gmail MCP API enabled). 2. Authorize the connection. 3. The authorization request is built without the scopes advertised by the resource's PRM document. ## Expected Behavior PRM discovery should follow RFC 9728: use the `WWW-Authenticate` `resource_metadata` hint when the server returns 401, and otherwise fall back to the well-known URIs — regardless of the probe's HTTP status. ## Actual Behavior Discovery only happens on 401; servers answering 200/4xx-other to the anonymous probe never get PRM discovery. ## Environment - Open WebUI: reproduced on `v0.9.6` and present in current `dev` (`backend/open_webui/utils/oauth.py`, `if response.status == 401:`). ## Proposed Fix Run the discovery unconditionally after the probe (prefer the `WWW-Authenticate` hint when present, fall back to well-known URIs otherwise). Verified against Google's Gmail MCP in a production deployment. PR incoming.

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Linux ### 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 When the AI uses `replace_note_content` to edit a note, the new content should persist in the editor. Subsequent user keystrokes should not alter the content the AI wrote. ### Actual Behavior The tool returns `{"status":"success"}` and `view_note` immediately shows the new text — but as soon as the user types any character in the open editor, the AI's edit vanishes and the original content is restored. Restarting the server temporarily reveals the edit until the note is opened again. ### Steps to Reproduce 1. Open a note in the editor and type some content. 2. In a chat, ask the AI to rewrite the note using the `replace_note_content` built-in tool. 3. Observe that the tool returns success and `view_note` shows the new text. 4. Without closing the note tab, type any character in the editor. 5. The editor reverts to the original content. The AI's edit is gone. ## PoC Fully self-contained, headless reproduction — no browser needed. The script authenticates, writes via the API as the tool does, then emits the same socket event a browser sends on a keystroke. `docker-compose.yml`: ```yaml services: open-webui: image: ghcr.io/open-webui/open-webui:main ports: - "3000:8080" environment: WEBUI_SECRET_KEY: "poc-secret-key-12345" DEFAULT_USER_ROLE: "admin" ENABLE_SIGNUP: "true" OLLAMA_BASE_URL: "" volumes: - owui-data:/app/backend/data healthcheck: test: ["CMD", "curl", "--fail", "http://localhost:8080/health"] interval: 5s timeout: 10s retries: 30 start_period: 30s test: image: python:3.12-slim volumes: - ./test_bug.py:/test_bug.py:ro command: > bash -c "pip install --quiet requests 'python-socketio[client]' && python /test_bug.py" environment: WEBUI_URL: "http://open-webui:8080" depends_on: open-webui: condition: service_healthy volumes: owui-data: ``` `test_bug.py`: ```python import os, sys, time import requests, socketio BASE_URL = os.environ.get("WEBUI_URL", "http://localhost:3000") EMAIL = "poc@example.com" PASSWORD = "Poc123456!" ORIGINAL_CONTENT = {"md": "# Original\nOriginal content."} LLM_CONTENT = {"

## Problem When connecting to an MCP server, Open WebUI requests **every** OAuth scope the server advertises — either the Authorization Server's `scopes_supported` (during dynamic client registration) or the Protected Resource Metadata's `scopes_supported` (with static credentials). Some servers advertise scope catalogs that are broader than what a deployment needs, or even mutually exclusive. Google's hosted Gmail MCP advertises: ``` "scopes_supported": ["https://mail.google.com/", ".../gmail.modify", ".../gmail.compose", ".../gmail.readonly", ".../gmail.metadata"] ``` Requesting all of them is a problem twice over: - **Broken operations:** `gmail.metadata` is incompatible with full-content reads; a token carrying it makes `get_thread` with `messageFormat: FULL_CONTENT` fail. - **Over-granting:** users are asked to consent to full mailbox access (`https://mail.google.com/`) when the deployment only needs read/compose. There is currently no way for an admin to narrow this down — neither globally nor per connection. ## Proposed Solution A `MCP_OAUTH_ALLOWED_SCOPES` environment variable (space- or comma-separated allowlist). When set, advertised scopes not in the list are not requested; when unset, behavior is unchanged. Scope strings are matched exactly, and since they are globally unique per service (especially for Google APIs), a single deployment-wide allowlist works across multiple MCP connections. Verified in a production deployment against Google's Gmail MCP: with the allowlist set to `gmail.readonly gmail.compose`, the consent screen and the issued token are limited to exactly those scopes. A per-connection scope field in the Tool Server connection UI would be a natural follow-up; the env var provides the deployment-level safety net with no UI changes. PR incoming.

### 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 Docker ### Open WebUI Version v0.9.6 (latest) ### 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 The Eject operation should strip the configured connection prefix from the model identifier before transmitting the API request to the backend. This ensures the backend receives the exact, clean model name it expects (e.g., sending 'model-name' instead of 'prefix.model-name'). ### Actual Behavior The Eject action transmits the full internal identifier, including the prefix, directly to the backend API endpoint. As a result, the backend rejects the request with a "model not found" or 404 error because it does not recognize the prefixed string (e.g., receiving 'prefix.model-name' instead of just 'model-name'). ### Steps to Reproduce 1. Go to **Settings > Connections** and configure an OpenAI-compatible API backend. 2. Set a **Prefix ID** for this connection (e.g., 'my-backend'). 3. Load a model belonging to this connection. 4. Attempt to trigger the **Eject/Unload** action on the loaded model. 5. Check the network logs or backend console; the request fails because it targets 'my-backend.model-name' instead of 'model-name'. ### Logs & Screenshots <img width="1341" height="318" alt="Image" src="https://github.com/user-attachments/assets/245c8fc4-34b3-466c-962e-a09af396db71" /> <img width="1042" height="344" alt="Image" src="https://github.com/user-attachments/assets/886c8041-4d5d-4329-bb47-7aae4805476a" /> <img width="1577" height="312" alt="Image" src="https://github.com/user-attachments/assets/cdb83909-96df-4dea-92c2-35b7861a1003" /> ### Additional Information This issue only occurs when a Prefix ID is defined on the OpenAI compatible connection (for example: llama.cpp). If no prefix is used, the eject action works flawlessly because the internal UI identifier matches the backend's model identifier exactly. The bug likely resides in the component/function handling the eject button payload generation, where it pulls 'model.id' instead of the underlying un-prefixed model reference.

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 10 ### Browser (if applicable) Firefox ### 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 Opening a Knowledge Base — and any background polling for in-flight files — should issue a lookup whose cost scales with the number of pending files, not with the total extracted document text in the file table. With a large file table this query should remain an index lookup, and the polling that drives it should not be able to stack requests on top of each other. A KB with no genuinely-processing files should generate negligible DB load. This is the same pathology I reported in #25082, on a different (newly-added in 0.9.6) endpoint. ### Actual Behavior The new `GET /api/v1/knowledge/{id}/files/pending endpoint` (0.9.6) is backed by `Files.get_pending_files_for_knowledge` in `backend/open_webui/models/files.py`, which runs: ``` SELECT ... FROM file WHERE CAST(((meta -> 'data') ->> 'knowledge_id') AS VARCHAR) = $1 AND CAST((data ->> 'status') AS VARCHAR) IN ('pending','processing') AND file.id NOT IN (SELECT file_id FROM knowledge_file WHERE knowledge_id = $2); ``` All three predicates are unindexed JSON expressions, so every call is a full sequential scan of file. Since file.data holds the full extracted content of every document, that table is multi-GB on a large deployment, a plain COUNT with this filter took 1m43s for me. The frontend amplifies it. In `src/lib/components/chat/Knowledge/KnowledgeBase.svelte`, `init()` calls the endpoint on every KB page load, and if anything is pending it starts `setInterval(..., 5000)` with an async callback and no overlap guard so it re-fires every 5s regardless of whether the previous request finished. When the query takes minutes, the polls pile up: I saw 30+ concurrent parallel seq-scans of file at once, one set per open tab. On my deployment (5k users, hundreds of thousands of files) this pinned Aurora Serverless v2 at 100% of 120 ACU and took the instance down. I had to roll back to 0.9.5. ### Steps to Reproduce 1. Stand up Open WebUI v0.9.6 backed by Postgres, with a non-trivial file table (large extracted data.content). 2. Open a Knowledge Base in Workspace → Knowledge; open it in a few tabs. 3. Watch the Postgres logs / pg_stat_activity. Each init() and each 5s interval fires SELECT public.file... as a full seq-scan; with multiple

### 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 Docker ### Open WebUI Version v0.8.12 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 13 ### 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 The old RAG Query Generation and Retrieval process should also be skipped when native function calling is enabled and a collection is selected in chat. ### Actual Behavior After updating from v0.8.10 to v0.8.12, when selecting a collection in Chat now causes the old RAG Query Generation and Retrieval process to start before the model starts generating. The model with native function calling enabled should handle the retrieval themself and being either limited or suggested to use the selected collection. ### Steps to Reproduce 1. Create multiple collections with documents. 2. Create model with collections attached and native function calling enabled. 3. Open chat with created model. 4. Select collection with `+` button in chat text field. 5. Send message with collection selected. ### Logs & Screenshots <img width="1496" height="280" alt="Image" src="https://github.com/user-attachments/assets/93052543-2e9f-4fab-a699-d2ecd2641585" /> <img width="1968" height="224" alt="Image" src="https://github.com/user-attachments/assets/b185d92f-32b8-427f-b631-21ca09951eca" /> ### Additional Information I have a model in Open WebUI with native function calling enabled and multiple collections attached. This works perfectly fine.

### 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 Docker dev-slim image ### Open WebUI Version dev-slim Created 2026-06-02 04:14:37 ### Ollama Version (if applicable) _No response_ ### Operating System pop-os 22.04 ### Browser (if applicable) Chrome latest ### 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 Adding a space when renaming won't open the file. ### Actual Behavior Adding a space when renaming opens the file. Also title is not editable when file is opened for viewing/editing, I don't know if this is intended. ### Steps to Reproduce Rename a KB file, and try adding a space. ### Logs & Screenshots <img width="950" height="601" alt="Image" src="https://github.com/user-attachments/assets/3fe3a3de-4cd9-497a-adef-7ff0dcd12bc7" /> ### Additional Information This was tested on the lastest dev-slim image Created | 2026-06-02 04:14:37

### 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 Docker ### Open WebUI Version 0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### Browser (if applicable) Edge ### 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 a chat session uses a per-user OpenAPI tool server and the LLM makes multiple sequential tool calls, each call should complete and return a result to the backend. The chat should continue normally after all tool calls finish. ### Actual Behavior The chat hangs indefinitely after the first tool call completes. The backend logs tool_call_handler for the second tool call but never sends the execute:tool WebSocket event to the browser — and since WEBSOCKET_EVENT_CALLER_TIMEOUT defaults to None, sio.call() blocks forever. Root cause: executeTool in src/routes/+layout.svelte has no try-catch. If executeToolServer throws on a second call (e.g. because toolServerData is undefined), cb() is never called and the backend never unblocks: // Current code — no try-catch, cb() never called on throw const executeTool = async (data, cb, chatId) => { const { toolServer, toolServerData, token } = resolveToolServer(data.server?.url); if (toolServer) { const res = await executeToolServer( token, toolServer.url, data?.name, data?.params, toolServerData, chatId ); if (cb) { cb(structuredClone(res)); } // never reached if executeToolServer throws } else { if (cb) { cb({ error: 'Tool Server Not Found' }); } } }; ### Steps to Reproduce 1. Add a per-user OpenAPI tool server under User Settings → Tool Servers 2. Start a chat where the LLM needs to make 2+ sequential tool calls (e.g. "list all open deals, then get the details of the top one") 3. Observe: first tool call completes and result appears in the tool citation; second call never fires — chat hangs indefinitely ### Logs & Screenshots Open WebUI backend logs — tool_call_handler fires for the second tool, then silence: 2026-06-09 09:43:32 | DEBUG | open_webui.utils.middleware:tool_call_handler:1331 tool_call={'name': 'pipedrive_list_deals', 'parameters': {'start': 0, 'limit': 500}} [no further tool-related log lines until manual restart] Tool server logs — only one POST received per hang, second call never arrives: INFO: "POST /pipedrive/tools/pipedrive_list_deals HTTP/1.1" 200 OK [no further POST requests] Browser console — first execute:tool fires and returns; second event never appe

### 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 Docker ### Open WebUI Version latest ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04, ### 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 Being able to generate images using models from openrouter ### Actual Behavior The generation fails with error message. ### Steps to Reproduce Just add openrouter as an provider and try the same model as on the picture ### Logs & Screenshots <img width="1039" height="198" alt="Image" src="https://github.com/user-attachments/assets/c86fe500-7eae-431d-80d5-9eb98f22af03" /> ### Additional Information _No response_

### 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 Docker ### Open WebUI Version Open WebUI version: 0.9.6 ### Ollama Version (if applicable) Model: Llama 3.3 70B (via vLLM with native tool calling) ### Operating System Debian 13 ### Browser (if applicable) Search engine: SearXNG ### 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 a model using native function calling (function_calling: native) emits a tool call with numeric parameters as strings (e.g., "count": "1" instead of "count": 1), the builtin tool functions should coerce the values to int before use and execute normally. ### Actual Behavior The builtin tool functions declare int/Optional[int] type hints but never coerce the actual runtime values. When the model passes a numeric parameter as a string, any comparison or arithmetic on that value raises: TypeError: '<' not supported between instances of 'int' and 'str' This crashes the tool call and the model receives an error response instead of search results. ### Steps to Reproduce 1. Configure a model with native function calling enabled (Admin Panel → Function Calling = Native) 2. Enable SearXNG web search 3. In a chat, ask the model to search for something (e.g., "What is the weather in Portland OR?") 4. The model emits a tool call: search_web(query="Portland Oregon weather today", count=1) 5. If the model passes count as the string "1" in the tool call JSON, the min(count, max_count) comparison on line 233 of builtin.py crashes with TypeError ### Logs & Screenshots 2026-06-03 02:15:56.762 | ERROR | open_webui.tools.builtin:search_web:245 - search_web error: '<' not supported between instances of 'int' and 'str' Full traceback shows the error at: File "/app/backend/open_webui/utils/middleware.py", line 4645, in response_handler tool_result = await tool_function(**tool_function_params) ### Additional Information 20 builtin tool functions in backend/open_webui/tools/builtin.py are affected — any that accept int or Optional[int] parameters and use them in comparisons, arithmetic, or slicing: - search_web: min(count, max_count) - calculate_timestamp: days_ago + (weeks_ago * 7), months_ago > 0, years_ago > 0 - search_notes, search_chats, search_channel_messages: start_timestamp * 1_000_000_000, end_timestamp * 1_000_000_000 - search_memories, search_channels, list_knowledge_bases, search_knowledge_bases, search_knowledge_files, list_knowledge, query_kn

## Summary When an OpenAI-compatible provider sends `"timings": null` (or any other null dict field) in streaming chunks, `dict.update(None)` throws a `TypeError` on every content chunk. The exception is caught silently at `DEBUG` log level, so `output` remains `[]` for the entire stream and the saved message has `content: ""` and `output: []`. ## Affected version 0.9.2 ## Affected file and line `open_webui/utils/middleware.py` (~line 3963): ```python raw_usage = data.get('usage', {}) or {} raw_usage.update(data.get('timings', {})) # llama.cpp ``` ## Root cause `dict.get(key, default)` returns the default **only when the key is absent**. When the JSON contains `"timings": null`, the key exists and `.get('timings', {})` returns `None`. Calling `{}.update(None)` raises: ``` TypeError: 'NoneType' object is not iterable ``` This fires inside the `async for line in response.body_iterator` loop. The catch-all at the bottom of that loop catches it silently: ```python except Exception as e: done = 'data: [DONE]' in line if done: pass else: log.debug(f'Error: {e}') # silent! continue ``` Because the exception fires before content is extracted from the delta, `output` remains empty. With `ENABLE_REALTIME_CHAT_SAVE=False` (the default), nothing is written until the stream ends — at which point `serialize_output([])` returns `""`. ## Reproduction Confirmed with `mlx-vlm` serving `mlx-community/gemma-4-12b-it-4bit`. Example streaming chunk: ```json { "id": "chatcmpl-...", "object": "chat.completion.chunk", "choices": [{"index": 0, "delta": {"content": "Hi"}, "finish_reason": null}], "usage": null, "timings": null } ``` Any OpenAI-compatible provider sending null for `timings` or other dict fields will trigger this. It is not specific to mlx-vlm. **Symptoms:** - Chat UI shows an empty assistant message bubble - Follow-up suggestions still generate (they run as a separate model call) - Non-streaming (`stream: false`) requests work correctly — different code path - `DEBUG` logs show `Error: 'NoneType' object is not iterable` for every content chunk ## Fix Add `or {}` to guard against null — consistent with how `usage` is already handled on the line above: ```python raw_usage = data.get('usage', {}) or {} raw_usage.update(data.get('timings', {}) or {}) # llama.cpp — guard against null ``` ## Broader concern The `except Exception as e: log.debug(...)` catch-all in the streaming loop will silently swallow any processing error for any content chunk, always producing empty output. Raising to `WARNING` or `ERROR` would surface unexpected provider response formats much faster.

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description Having used LM Studio in the past, I'd like to have a bit more flexibility when deleting single messages in a given chat. For example, in LM Studio, I can delete the LLM's response if I don't like it, and then regenerate it. In Open WebUI, I cannot delete the entire response, I first need to regenerate it so it shows "2/2", then change back to 1/2, then delete that generation. Also, when I delete one of my messages, Open WebUI automatically deletes the LLM's response as well. In LM Studio, when I delete my message, the LLM answer stays in the chat context anyways, it's just two generated answers after another. The user message just disappears from the screen and from the LLM context. Also, when I keep re-generating a particular message, and there's an error (like the LLM provider is unreachable or whatever), then I can't delete that generation. I can scroll through the generations (1/3, 2/3, 3/3, ...), and I can delete the ones that have actual text, but I cannot delete the ones that just consist of an error, the "delete" button is just missing. ### Proposed Solution - Deleting a user message should not cause the LLM's response to be deleted as well. - It should be possible to delete the last LLM response and re-generate it, without having to first re-generate it, then scroll back to the previous message, then deleting it. - It should be possible to delete failed / error messages. ### Alternatives Considered I can edit the user message and replace it with a blank text, but that doesn't really look nice. Also, it's not really expected behaviour in a chat, where each message has its own "delete" button, that deleting one message will also auto-delete the response to said message. As for deleting the LLM response, yeah, there's a workaround (generate new message, flip back to the previous generation, press delete), but it'd be simpler if this was just built-in. ### Additional Context _No response_

### 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 Docker ### Open WebUI Version running the main branch image: ghcr.io/open-webui/open-webui:main ### Ollama Version (if applicable) ollama:latest ### Operating System Ubunto 22.04 LTS ### Browser (if applicable) 148.0.7778.179 (Official Build) (64-bit) ### 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 Both Open WebUI instances (Main on port 3000 and Experimental on port 3001) should be fully accessible and functional when reached through the SSH tunnel using local port forwarding. The frontend should successfully connect to the backend on both instances, allowing normal login and use without any “Open WebUI backend required” error. ### Actual Behavior I’m running two separate Open WebUI instances on the same Ubuntu server using Docker Compose, accessed via SSH tunnel (PuTTY) with local port forwarding: - Main → `localhost:3000` → **Working perfectly** - Experimental → `localhost:3001` → **Broken** **Error:** “Open WebUI backend required. Oops! You’re using an unsupported method, front-end only. Please serve the WebUI from the backend.” ### Steps to Reproduce **What I’ve already tried:** - Full PuTTY reconnect + hard refresh (`Ctrl + Shift + R`) - Restarting only the Experimental container - Clearing browser cache - Multiple waits and retries **Current state:** - Both containers show as **healthy** in `docker ps` - Main instance works without issues - Experimental keeps showing the backend error (sometimes looping “failing to connect”) **Setup:** - Two separate `docker-compose.yml` files - Both point to the same shared Ollama backend - Using local port forwarding in PuTTY (3000 → 3002 and 3001 → 3001) Has anyone else experienced this flaky behaviour with a second instance behind an SSH tunnel? Any reliable fixes? Thanks in advance. ### Logs & Screenshots none ### Additional Information _No response_

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Fedora Linux 43 (Workstation Edition) x86_64 ### 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 When selecting the exact same model ID (e.g., `gemma3:270m` vs `gemma3:270m`) in a side-by-side chat, both chat panes should receive and display the streamed responses independently without interfering with each other. ### Actual Behavior When identically named models are used, only one model pane receives the streamed response. The other pane remains stuck in a "waiting for response" state, and the stop button becomes unresponsive. Upon reloading the page, both panes display the exact same response (the one from the model that succeeded). The payload suggests that message_ids may collide because the model ID is used as the key. When the exact same model ID is specified for both panes, a key collision occurs, causing the latter message ID to overwrite the former. Consequently, the frontend loses track of one of the message streams. ### Steps to Reproduce 1. Start Open WebUI using the following Docker command: `sudo docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda` 2. Ensure you have a local Ollama model available (e.g., `gemma3:270m`). 3. Open "Open WebUI". 4. Select the **exact same model** for both panes (e.g., `gemma3:270m` and `gemma3:270m`). 5. Send a prompt (e.g., "hello"). 6. Observe that only one pane generates a response, while the other is stuck waiting. The stop button does not work. 7. Reload the page and observe that both panes now display the same text. 8. (Note: Using two distinct model IDs or calling a model individually works perfectly fine.) ### Logs & Screenshots Neither `docker logs -f open-webui` nor the browser console show explicit errors because this is a logical state management issue. However, the relevant evidence is in the `completions` POST request payload: ```json {"stream":true,"model":"gemma3:270m","params":{},"tool_servers":[],"features":{"voice":false,"image_generation":false,"code_interpreter":false,"web_search":false},"variables":{"{{USER_NAME}}":"User","{{USER_EMAIL}}":"*@*.*","{{USER_LOCATION}}":"Unknown","{{CURRENT_DATETIME}}":"2026-06-12 00:54:16","{{CURRENT_DATE

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11、macOS Tahoe ### 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 Open WebUI should handle the Bearer token consistently across all Open Terminal features. If the Bearer token contains accidental leading or trailing whitespace, Open WebUI should either: 1. Trim the whitespace before saving or using the token, or 2. Reject the configuration and show a clear validation warning, such as: `Bearer token contains leading or trailing whitespace`. The connection test, file listing, AI/tool calls, and interactive terminal should all behave consistently. If the token is accepted by the connection test and file listing, the interactive terminal should also work. If the token is invalid due to whitespace, the issue should be detected during configuration or connection testing. ### Actual Behavior When the Bearer token has one trailing space at the end, most Open Terminal-related features still work: * The connection test passes. * The Files page can successfully list files from Open Terminal. * AI/tool calls using Open Terminal also work normally. However, when opening the Files page and expanding the Terminal option to start an interactive terminal session, the terminal immediately fails with: ```text [Connection closed] ``` This behavior is confusing because the same configuration appears valid in other parts of Open WebUI, but only the interactive terminal fails. ### Steps to Reproduce 1. Configure Open-Terminal in Open-WebUI. 2. Enter a valid Bearer token, but accidentally add one trailing space at the end. * Example: `your-secret-key ` 3. Save the Open-Terminal configuration. 4. Run the connection test. 5. Observe that the connection test passes. 6. Open the Files page in Open-WebUI. 7. Confirm that files from Open-Terminal can be listed successfully. 8. Confirm that AI/tool calls using Open-Terminal work normally. 9. In the `Files` page, expand the `Terminal` option to start an interactive terminal session. 10. Observe that the terminal immediately fails with: ```text [Connection closed] ``` 11. Remove the trailing space from the Bearer token and save the configuration again. 12. Reopen the interactive terminal. 13. Observe that the terminal works normally after the trailing space is removed. ### Logs & Screenshots <img wi

### Summary Uploading a `.pptx` (or any other format that goes through `UnstructuredPowerPointLoader`-like loaders) to a freshly built/recreated `open-webui` container leaves the file stuck at `status=pending` forever. Knowledge-base ingestion silently never advances. Chat works, embeddings work, but RAG document processing is blocked end-to-end. ### Root cause `unstructured==0.18.31` + `nltk==3.9.3` (both pinned in `backend/requirements.txt` on `main`, `v0.9.1`, and `v0.9.2`) require the language-tagged NLTK resource `averaged_perceptron_tagger_eng` for sentence/POS tagging in PPTX/Word partitioning. NLTK 3.9.x renamed several taggers to add an `_eng` suffix. The Dockerfile (and `backend/start.sh`) bundles only `punkt_tab`: ```dockerfile python -c "import nltk; nltk.download('punkt_tab')" ``` `averaged_perceptron_tagger_eng` is never pre-downloaded. On first PPTX upload after a fresh `docker compose up --force-recreate` (or a clean image pull), `unstructured` raises: ``` LookupError: Resource 'averaged_perceptron_tagger_eng' not found. Please use the NLTK Downloader to obtain the resource: >>> import nltk >>> nltk.download('averaged_perceptron_tagger_eng') ``` Confirmed by direct probe inside the container: ```python from langchain_community.document_loaders import UnstructuredPowerPointLoader UnstructuredPowerPointLoader('/path/to/file.pptx').load() # -> LookupError: Resource 'averaged_perceptron_tagger_eng' not found. ``` After `python -c "import nltk; nltk.download('averaged_perceptron_tagger_eng', download_dir='/root/nltk_data')"`, the same probe succeeds in ~1.5s and any subsequent file upload completes within seconds. ### Why it appears as 'pending' rather than 'failed' The exception path in `process_uploaded_file` is supposed to set `status='failed'` with the error string, but in practice the file row stays at `status='pending'` (no `failed`, no `completed`, no log line at WARN/ERROR), making this look like a silent hang rather than a deterministic failure. The frontend SSE on `/api/v1/files/{id}/process/status?stream=true` keeps spinning. Worth a separate look on its own — the exception is being swallowed somewhere in the BackgroundTask/asyncio chain. Reproduces with both `process_in_background=true` and inline. ### Reproduction 1. Pull `ghcr.io/open-webui/open-webui:v0.9.2` (or `v0.9.1`, identical packages). 2. Start fresh, configure any embedding backend. 3. Upload any `.pptx` (e.g. via Knowledge → Upload). 4. File row stays at `data->>'status' = 'pending'` indefinitely. No log lines mentioning the file ID after the initial `POST /api/v1/files/?process=true HTTP/1.1 200`. Probe to confirm root cause: ```bash docker exec -it open-webui-app python3 -c " from langchain_community.document_loaders import UnstructuredPowerPointLoader import glob p = glob.glob('/app/backend/data/uploads/*.pptx')[0] UnstructuredPowerPointLoader(p).load() " ``` ### Proposed fix Two parts: 1. **Bundle the missing NLTK resource alongside `punkt_tab`.** Mirror the existing pattern in both Dockerfile branches (`USE_CUDA=true` and `else`) and in `backend/start.sh` / `backend/start_windows.bat`: ```dockerfile python -c "import nltk; nltk.download('punkt_tab'); nltk.download('averaged_perceptron_tagger_eng')" ``` Keeps the airgapped-friendliness improvement from #21165 consistent across the resources `unstructured` 0.18.x actually needs. 2. **Surface the failure.** Make sure the `process_uploaded_file` exception path actually transitions `data->>'status'` to `failed` with the original error string in `data->>'error'` so the UI shows a clear error instead of an infinite spinner. Today the SSE polls `data->>'status'` and never sees a terminal state. Happy to put up a PR for (1) — it's a 3-character diff. ### Environment - Open WebUI: `v0.9.2` (and `v0.9.1`, same deps) - `unstructured`: `0.18.31` - `nltk`: `3.9.3` - Vector store: `pgvector` 0.8.2 - Embedding engine: `openai`-compatible (LiteLLM → GigaChat)

### 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.6 (latest) ### Ollama Version (if applicable) _No response_ ### Operating System portainer ### 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 cannot reshape array of size 275532 into shape (1752,1240,newaxis) ### Actual Behavior cannot reshape array of size 275532 into shape (1752,1240,newaxis) ### Steps to Reproduce cannot reshape array of size 275532 into shape (1752,1240,newaxis) ### Logs & Screenshots cannot reshape array of size 275532 into shape (1752,1240,newaxis) ### Additional Information cannot reshape array of size 275532 into shape (1752,1240,newaxis)

### 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.6 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### 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 Send Authorization: Bearer header with a Token ### Actual Behavior NO header seen ### Steps to Reproduce Bring up a OpenWebUI container with below environment Settings. MICROSOFT_CLIENT_ID=xxxx MICROSOFT_CLIENT_SECRET=yyyy MICROSOFT_CLIENT_TENANT_ID=zzzz MICROSOFT_REDIRECT_URI=https://openweb.example.com/oauth/microsoft/callback MICROSOFT_OAUTH_SCOPE=openid email profile offline_access OPENID_PROVIDER_URL=https://login.microsoftonline.com/zzzz/v2.0/.well-known/openid-configuration ENABLE_OAUTH_GROUP_MANAGEMENT=true ENABLE_FORWARD_OAUTH_TOKEN=True ENABLE_OAUTH_SIGNUP=true ENABLE_FORWARD_USER_INFO_HEADERS=true FORWARD_USER_INFO_HEADER_USER_ID=X-User-Id USER_AGENT=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36 ### Logs & Screenshots <img width="1202" height="773" alt="Image" src="https://github.com/user-attachments/assets/52a76187-7d42-42d4-aa24-bd62ea549188" /> ### Additional Information Even the User-Agent Header setting of Variable is not working as expected.

## Bug Description When `RAG_EMBEDDING_ENGINE=""` and `RAG_EMBEDDING_MODEL=""` are set (disabling RAG embeddings), uploading files with `.diff` extension causes an `AttributeError: 'NoneType' object has no attribute 'encode'` error. The error occurs at `/app/backend/open_webui/retrieval/utils.py` line 839: ```python lambda query, prefix=None: embedding_function.encode( query, batch_size=int(embedding_batch_size), **({"prompt": prefix} if prefix else {}), ).tolist() ``` When `embedding_function` is `None`, calling `.encode()` raises `AttributeError`. ## Steps to Reproduce 1. Set environment variables: ```bash RAG_EMBEDDING_ENGINE="" RAG_EMBEDDING_MODEL="" ``` 2. Start Open-WebUI with these environment variables 3. Upload a `.diff` file (or any file that triggers RAG processing) 4. Observe the error in logs: ``` AttributeError: 'NoneType' object has no attribute 'encode' ``` ## Root Cause The `get_embedding_function` function doesn't handle the case where `embedding_function` parameter is `None`. When RAG is disabled via empty environment variables, `embedding_function` becomes `None`. ## Proposed Fix Add a check for `embedding_function is None` before calling `.encode()`: ```diff --- backend/open_webui/retrieval/utils.py.orig +++ backend/open_webui/retrieval/utils.py.fixed @@ -839,9 +839,9 @@ ( lambda query, prefix=None: embedding_function.encode( query, batch_size=int(embedding_batch_size), **({"prompt": prefix} if prefix else {}), - ).tolist() + ).tolist() if embedding_function is not None else [] ), query, prefix, ) ``` This fix returns an empty list when `embedding_function` is `None`, preventing the `AttributeError`. ## Impact - **Files affected**: `backend/open_webui/retrieval/utils.py` - **Users affected**: Anyone running Open-WebUI with RAG disabled (empty embedding config) - **Severity**: Medium - prevents file uploads when RAG is disabled ## Additional Context This bug was discovered while testing file uploads with custom LLM providers. The user had embedding disabled but still wanted to upload `.diff` files for patch review functionality.

### 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 exact duplicate. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version latest `main` as of 2026-04-16 (latest release also checked: `v0.8.12`) ### Ollama Version (if applicable) _No response_ ### Operating System macOS Sequoia ### 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 Open WebUI. - [x] I have provided a deterministic local reproduction of the affected code path. - [x] I have included the relevant code path, expected behavior, actual behavior, and exact reproduction steps. ### Expected Behavior Updating a file's content should not leave any knowledge collection in a worse state than before. If the KB reindex step fails after the file content has been updated, Open WebUI should either: - preserve the old KB vectors, or - fail the request before destructive cleanup happens. ### Actual Behavior `/files/{id}/data/content/update` currently deletes the old KB vectors first and only then tries to rebuild them. If the rebuild fails, the exception is reduced to a warning and the route still returns success. That can leave the knowledge collection without any vectors for that file. This is different from `#20558`: - `#20558` = stale old embeddings remained after edits - this report = the old embeddings are deleted, the rebuild fails, and the route still succeeds ### Steps to Reproduce The current `main` code in `backend/open_webui/routers/files.py` does this during content updates: 1. update the file content via `process_file(..., content=...)` 2. for each knowledge collection referencing the file: - `delete(... filter={'file_id': id})` - `process_file(..., collection_name=knowledge.id)` 3. if step 2b fails, only log a warning and continue A deterministic local reproduction is: ```python from dataclasses import dataclass kb_vectors = {'kb-1': [{'file_id': 'file-1', 'chunk': 'OLD EMBEDDING'}]} @dataclass class Knowledge: id: str class VECTOR_DB_CLIENT: @staticmethod def delete(collection_name, filter): kb_vectors[collection_name] = [ v for v in kb_vectors.get(collection_name, []) if v.get('file_id') != filter['file_id'] ] class ProcessFileForm: def __init__(self, file_id, collection_name=None): self.file_id = file_id self.collection_name = collection_name def process_file(request, form, user, db=None): if form.collection_name: raise RuntimeError('reindex failed') for knowledge in [Knowledge(id='kb-1')]: try: VECTOR_DB_CLIENT.delete(collection_name=knowledge.id, filter={'file_id': 'file-1'}) process_file(None, ProcessFileForm(file_id='file-1', collection_name=knowledge.id), user=None) except Exception as e: print('swallowed knowledge reindex failure:', e) print('remaining_vectors =', kb_vectors['kb-1']) ``` Actual output: ```text swallowed knowledge reindex failure: reindex failed remaining_vectors = [] ``` The route-level call sequence is effectively: ```text process_file(file-1, content='NEW') delete(kb-1, {'file_id': 'file-1'}) process_file(file-1, collection_name='kb-1') # fails return {'content': 'NEW'} ``` ### Logs & Screenshots Relevant current code path (`backend/open_webui/routers/files.py`): ```python await ASYNC_VECTOR_DB_CLIENT.delete(collection_name=knowledge.id, filter={'file_id': id}) await process_file( request, ProcessFileForm(file_id=id, collection_name=knowledge.id), user=user, db=db, ) ``` and on failure: ```python log.warning(f'Failed to update knowledge {knowledge.id} after content change for file {id}: {e}') ``` ### Additional Informa

### 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.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 10 ### 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 ### Description When an admin disables chat deletion for users (`chat.delete` permission set to `false`), the restriction is correctly enforced when: - A user tries to delete an individual chat - A user tries to delete a folder that **directly contains** chat conversations However, the restriction is **NOT enforced** when a user deletes a **parent/master folder** that contains no direct chats but has **subfolders with chat conversations inside them**. The parent folder is deleted successfully, which cascades and deletes all subfolders and their chats — effectively bypassing the permission entirely. --- ### Expected Behavior Deleting the Master Folder should be blocked if **any descendant subfolder** contains chats that the user does not have permission to delete. ### Actual Behavior Deleting the Master Folder succeeds and cascades — silently deleting all subfolders and their chat conversations, bypassing the `chat.delete` permission check. ### Steps to Reproduce ### Steps to Reproduce 1. As an admin, disable chat deletion for users (`Admin Panel → Users → Permissions → Allow Chat Deletion = false`) 2. Log in as a regular (non-admin) user 3. Create a **Master Folder** in the sidebar 4. Inside the Master Folder, create a **Subfolder** 5. Inside the Subfolder, start one or more chat conversations 6. Attempt to delete the **Subfolder** → ✅ Correctly blocked with permission error 7. Attempt to delete the **Master Folder** (which has no direct chats) → ❌ **Deletion succeeds**, wiping out the Subfolder and all its chats --- ### Logs & Screenshots ### Root Cause In `backend/open_webui/routers/folders.py`, the `delete_folder_by_id` endpoint checks for chats only in the **top-level folder** being deleted: ```python # Current (buggy) code if await Chats.count_chats_by_folder_id_and_user_id(id, user.id, db=db): chat_delete_permission = await has_permission( user.id, 'chat.delete', request.app.state.config.USER_PERMISSIONS, db=db ) if user.role != 'admin' and not chat_delete_permission: raise HTTPException( status_code=status.HTTP_403_FORBIDDEN, detail=ERROR_MESSAGES.ACCESS_PROHIBITED, ) ``` When the master folder ha

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description when scrolling a lot of return token information from AI if I need to scroll all the way to the top or somewhere inbetween there is no scroll bar. You have to move over to the text and use the scroll wheel which does not work very well. ### Proposed Solution It would be easier to use if there was a scroll bar as I often scroll up and down the next to copy stuff out of it and its really hard to do that if there is no scroll bar as I need to manually use the scroll which and a lot of time to scroll to the top of a large amount of return text. ### Alternatives Considered _No response_ ### Additional Context _No response_

### 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. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.9.6 (also present on `main` as of 2026-06-02) ### Operating System Linux (Docker) ### Description `POST /api/v1/configs/tool_servers` returns **500 Internal Server Error** when any MCP-type connection in the saved config has `info: null`. This is a Python dict-default footgun: `dict.get(key, default)` returns `None` — not the default — when the key is *present* with value `None`. ### Root Cause `ToolServerConnection.model_dump()` serialises `info=None` as `{"info": None, ...}` (the key is *present*). Two places in `set_tool_servers_config` then do: ```python server_id = connection.get('info', {}).get('id') # ^^^ # When info is None (explicitly stored), .get('info', {}) returns None — not {} # → AttributeError: 'NoneType' object has no attribute 'get' ``` **Occurrence 1** (`configs.py` ~line 187) — cleanup loop over *old* connections: ```python for connection in request.app.state.config.TOOL_SERVER_CONNECTIONS: server_type = connection.get('type', 'openapi') auth_type = connection.get('auth_type', 'none') if auth_type in ('oauth_2.1', 'oauth_2.1_static'): server_id = connection.get('info', {}).get('id') # ← crashes when info is None ``` **Occurrence 2** (`configs.py` ~line 205) — registration loop over *new* connections: ```python for connection in request.app.state.config.TOOL_SERVER_CONNECTIONS: server_type = connection.get('type', 'openapi') if server_type == 'mcp': server_id = connection.get('info', {}).get('id') # ← crashes when info is None ``` ### Steps to Reproduce ```bash # 1. POST an MCP connection leaving info absent (defaults to None via model_dump) curl -X POST http://localhost:8080/api/v1/configs/tool_servers \ -H "Authorization: Bearer <admin-key>" \ -H "Content-Type: application/json" \ -d '{ "TOOL_SERVER_CONNECTIONS": [{ "url": "http://my-mcp-server:8000", "path": "/mcp", "type": "mcp", "auth_type": "none", "headers": null, "key": null, "config": null, "info": null }] }' # → 200 OK (the connections are saved) # 2. POST again (any update) — now the saved connection has info: null curl -X POST http://localhost:8080/api/v1/configs/tool_servers \ -H "Authorization: Bearer <admin-key>" \ -H "Content-Type: application/json" \ -d '{"TOOL_SERVER_CONNECTIONS": []}' # → 500 Internal Server Error ``` Server log: ``` AttributeError: 'NoneType' object has no attribute 'get' File ".../routers/configs.py", line 205, in set_tool_servers_config server_id = connection.get('info', {}).get('id') ``` ### Fix Replace both occurrences with a null-safe pattern: ```python # Before (both occurrences): server_id = connection.get('info', {}).get('id') # After: server_id = (connection.get('info') or {}).get('id') ``` This handles all three cases correctly: - key absent → `None or {}` → `{}` - key present, value `None` → `None or {}` → `{}` - key present, value `{}` or a populated dict → passes through ### Additional Notes - The `ToolServerConnection` model declares `info: dict | None = None`, so `None` is a valid value per the schema and `model_dump()` will produce it whenever callers omit `info` or set it explicitly to `None`. - Occurrence 1 only fires when an existing connection has `auth_type: "oauth_2.1"` or `"oauth_2.1_static"` and `info: null`. Occurrence 2 fires for any `type: "mcp"` connection with `info: null`. - **Workaround**: always include `"info": {"id": "..."}` in the payload — the `200` path works correctly.

## Summary `chatCompletedHandler` is invoked fire-and-forget (no `await`) at line 1883. Inside it, after an `await getChatList(...)` call at line 1536, it unconditionally executes `taskIds = null` (line 1538). Because the handler yields at that `await`, a concurrent `sendMessage` call can resolve its own network request in the meantime and assign fresh task IDs to `taskIds` (lines 2500-2504). When `chatCompletedHandler` then resumes, it wipes those freshly written task IDs. The result is that `stopResponse()` (line 2579) iterates an empty/null list and the stop-generation UI binding (`{taskIds}` at line 3099) renders as inactive, so in-flight background tasks (title generation, follow-ups, tags) cannot be cancelled by the user. ## What I observed Relevant code in `src/lib/components/chat/Chat.svelte`: ```svelte // L1531-1538 — chatCompletedHandler clears taskIds unconditionally const chatCompletedHandler = async (_chatId, modelId, responseMessageId, messages) => { if ($chatId == _chatId && !$temporaryChatEnabled) { currentChatPage.set(1); await chats.set(await getChatList(localStorage.token, $currentChatPage)); // <-- yields here } taskIds = null; // <-- resumes here, overwrites any concurrent assignment }; // L1880-1891 — fire-and-forget call site (no await) chatCompletedHandler( chatId, message.model, message.id, createMessagesList(history, message.id) ); await processNextInQueue(chatId); // sendMessage may run concurrently // L2499-2505 — sendMessage assigns taskIds after its own await const newTaskIds = res.task_ids ?? (res.task_id ? [res.task_id] : []); if (taskIds) { taskIds.push(...newTaskIds); } else { taskIds = newTaskIds; // <-- written while chatCompletedHandler is suspended at getChatList } ``` **Race sequence:** 1. Response stream for message N finishes; `chatCompletedHandler` is dispatched fire-and-forget and suspends at `await getChatList(...)`. 2. User sends message N+1 (or the queue processes the next request via `processNextInQueue`); `sendMessage` issues its HTTP request and awaits the response. 3. While `chatCompletedHandler` is still suspended, `sendMessage`'s `await` resolves; `taskIds` is `null` at that point so the `else` branch at L2504 fires: `taskIds = newTaskIds`. 4. `chatCompletedHandler` resumes and executes `taskIds = null`, erasing the IDs just set. 5. `stopResponse()` reads `if (taskIds)` as falsy; no stop calls are issued; the UI stop button disappears. The partial fix in open PR #22146 adds a `get(chatId) !== _chatId` guard before `taskIds = null`, which prevents the stale-navigation variant of this race (user navigates away) but does not prevent the same-chat interleaved race described above, because `_chatId === $chatId` holds true for in-progress messages in the same conversation. ## Suggested fix Replace the unconditional `taskIds = null` in `chatCompletedHandler` with a generation-stamp or sequence-number guard so the handler only clears `taskIds` when no newer `sendMessage` has started since the handler was invoked: ```svelte // Option A: capture taskIds reference at dispatch time and only null if unchanged const chatCompletedHandler = async (_chatId, modelId, responseMessageId, messages) => { const capturedTaskIds = taskIds; // snapshot before first await if ($chatId == _chatId && !$temporaryChatEnabled) { currentChatPage.set(1); await chats.set(await getChatList(localStorage.token, $currentChatPage)); } // Only clear if sendMessage hasn't assigned new task IDs since we were dispatched if (taskIds === capturedTaskIds) { taskIds = null; } }; ``` Alternatively, introduce a monotonic `sendGeneration` counter incremented at the start of each `sendMessage` call and captured in `chatCompletedHandler` at dispatch time; only null `taskIds` if `sendGeneration === capturedGeneration`.

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System macOS Tahoe ### 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 When Open WebUI registers a client via **RFC 7591 Dynamic Client Registration (DCR)** for an MCP / OAuth 2.1 tool server, the `scope` it sends in the registration request should be derived from the **resource's** advertised scopes, following the principle of least privilege: 1. the `scope` value from the `WWW-Authenticate` 401 challenge, if present; otherwise 2. the **Protected Resource Metadata** (`/.well-known/oauth-protected-resource`, RFC 9728 §2) `scopes_supported` — i.e. the scopes specific to *this* protected resource. This matches the MCP Authorization spec's [Scope Selection Strategy](https://modelcontextprotocol.io/specification/draft/basic/authorization#scope-selection-strategy) and is exactly the source already adopted for the **static-credentials** flow in **PR #24690** ("use Protected Resource Metadata scopes in static OAuth 2.1 flow", merged in v0.9.6, closing #24730 / relating to #23668). ### Actual Behavior The **DCR flow** still seeds the registration `scope` from the **Authorization Server Metadata** `scopes_supported` — the full catalog of every scope the AS can grant across **all** resources it protects — not from the Protected Resource Metadata. In `backend/open_webui/utils/oauth.py`, `get_oauth_client_info_with_dynamic_client_registration()` fetches the PRM but **ignores** `resource_metadata.scopes_supported`, and instead does (current `main`, commit `f2e1aa1`, ~L448–452): ```python resource_metadata = await get_protected_resource_metadata(oauth_server_url) # PRM fetched... resource = resource_metadata.resource discovery_urls = resource_metadata.get_discovery_urls(oauth_server_url) for url in discovery_urls: ... oauth_server_metadata = OAuthMetadata.model_validate(await ...json()) ... if ( oauth_client_metadata.scope is None and oauth_server_metadata.scopes_supported is not None # <-- AS catalog ): oauth_client_metadata.scope = ' '.join(oauth_server_metadata.scopes_supported) ``` `resource_metadata.scopes_supported` (PRM) is never consulted here. The space-joined AS `scopes_supported` is then serialized into the registration POST body (`model_dump(...)` → `session.post(registration_url, json=registr

### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Currently, there's no way to mark or save important information within chat conversations in Open WebUI. Often times I want to go back to a point in the chat where there was a useful piece of information, but I don't remember exactly where it is. This makes knowledge retention and retrieval inefficient, especially for users who have many conversations or use the platform for learning or research. ### Desired Solution you'd like 1. Add text highlighting functionality that allows users to select and highlight important parts of any message 2. Automatic saving of these highlights to a user's profile/account 3. A dedicated "Highlights" tab that displays all highlights in chronological order 4. The ability to click on any highlight to jump back to its original conversation context 5. Search functionality that allows users to search through their highlights ### Alternatives Considered _No response_ ### Additional Context _No response_

## Description When a filter function's `outlet` hook converts a non-HTML code block (e.g. \`\`\`markdown) to \`\`\`html, the artifact panel does not automatically open on the right side. The user must manually click the code block to trigger it. For \`\`\`html blocks emitted directly by the LLM during streaming, the panel auto-opens correctly. ## Steps to Reproduce 1. Create a filter function with an `outlet` hook that converts \`\`\`markdown blocks to \`\`\`html (e.g., a markdown-to-HTML document renderer) 2. Send a prompt that triggers the LLM to emit a \`\`\`markdown block 3. After streaming completes, the outlet converts it to \`\`\`html 4. The artifact panel does not open automatically — user must click the code block ## Expected Behavior The artifact panel should auto-open after the outlet converts the content to \`\`\`html, just like it does for \`\`\`html blocks emitted directly during streaming. ## Root Cause Analysis `ContentRenderer.svelte` (line ~247) has an `onUpdate` callback that calls `showArtifacts.set(true)` when the markdown renderer processes a code block with `lang="html"`. This fires correctly during the initial streaming render. However, when the outlet modifies the message content post-stream (converting \`\`\`markdown → \`\`\`html), the markdown renderer's `onUpdate` callback does not re-fire for the new \`\`\`html block. The Svelte reactive system updates the content, but the artifact detection logic in `onUpdate` is not re-triggered. ## Environment - Open WebUI version: 0.9.x (from upstream dev branch ~May 2026) - Browser: Chrome - Platform: macOS

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04.4 LTS ### 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 `SafePlaywrightURLLoader` should reliably clean up Playwright resources after each URL and after loader failures or cancellation. Specifically: - each `page` created by `browser.new_page()` should be closed in a per-URL `finally` block; - the connected or launched browser should be closed in an outer `finally` block; - cleanup should happen even when `page.goto()`, route handling, evaluator logic, cancellation, or `continue_on_failure=False` exits early. ### Actual Behavior In `backend/open_webui/retrieval/web/utils.py`, both `SafePlaywrightURLLoader.lazy_load()` and `SafePlaywrightURLLoader.alazy_load()` create a Playwright page per URL but do not close the page per URL. The browser is closed only after the URL loop completes normally. If execution exits early, cleanup can be skipped. During slow pages, bot-protection/challenge pages, route timeouts, or interrupted web searches, this can leave Playwright pages/sessions open longer than necessary and can accumulate resources on a remote Playwright server. Observed failure mode: - `WEB_LOADER_ENGINE=playwright` - `PLAYWRIGHT_WS_URL=ws://playwright:3002/` - web search triggered multiple Playwright route/navigation timeouts - Open WebUI logs showed repeated Playwright timeout exceptions - Open WebUI became degraded under load - restarting the Playwright service cleared the immediate issue ### Steps to Reproduce 1. Run Open WebUI with Docker. 2. Run a remote Playwright server. 3. Configure Open WebUI with: WEB_LOADER_ENGINE=playwright PLAYWRIGHT_WS_URL=ws://playwright:3002/ PLAYWRIGHT_TIMEOUT=15000 WEB_LOADER_CONCURRENT_REQUESTS=8 4. Enable web search. 5. Trigger web searches that include slow, bot-protected, redirect-heavy, or challenge pages. 6. Observe Open WebUI backend logs showing Playwright Page.goto, Route.fetch, or route continuation timeouts. 7. Observe that page.close() is not called per URL, and browser.close() is not protected by finally. ### Logs & Screenshots 2026-06-09T14:28:45.711113852Z ERROR open_webui.retrieval.web.utils:alazy_load:614 - Error loading https://www.outdoorxl.nl/crespo.html: Browser.new_page: Route.continue_: ... Route.fetch: Timeout 30000ms exceeded. Call log: - GET ht

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description When utilizing Open WebUI with fast local models (generating 40+ tokens per second on modern hardware), the chat interface aggressively auto-scrolls the viewport downward. If a user tries to focus and read an answer from the top while it is actively streaming, the layout constantly jumps, causing severe eye strain. Currently, the only workaround is a manual user gesture: flicking the mouse wheel upward the millisecond text generation begins to force-trigger the internal scroll lock. ### Proposed Solution We should implement a more stable reading view modeled after Google Gemini's user interface: 1 Native Scroll Anchoring: Utilize robust CSS scroll anchoring (⁠overflow-anchor: auto⁠) on the chat container. This ensures that when new tokens stream in off-screen below the current viewport, the text the user is actively reading remains completely locked, solid, and motionless. 2 Strict Bottom-Pin Check: The JavaScript auto-scroll script (⁠scrollToBottom⁠) should only execute if the user's scrollbar is actively pinned to the absolute bottom pixel of the window. If the user has scrolled up even a fraction, auto-scrolling should immediately stand down without requiring an aggressive user gesture to fight it. This enhancement would massively improve readability for power users running high-speed local workstations. Thank you for maintaining such an incredible project! ### Alternatives Considered _No response_ ### Additional Context _No response_

### 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 Docker ### Open WebUI Version 0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System Ununtu 22.04 ### 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 The notification for unread messages should not appear after the refresh. ### Actual Behavior Notice that the prompt will appear again after the refresh operation. ### Steps to Reproduce 1. Click on the new conversation button to send any prompts to the model. 2. After obtaining the complete output, click on the new conversation again. 3. Refresh the webpage 4. It can be observed that a "unread" notification appears next to the message created in step 1 in the side bar. ### Logs & Screenshots There are no issues with the log at all. ### Additional Information _No response_

### 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 Docker ### Open WebUI Version v0.9.6 ### Ollama Version (if applicable) 0.30.7 ### Operating System Pop!_OS 24.04 LTS x86_64 ### Browser (if applicable) Firefox 153.0a1 ### 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 It should work. ### Actual Behavior ```log open-webui | 2026-06-12 12:24:03.704 | INFO | open_webui.retrieval.web.ollama:search_ollama_cloud:26 - Searching with Ollama for query: what is embeddinggemma open-webui | 2026-06-12 12:24:03.704 | INFO | open_webui.retrieval.web.ollama:search_ollama_cloud:26 - Searching with Ollama for query: gemma 4 model architecture details open-webui | 2026-06-12 12:24:03.705 | INFO | open_webui.retrieval.web.ollama:search_ollama_cloud:26 - Searching with Ollama for query: does gemma 4 use embeddinggemma open-webui | 2026-06-12 12:24:03.795 | ERROR | open_webui.retrieval.web.ollama:search_ollama_cloud:51 - Error searching Ollama: 401 Client Error: Unauthorized for url: https://ollama.com/api/web_search open-webui | 2026-06-12 12:24:03.796 | ERROR | open_webui.retrieval.web.ollama:search_ollama_cloud:51 - Error searching Ollama: 401 Client Error: Unauthorized for url: https://ollama.com/api/web_search open-webui | 2026-06-12 12:24:03.798 | ERROR | open_webui.retrieval.web.ollama:search_ollama_cloud:51 - Error searching Ollama: 401 Client Error: Unauthorized for url: https://ollama.com/api/web_search open-webui | 2026-06-12 12:24:03.798 | ERROR | open_webui.utils.middleware:chat_web_search_handler:1649 - 404: [ERROR: No results found from web search] ``` ### Steps to Reproduce 1. Configure Open-WebUI to use Ollama Cloud Web Search ```env ENABLE_WEB_SEARCH=true WEB_SEARCH_ENGINE=ollama_cloud OLLAMA_CLOUD_WEB_SEARCH_API_KEY= ``` 2. Ask a model to search something ### Logs & Screenshots ```log open-webui | 2026-06-12 12:24:03.704 | INFO | open_webui.retrieval.web.ollama:search_ollama_cloud:26 - Searching with Ollama for query: what is embeddinggemma open-webui | 2026-06-12 12:24:03.704 | INFO | open_webui.retrieval.web.ollama:search_ollama_cloud:26 - Searching with Ollama for query: gemma 4 model architecture details

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description I don't know if this is a bug or rather a feature in terms of where to put this. Nevertheless, it's annoying at least for users. When you select a Tool that belongs to an mcp server Open WebUI correctly sends you to the providers page for oauth. The problem now is that upon authentication you're redirect back to Open WebUI with the default model selected. So when you trigger this flow with a non default Model you have to switch back to the original model to start your chat... This can be quit unintuitive for users as they expect to have the correct model selected. Steps to reproduce: - Have at least two models - Connect a mcp server via oauth 2.1 - select the non default model - enable the tool and complete the oauth ### Proposed Solution After redirecting back to Open WebUI the Model from which the OAuth flow was triggered should be selected again regardless of which is your default model ### Alternatives Considered As stated above i'm unsure if this intentional and therefore a feat or a bug that needs to be fixed. Regardless of that i don't have an alternative for now ### Additional Context _No response_

### 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.6 ### Ollama Version (if applicable) _No response_ ### Operating System MacOS ### 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 Bash `{,,}` (lower-case substitution) is not available in older bash version. As an older version is default-bundled with current MacOS this will prevent startup using `start.sh`. **Solution:** Lowercasing can be easily achieved using a cross-platform compatible helper as e.g., ```bash lowercase() { printf '%s' "$1" | tr '[:upper:]' '[:lower:]' } ``` and later be used like ```bash if [[ "$(lowercase "$WEB_LOADER_ENGINE")" == "playwright" ]]; then ``` ### Actual Behavior Program does not start ### Steps to Reproduce run `start.sh` on 3.X bash (e.g., bundled with MacOS) ### Logs & Screenshots `./start.sh: line 21: ${WEB_LOADER_ENGINE,,}: bad substitution` ### Additional Information _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description Chunks written to the vector DB carry metadata such as `file_id`, `created_by`, `source` and `embedding_config`, but **no timestamp**. In `save_docs_to_vector_db()` (`backend/open_webui/routers/retrieval.py`), the per-chunk metadata dict includes `created_by` but never a `created_at` or `indexed_at`. The only creation time available lives one level up - on the `file` / `knowledge` records in the main DB. This makes two common operations impractical: 1. **Time-based filtering/boosting at query time** - retrieval cannot filter or boost by recency (e.g. `created_at` >= …) directly in the vector store; it would require joining back to the main DB. 2. **Time-based retention/cleanup** - there is no reliable way to identify and purge stale chunks (e.g. older than X days), since the chunks themselves carry no age information. ### Proposed Solution Add a `created_at` (and ideally `indexed_at`) field to the chunk metadata at indexing time, alongside the existing `created_by`. For JSON-metadata backends this is non-breaking - a single field added to the metadata dict in `save_docs_to_vector_db()`: [`save_docs_to_vector_db()` in `retrieval.py` (L1467)](https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/retrieval.py#L1467) ```python metadatas = [ { **doc.metadata, **(metadata if metadata else {}), 'created_at': int(time.time()), 'embedding_config': { ... }, } for doc in docs ] ``` This unlocks: - **Recency-aware retrieval** - filter/boost by `created_at` directly in the vector store. - **Stateless, scheduled cleanup** - an external job (e.g. a Kubernetes `CronJob`) can query and delete chunks by age directly against the vector DB, with no join into the main DB and no coupling to the app, making retention trivial to automate. ### Alternatives Considered _No response_ ### Additional Context I run Open WebUI on my own Kubernetes cluster with enforced data-retention deadlines. Implementing this today is very cumbersome, since there's no per-chunk timestamp to filter on. A per-chunk `created_at` would let a `CronJob` purge chunks by age directly in the vector DB.

**Issue** Open WebUI appears to persist only the last LLM call’s `usage` object for a streaming assistant response that uses native/server-side tool calls. Earlier LLM calls in the same tool loop are overwritten before the final assistant message is saved. This makes the built-in analytics token usage inaccurate for tool-using conversations. **Affected Path** This applies to streaming chat completions with native/server-side tool calling, where one visible assistant message may require multiple upstream LLM calls: 1. Initial LLM call returns tool calls. 2. Open WebUI executes tools. 3. Open WebUI sends another LLM call with tool results. 4. This may repeat. 5. Final LLM call returns the visible assistant answer. Each upstream LLM call can return its own `usage` object, but Open WebUI seems to persist only the final one. **Code Evidence** In `backend/open_webui/utils/middleware.py`, `streaming_chat_response_handler(...)` creates a single shared `usage` variable for the whole assistant response: ```python usage = None ``` Inside `stream_body_handler(...)`, that variable is reused: ```python nonlocal usage ``` When a streamed usage object arrives, it overwrites the previous value: ```python raw_usage = data.get('usage', {}) or {} raw_usage.update(data.get('timings', {})) # llama.cpp if raw_usage: usage = normalize_usage(raw_usage) ``` The Responses API path does the same: ```python if response_metadata.get('usage'): response_metadata['usage'] = normalize_usage(response_metadata['usage']) usage = response_metadata['usage'] ``` During native tool loops, the same `stream_body_handler(...)` is called again for follow-up LLM calls: ```python await stream_body_handler(res, new_form_data) ``` At the end, only the final value of `usage` is persisted: ```python await Chats.upsert_message_to_chat_by_id_and_message_id( metadata['chat_id'], metadata['message_id'], { 'done': True, 'content': serialize_output(output), 'output': output, **({'usage': usage} if usage else {}), }, ) ``` or, with realtime save enabled: ```python await Chats.upsert_message_to_chat_by_id_and_message_id( metadata['chat_id'], metadata['message_id'], {'done': True, 'usage': usage}, ) ``` Analytics then reads from the persisted assistant-message usage in `backend/open_webui/models/chat_messages.py`, for example: ```python ChatMessage.usage.isnot(None) ``` and sums: ```python func.coalesce(func.sum(input_tokens), 0) func.coalesce(func.sum(output_tokens), 0) ``` So analytics only sees the final persisted `usage` object. **Expected Behavior** For one visible assistant message that performs multiple LLM calls through a native tool loop, Open WebUI should persist aggregated usage for the whole assistant response. Example: ```text LLM call 1: 1,000 tokens LLM call 2: 2,000 tokens LLM call 3: 3,000 tokens ``` Expected persisted assistant-message usage: ```json { "input_tokens": "...sum...", "output_tokens": "...sum...", "total_tokens": 6000 } ``` **Actual Behavior** Only the last LLM call’s usage appears to be persisted. Using the example above, analytics would count approximately: ```text 3,000 tokens ``` instead of: ```text 6,000 tokens ``` **Impact** This causes Open WebUI’s built-in analytics to undercount token usage for tool-heavy conversations. The undercount can be significant because tool loops often resend growing context on every LLM call. Affected analytics endpoints include token aggregation by model/user, since they rely on `ChatMessage.usage`.

## 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. Related items exist and are listed below. - [x] I am using the latest version of Open WebUI. ## Installation Method Git Clone / Docker ## Open WebUI Version Current `dev` / `main` code path containing commit `afaa404fe442435368defb0858cba213baa1725b`. ## Operating System Linux ## Expected Behavior Changing the MinerU API timeout in Admin Settings > Documents > Content Extraction Engine > MinerU should save successfully through `POST /api/v1/retrieval/config/update`. ## Actual Behavior Saving a numeric MinerU API timeout from the WebUI returns HTTP 422 before the backend update handler runs. The WebUI field is an `<input type="number">`, so the request payload sends `MINERU_API_TIMEOUT` as a JSON number. The backend `ConfigForm` currently declares `MINERU_API_TIMEOUT` as `str | None`, which Pydantic v2 rejects for numeric JSON input. ## Steps to Reproduce 1. Run Open WebUI from a version containing MinerU timeout configuration support. 2. Log in as an administrator. 3. Open Admin Settings > Documents. 4. Set Content Extraction Engine to MinerU. 5. Change API Timeout from the default `300` to another numeric value, such as `600`. 6. Save the settings. 7. Observe `POST /api/v1/retrieval/config/update` returning HTTP 422. ## Logs & Screenshots Observed request: ```text POST /api/v1/retrieval/config/update Status: 422 ``` Validation cause: ```text MINERU_API_TIMEOUT expects str | None, but the WebUI number input sends a JSON number. ``` ## Additional Information Related feature request: #18495 Related closed PR: #20016 Related implementation commit: afaa404fe442435368defb0858cba213baa1725b A minimal fix is to allow the update schema to accept both numeric WebUI values and existing string/env values, e.g. `int | str | None`.

Open AI whisper transcription endpoint supports srt, verbose_json, and vtt. https://developers.openai.com/api/docs/guides/speech-to-text It looks like Open WebUI hard codes a simple `{"text": "..."}` response though. https://github.com/open-webui/open-webui/blob/02dc3e689ceac915a870b373318b99c029ddf603/backend/open_webui/routers/audio.py#L1085 It would be nice to just return the requested format.

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description the only method to start loading model into VRAM is by submitting a query, not really ideal. ### Proposed Solution It would be awesome if the drop down model selector box had a button to load the model into memory right then and there. So you could already start the delayed process of loading the model, so that way the model is already being loaded while you begin to formulate your question. By the time your submitting the question, the model is already loaded. just right here in this menu you could put a button to load the model right then and there: <img width="685" height="485" alt="Image" src="https://github.com/user-attachments/assets/c5bf0a8e-d045-4296-91a1-b966722ef314" /> ### Alternatives Considered _No response_ ### Additional Context _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description Loguru stacks in logs include variables which may include secrets. Here is a stack I recently got with @owndev's Google Gemini pipe, showing my API key as an HTTP header: ```log open-webui-1 | File "/usr/local/lib/python3.11/site-packages/google/genai/_api_client.py", line 1464, in async_request_streamed open-webui-1 | response = await self._async_request(http_request=http_request, stream=True) open-webui-1 | │ │ └ HttpRequest(headers={'Content-Type': 'application/json', 'x-goog-api-key': '<my key>', 'user-a... open-webui-1 | │ └ <function BaseApiClient._async_request at 0x73662078f2e0> open-webui-1 | └ <google.genai._api_client.BaseApiClient object at 0x736610ef7a10> ``` ### Proposed Solution Claude suggests this to show stack traces without variables: ```patch Index: backend/open_webui/utils/logger.py IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/backend/open_webui/utils/logger.py b/backend/open_webui/utils/logger.py --- a/backend/open_webui/utils/logger.py (revision 02dc3e689ceac915a870b373318b99c029ddf603) +++ b/backend/open_webui/utils/logger.py (date 1780758307199) @@ -185,6 +185,8 @@ level=GLOBAL_LOG_LEVEL, format=stdout_format, filter=audit_filter, + diagnose=False, # prevents local variable values (incl. secrets) from appearing in tracebacks + backtrace=True, ) if AUDIT_LOG_LEVEL != 'NONE' and ENABLE_AUDIT_LOGS_FILE: try: ``` ### Alternatives Considered I didn't find a way to configure this behavior more finely though I may have missed one. ### Additional Context `GLOBAL_LOG_LEVEL: INFO`

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description Rotating oidc client credentials via client secret cannot be automated easily. Secret has to be changed on both sides and ideally with some overlap window. Especially if the oidc provider is not under your control, changing the secret in the idp is troublesome. ### Proposed Solution Support the private-key-jwt oidc client auth https://oauth.net/private-key-jwt/ This also has some benefits being slightly more secure as not a single long living token is being used. ### Alternatives Considered _No response_ ### Additional Context _No response_

### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Continuing the discussion from #23740 which is closed prematurely. I have to apply the following diff to middleware.py in addition to running a fairly carefully crafted filter function in order for API calls to track outlet() correctly https://gist.github.com/pfn/cdf3631365e6bee59912016b7a953175 With this filter and the diff in place, both non-streaming and streaming API calls through openwebui work for me. Without the filter active and the diff, neither API call use-case works. The diff is primarily required for the streaming use-case. The filter is required for both streaming and non-streaming API calls. ### Desired Solution you'd like I'm relatively happy with how the linked gist solves the problem. If it could be made more elegant, I would like that. ### Alternatives Considered N/A ### Additional Context Discussed in discord. > pfn0 [SJBH], — 7:18 PM > not sure what it is yet (looking at the code, event_emitter shouldn't be the problem) > ctx = await build_chat_response_context(request, form_data, user, model, metadata, tasks, events) > main.py:1851 @Classic this brings event_emitter to life > pfn0 [SJBH], — 7:50 PM > @Classic final finding: streaming_chat_response_handler -> w/o event_emitter -> does not ever call outlet_filter_handler (and if outlet_filter_handler is force-called, assistant_message is not available)

## Bug: ModelEditor marks all `collection_names` knowledge entries as `legacy: true`, causing "Legacy Collection" UI label ### Description In the Model Editor UI (`src/lib/components/workspace/Models/ModelEditor.svelte`), the knowledge mapping logic **unconditionally sets `legacy: true`** for knowledge entries that use the `collection_names` format — the same format that was introduced as the replacement for the old `collection_name` format. This causes the UI to display "Legacy Collection" labels for all knowledge collections, even when they are using the current, non-legacy format. ### Affected File `src/lib/components/workspace/Models/ModelEditor.svelte`, lines 303-320: ```typescript knowledge = (model?.meta?.knowledge ?? []).map((item) => { if (item?.collection_name && item?.type !== 'file') { return { id: item.collection_name, name: item.name, legacy: true }; } else if (item?.collection_names) { return { name: item.name, type: 'collection', collection_names: item.collection_names, legacy: true // <-- BUG: this should NOT be legacy: true }; } else { return item; } }); ``` ### Root Cause Line 315 sets `legacy: true` for entries that have `collection_names` (the **new** format). The `collection_names` array format was introduced in the knowledge table migration (`6a39f3d8e55c_add_knowledge_table.py`) as the replacement for the single `collection_name` string. The old `collection_name` format correctly gets `legacy: true`, but the new `collection_names` format should **not**. The downstream rendering in `src/lib/components/workspace/Models/Knowledge.svelte` line 180-181 uses this `legacy` flag to determine the display label: ```svelte type={file?.legacy ? `Legacy${file.type ? ` ${file.type}` : ''}` : (file?.type ?? 'collection')} ``` So any entry with `legacy: true` gets rendered as "Legacy Collection" regardless of whether the underlying data format is actually legacy. ### Reproduction Steps 1. Create a knowledge collection via the OWUI Knowledge interface 2. Create or edit a model and associate it with that knowledge collection 3. Save the model — the `model.meta.knowledge` array now contains entries with `collection_names: [uuid]` 4. Re-open the model in the Model Editor 5. The knowledge section displays "Legacy Collection" label for each collection ### Expected Behavior Knowledge entries using the `collection_names` format (the current format) should display as "collection" in the Model Editor, not "Legacy Collection". The `legacy` flag should only be `true` for entries using the deprecated `collection_name` (singular) format. ### Actual Behavior All knowledge entries with `collection_names` are marked as `legacy: true` and displayed as "Legacy Collection" in the Model Editor UI, regardless of the database state. Clearing browser cache does not help because the `legacy: true` is set dynamically by the frontend code on every load. ### Environment - Open WebUI version: 0.9.6 (dev-cuda) - Backend: Python/FastAPI with PostgreSQL - Frontend: SvelteKit ### Proposed Fix Change line 315 from `legacy: true` to `legacy: false`: ```typescript } else if (item?.collection_names) { return { name: item.name, type: 'collection', collection_names: item.collection_names, legacy: false // collection_names is the current format }; } ``` ### Additional Context The migration `6a39f3d8e55c_add_knowledge_table.py` introduced the `collection_names` array as the replacement for the old `collection_name` string. The middleware in `utils/middleware.py` (line 2480+) correctly distinguishes between the two formats: - `collection_name` (singular) = legacy format, triggers migration to new format - `collection_names` (array) = current format, used directly The ModelEditor frontend logic does not match this distinction — it treats both as legac

## Describe the bug When using **Call mode** (voice overlay), the chat input field receives focus automatically after every model response finishes. This causes two problems: 1. **Formatting toolbar appears** — if the rich text toolbar is enabled, it pops up after every response, even though it's not needed in hands-free mode. 2. **Mobile keyboard opens** — on Android/iOS PWA, the auto-focus triggers the virtual keyboard every time the assistant finishes speaking, which defeats the purpose of hands-free call mode. ## Steps to Reproduce 1. Open a chat in **Call mode** (microphone icon → call overlay active) 2. Ask any question via voice 3. Wait for the model to finish responding / TTS to finish playing 4. Observe: the chat input field receives focus automatically ## Expected behavior In call mode, the input field should **not** receive focus after a response. The user is operating hands-free; auto-focusing the input serves no purpose and actively disrupts the experience (especially on mobile). ## Current behavior The input receives focus after each response, causing: - The rich text formatting toolbar to appear - The mobile virtual keyboard to open (PWA on Android/iOS) ## Code analysis The codebase already contains a partial fix with an explicit comment in `src/lib/components/chat/Chat.svelte`: ```js // focus on chat input (skip during voice call to avoid triggering mobile keyboard) if (!$showCallOverlay) { chatInput?.focus(); } ``` However, there are several other `.focus()` calls in `Chat.svelte` and `MessageInput.svelte` that do **not** check `$showCallOverlay`, e.g.: - `Chat.svelte` ~line 261 (navigateHandler) - `Chat.svelte` ~line 877 (onMount / init) - `Chat.svelte` ~line 1386 (model change handler, inside `setTimeout`) - `MessageInput.svelte` ~line 1088 (onMount) - `MessageInput.svelte` ~line 1165 (modal close callback) All of these need the same `if (!$showCallOverlay)` guard. ## Environment - Open WebUI version: current - Platform: Desktop + Android PWA - Browser: Chrome ## Additional context This issue has existed for a long time and is particularly disruptive on mobile PWA where the keyboard covers half the screen after every single response in what is supposed to be a fully hands-free interaction mode.

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description I don't know when a file has been uploaded so I can send the message. ### Proposed Solution When you still have files waiting to be sent, you can press the send button, and it turns into a spin wheel and automatically sends when the file/s are finished uploading. ### Alternatives Considered _No response_ ### Additional Context _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description When using Firecrawl as the web loader engine (`WEB_LOADER_ENGINE=firecrawl`), there is currently no way to configure Firecrawl-specific scraping options through environment variables or the admin panel. Specifically: 1. **`onlyMainContent`** (default: true): A deterministic HTML-level filter that excludes headers, navs, footers, etc. No LLM involved. 2. **`onlyCleanContent`** (default: false, Beta): Runs an additional **LLM-based pass** over the generated markdown to remove residual boilerplate that `onlyMainContent` can miss. This is particularly useful for RAG applications as it produces cleaner, LLM-ready content. 3. **`formats`**: Control output formats (markdown, html, links, etc.) Currently, the `SafeFireCrawlLoader` class accepts a `params` dictionary, but there's no mechanism to populate it with user-defined Firecrawl options. The only configurable Firecrawl environment variables are: - `FIRECRAWL_API_KEY` - `FIRECRAWL_API_BASE_URL` - `FIRECRAWL_TIMEOUT` ### Proposed Solution Add environment variables and corresponding admin panel UI options to configure Firecrawl-specific scraping parameters: **Proposed Environment Variables:** # Only return main content, excluding headers/navs/footers (default: true) # This is a deterministic HTML filter, no LLM involved FIRECRAWL_ONLY_MAIN_CONTENT=true # Beta: Run additional LLM-based pass to remove residual boilerplate (default: false) # Uses LLM to clean markdown output, preserving headings, lists, tables, code blocks FIRECRAWL_ONLY_CLEAN_CONTENT=false # Output formats (default: "markdown") # Options: markdown, html, rawHtml, links, images, screenshot, json, etc. FIRECRAWL_FORMATS="markdown" **Implementation Details:** 1. Add these environment variables to `backend/open_webui/config.py` similar to existing Firecrawl variables 2. Modify `SafeFireCrawlLoader` initialization in `backend/open_webui/retrieval/web/utils.py` to pass these options to `scrape_firecrawl_url` 3. Update the admin panel (Settings > Documents > Web Loader) to expose these options when Firecrawl is selected as the engine 4. Update documentation in `docs/reference/env-configuration.md` **Example Usage:** # docker-compose.yml environment: - WEB_LOADER_ENGINE=firecrawl - FIRECRAWL_API_KEY=fc-xxxxx - FIRECRAWL_ONLY_MAIN_CONTENT=true - FIRECRAWL_ONLY_CLEAN_CONTENT=true # Enable LLM-based cleaning for better RAG quality - FIRECRAWL_FORMATS=markdown ### Alternatives Considered 1. **Using the external web loader**: Configure a custom Firecrawl service with the desired options, but this requires maintaining additional infrastructure. 2. **Using Firecrawl Pipelines**: Install the Firecrawl Open-WebUI-Pipelines extension, but this adds complexity and may not integrate seamlessly with the built-in web search and RAG features. ### Additional Context **Why this matters:** - **Better RAG quality**: `onlyCleanContent` uses LLM to produce cleaner markdown by removing navigation menus, footers, ads, and other non-content elements that `onlyMainContent` might miss, leading to better embeddings and retrieval quality. - **Reduced token usage**: Cleaner content means fewer tokens sent to LLMs, reducing costs and improving response times. - **Flexibility**: Users can choose between fast deterministic filtering (`onlyMainContent`) and more thorough LLM-based cleaning (`onlyCleanContent`) based on their needs. **Firecrawl API Reference:** According to Firecrawl's official API documentation, the `/v2/scrape` endpoint accepts: { "url": "https://example.com", "formats": ["markdown"], "onlyMainContent": true, "onlyCl

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description This is related to an old CommonMark issue: https://github.com/commonmark/commonmark-spec/issues/650, which breaks UX for CJK users (Chinese + Japanese + Korean ≈ 1.6 billion speakers in the world). <img width="2169" height="462" alt="Image" src="https://github.com/user-attachments/assets/0a8698e8-ab18-4d2e-a987-e64a9778662c" /> ### Proposed Solution https://github.com/tats-u/markdown-cjk-friendly can fix this. ### Alternatives Considered _No response_ ### Additional Context _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description Right now only Dynamic Client Registration (DCR) or static OAUTH is supported. Where the latest spec says that CIMD should be supported. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents ### Proposed Solution Support Client ID metadata document ### Alternatives Considered _No response_ ### Additional Context _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description OpenWebUI already shows a loaded/running indicator for native Ollama models when Ollama-specific metadata such as `expires_at` is available. This is very useful because users can see whether selecting a model will likely require loading/switching models. Pipe/manifold models currently appear to support returning model entries primarily as `{ "id": "...", "name": "..." }`. This makes it difficult for custom providers to expose equivalent runtime state, even when the backend can determine it. -- I have a Pipe Function that exposes Letta agents as individual OpenWebUI models. Each Letta agent may use an underlying Ollama model. The Pipe can query Letta for the agent configuration and Ollama `/api/ps` for currently loaded models, including `expires_at`. However, there does not appear to be a supported way for the Pipe to pass that loaded/running state back to OpenWebUI so the UI can show the same kind of indicator that direct Ollama models receive. ### Proposed Solution Allow `pipes()` model definitions to include optional status metadata, for example: - `loaded: true | false` - `expires_at: string | null` - `provider_model: string` - `runtime.provider: "ollama"` - or an `ollama` metadata object compatible with the existing Ollama model indicator logic OpenWebUI could then render the existing loaded/running indicator for custom Pipe/manifold models when this metadata is present. ### Alternatives Considered Annotating model names: Works but fragile, can be overridden in the UI. doesn't integrate with existing indicators. Status messages at request time: only visible after sending a message and not during model selection, defeating the purpose in some cases. Separate status/info page: feasible, but disconnected from the model selector and adds user friction. ### Additional Context _No response_

### Check Existing Issues - [x] I have searched all existing **open AND closed** issues and discussions and found none comparable to my request. ### Verify Feature Scope - [x] I believe this feature request is appropriately scoped for the Issues section as described above. ### Problem Description When using mlx-audio.server the server returns nd-json by default for live transcriptions to be able to stream them. This breaks open webui because it expects json instead. ### Proposed Solution A **Additional Parameters** Box for json parameters like TTS has could solve this. We could supply `"response_format": "json"` using that. ### Alternatives Considered omni-mlx-server sadly breaks too and has some other quirks because it utilizes the same stack. ### Additional Context _No response_

Related Discussion: https://github.com/open-webui/open-webui/discussions/25856 ## Summary Request to add [iFlow Search](https://platform.iflow.cn/docs/) as a native Web Search provider, plus an optional Web Fetch loader using the same API credentials. I opened [Discussion #25856](https://github.com/open-webui/open-webui/discussions/25856) first per contribution guidelines and am following up here for visibility while awaiting maintainer feedback. ## Proposed integration | Layer | Config | iFlow API | | --- | --- | --- | | Web Search | `WEB_SEARCH_ENGINE=iflow` | `POST /api/search/webSearch` | | Page fetch | `WEB_LOADER_ENGINE=iflow` | `POST /api/search/webFetch` | Shared configuration: - `IFLOW_API_KEY` - `IFLOW_BASE_URL` (default `https://platform.iflow.cn`) Admin UI: - Settings → Web Search → Search Engine → **iFlow Search** - Settings → Web Search → Web Loader Engine → **iFlow Web Fetch** ## Motivation iFlow provides web search and page fetch behind one API key. This matches Open WebUI's existing split between Web Search engines and Web Loader engines (similar to Tavily / Firecrawl), while sharing one small client implementation. ## Implementation status (local, not yet submitted) - Web Search provider + Web Fetch loader implemented locally on branch `feat/iflow-search-provider` - Mock tests passing; manual UI verified - No new Python dependencies - **Image Search is out of scope** for the first PR (separate API route, not part of the Web Search provider model) ## Questions for maintainers 1. Is it acceptable to submit Web Search provider + Web Fetch loader in **one atomic PR**, given the shared client and config? 2. Should documentation go in a separate PR to `open-webui/docs`, as usual? 3. Please confirm that **`dev`** is the correct target branch. I will wait for feedback before opening the PR. cc @tjbck @Classic298