* perf: renaming a folder or deleting all chats takes seconds when many users are online
Renaming, sharing, moving or deleting a folder, and deleting all chats, each made the server recheck access for every chat that any online user had open in a browser tab, one database lookup at a time, before the request finished, and every one of those open chats reloaded its contents afterwards. Any user can do these, so with a few thousand people online every such click took several seconds and reloaded everyone's open chat. Owners keep access to their own chats (a role change or account deletion already disconnects them), so the recheck now skips owners entirely, with no lookup and no reload, and only checks people viewing someone else's chat and chats that no longer exist. Anyone who lost access is still removed from the chat as before.
Postgres 16, one open chat per online user, 2% of them viewing someone else's chat, time for a folder rename (the other actions above run the same recheck):
| Online users | No Redis, before | No Redis, after | Redis, before | Redis, after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.2 s | 0.12 s | 2.5 s | 0.23 s |
| 3,000 | 6.9 s | 0.60 s | 7.7 s | 0.78 s |
* refac: collect the open chats with a plain loop
Same behaviour, the owner lookup now reads more plainly.
* refac: shorten the owner comment in the chat access sweep
* fix: MCP tools that list their arguments under anyOf are called with no arguments
When an MCP tool described its input as alternatives, for example a page by id or by path and locale, and had no top-level list of fields, every argument the model sent was dropped and the tool was called with nothing, so the server rejected the call. Arguments for MCP tools now reach the server as the model sent them, and the MCP server checks them against its own schema. Other tool types still keep only the arguments their schema lists.
Fixes#32898
* refac: shorten the MCP arguments comment
The comment now only says why MCP tools skip the argument filter.
* fix: MCP tool errors reach the model as a Python list dump instead of the server's message
When an MCP tool server answered a call with an error, the model got a Python dump of the whole result list, with quotes, annotations and meta fields, instead of the error text the server wrote. Line breaks in the message were escaped as well, so a validation error listing the missing argument was hard to read and models tended to retry the same broken call. The model now gets the server's error text as written, the same way successful results already arrive.
Fixes#32918
* refac: drop the fallback text for MCP errors with no message
The error now carries only the text the server sent.
* fix: keep a readable error when an MCP error has no text
MCP error results that only carry images, audio or resources now give the model a short error message instead of an empty one.
* fix: Terminal capability shows while no terminal server exists
The Terminal capability showed in the model editor even when the admin had set up no terminal server and direct integrations were off, which is the default, so it did nothing. It now shows only when an enabled terminal server exists or users can add their own through direct integrations, and the value saved on a model is kept. The server now reports whether any enabled terminal server exists, since the editor itself only sees the servers the current user can access and a model can be shared with other users.
Refs #32830
* fix: hide the default terminal picker when no terminal is available
The model editor still showed the default terminal line when no terminal server or direct integration was available. It now follows the same rule as the Terminal capability.
Fixes CVE-2026-111497 (the "Node2Shell"/"HTTP2Shell" Brotli decoder flaw). Open WebUI decodes Brotli responses automatically whenever it fetches from a model provider, a tool server or a web page, so a malicious server could hand it a crafted response that hits the vulnerable decoder. Both packages now use the fixed releases.
The required parameters of OpenAPI tool server tools, Open Terminal included, were sent to the model in a random order that could change every time Open WebUI restarted. The tool list sits at the start of every prompt, so a different order made every prefix cache on the model side miss, and long chats were processed again from scratch after a restart. The required parameters now keep the order the tool server declares, so the tool list stays identical across restarts.
Picks up the 3.14.4 security release and the 3.14.5 fixes. Open WebUI only uses aiohttp as a client, and the fixes that apply there stop Secure cookies from going out over plain HTTP, stop a connection from being reused after a cancelled upload, fix a memory leak on upstream websocket connections, and keep a websocket open when the server sends a control frame with the RSV1 bit set. Its URL library yarl moves to 1.25.1 because the new aiohttp requires it. Checked with a fresh install, the startup check, the unit and outbound HTTP integration tests, and a streamed chat.
Pillow, the image library behind image uploads, edits and PDF image reading, moves to 13.0.0, the major release that carries fixes for crafted image files in its JPEG, TIFF, GIF, BMP and other decoders. No code had to change, since nothing in Open WebUI uses the features this release removed or changed. Verified with a real install, a server boot, the unit tests and the image-related integration tests, plus live runs of chat image uploads, image editing, PDF image extraction and profile pictures that gave the same results as the current version.
pypdf moves from 6.7.5 to 6.21.2, which brings many fixes for malformed PDFs that could hang the server or exhaust its memory during upload. Its text extraction also changed a little: some line breaks inside a block of text now come out as spaces, so a re-uploaded document can be split into chunks slightly differently, with the same words. cryptography picks up its 48.0.1 patch release, which ships wheels built against OpenSSL 4.0.1. Verified with a real install, the startup check and the upload, retrieval and sign-in tests, plus a text PDF and an image PDF that give the same extracted text as before.
Upgrade the MCP SDK to 2.3.0 and build MCPClient on its Client in
mode='auto', which probes server/discover for the stateless 2026-07-28
protocol and falls back to the initialize handshake for legacy servers.
MCPClient's public surface is unchanged.
MCP_INITIALIZE_TIMEOUT becomes the session's default request timeout, so
it bounds the legacy handshake, tool listing and resource reads; tool
calls keep using AIOHTTP_CLIENT_TIMEOUT_TOOL_SERVER.
Relates to #29778
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Tool servers and Open Terminal connections a user added in their Integrations settings kept loading and were still used in every chat after the admin turned Direct Integrations off, which only hid the settings tab. They are now ignored while Direct Integrations is off, for admins and users alike, and the server ignores them even when a request still includes them. The saved connections stay in each user's settings and come back as soon as the switch is turned on again.
Since 0.12.3, with the Redis websocket manager, WEBSOCKET_REDIS_ROOM_CHANNELS on (the default) and retry_on_timeout in WEBSOCKET_REDIS_OPTIONS (as in the documented example), an instance could stop accepting new browser connections until it was restarted. Before accepting a browser, the instance asks Redis to confirm its subscriptions. If its Redis connection dropped while that confirmation was still on its way, the Redis client reconnected silently and the confirmation was lost, so that browser and every later one waited forever. The instance now asks Redis again after the reconnect, so the waiting browser connects as soon as Redis is back.
Fixes#33008
Moves the web server to its latest release. The new features in 0.52 to 0.54 (experimental HTTP/2, a new HTTP parser, extra event loop choices) are all opt-in and the rest are small connection and websocket fixes, so the settings Open WebUI starts the server with stay the same and admins need no action. Checked on a fresh install: the app boots, the unit, socket, streaming and startup tests pass, and a chat streams over a websocket.
Settings > Interface offered the title, follow-up and chat tag auto-generation switches even when the admin turned those generations off, so switching them did nothing. Each switch now only shows while its generation is on. The settings for keeping and inserting follow-up prompts stay, because they still apply to follow-ups saved in existing chats. Saved choices are kept and apply again once the admin turns the generation back on.
Refs #32830
Editing a WebP image (an uploaded one, or one generated by a provider that returns WebP) failed in the Docker image. Python only learns the WebP type from a system file the image does not ship, so the picture went to the image provider labelled with no type at all, and providers rejected it. WebP is now registered at startup like the other types Open WebUI already sets, so the provider receives it as image/webp.
Fixes#32899
Every message posted in a channel waited until the server had re-checked the login of every online member of that channel, one connected session at a time with a few database lookups each, before the post went through. In a large channel that added seconds to every single message. The result only decides who gets a notification, and the message is already delivered to everyone before this step, so the check now runs right after the post returns, as the first step of the work that sends notifications and bot replies. Members are re-checked exactly as before, including disconnecting any session whose login is no longer valid.
Postgres 16, standard channel, median time for a post to return:
| Online members | Before | After |
| --- | --- | --- |
| 100 | 0.37 s | 0.03 s |
| 300 | 1.6 s | 0.05 s |
| 1,000 | 3.4 s | 0.10 s |
Since 0.12.0, every group save and every member add or remove made the server recheck access for every chat that any online user had open in a browser tab, one database lookup at a time, before the save finished. With a few thousand people online, saving a group took several seconds, and every one of those open chats reloaded its contents afterwards. When a group change can affect what someone may see, the server already makes that person's browser reconnect, and an open chat checks its access again on reconnect, so group changes now skip the recheck for everyone else. Folder and chat sharing changes keep it.
Postgres 16, 2,000-member group, one open chat per online user:
| Online users | Saving the group without permission changes, before | after | Adding a member, before | after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.0 s | under 0.05 s | 2.2 s | under 0.05 s |
| 3,000 | 6.7 s | under 0.05 s | 6.6 s | under 0.05 s |
When a group change affects its members (new permissions, parent group or default models, or deleting the group), the server makes every member's browser reconnect so it picks up the new permissions without a page reload. To find each member's connections it read through the whole list of connected users again for every single member, so saving a 2,000-member group with 3,000 people online spent almost 9 seconds on this with Redis as the websocket manager, and about 1 second without. It now finds all members' connections in one pass.
Changing one permission on a 2,000-member group, time the save spends making members reconnect:
| Online users | Redis, before | Redis, after | No Redis, before | No Redis, after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.8 s | 0.15 s | 0.09 s | <0.01 s |
| 3,000 | 8.7 s | 0.28 s | 1.2 s | <0.01 s |
Importing a model JSON on the Workspace Models page as a regular user skipped any model whose ID already belonged to another user's model they cannot edit, or to a model from one of the instance's connections such as OpenAI or Ollama. There was no message, so the model just never showed up. The import now stops at that model with the error "Uh-oh! This model id is already registered. Please choose another model id string."; the models before it in the file are imported and the ones after it are not. Admins, and users who can edit the existing model, are unaffected and still overwrite it.
The Docker image now runs Python 3.12 on Debian 13 (trixie) instead of Python 3.11 on Debian 12, and the pip install docs recommend 3.12. Image size stays about the same: the slim image is 1 MB smaller and the standard image is about 50 MB larger, mostly from the newer ffmpeg and pandoc that Debian 13 ships. Admins should know that custom functions, tools and anything installed with pip inside the container now run on Python 3.12, so a package that only has builds for 3.11 needs a newer version. Installing with pip still works on both Python 3.11 and 3.12.
Picking a model control option, such as a Thinking level, needed both the Allow Chat Controls and Allow Chat Params permissions, so admins had to hand out the Advanced Parameters panel just to let people pick a preset. Model control picks now work for anyone with access to the model and are saved per model to their account. Allow Chat Controls still hides the Chat Controls panel and Allow Chat Params still hides the Advanced Parameters panel, in the chat and in personal Settings. Parameters a person saves to their account are no longer filtered by these two permissions, since any chat message could already set any parameter without them.
Fixes#32626
A self-hosted MinerU 4.x server started with an API key rejected every document with a 401, even with the key filled in under Documents settings, because local mode never sent it. The key is now sent with the document requests to a 4.x server whenever one is set. Servers without a key are unaffected.
Fixes#32836
A model connection with its auth type set to OAuth only forwarded the user's sign-in token for requests coming from the browser. The same user calling the API with their bearer token or an API key sent nothing upstream, so an SSO-protected model server rejected every API call and its models could not be listed or used. These connections now fall back to the user's latest sign-in session the same way tool servers already do.
Fixes#32820
With OAuth 2.1 (Static), when the authorization server did not accept the client secret as a form field, Open WebUI used whichever auth method the server's metadata listed first. X Ads lists "none" (public client, no secret) first, so the token exchange went out without the configured client secret and X rejected it with "Missing valid authorization header". When the server supports HTTP Basic auth, the secret is now sent that way, no matter which method it lists first.
Fixes#32813
Create and publish Docker images with specific build args / build (map[arch:linux/amd64 runner:ubuntu-latest], map[build_args:USE_CUDA=true
USE_CUDA_VER=cu126
free_disk:true name:cuda126 suffix:-cuda126]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/arm64 runner:ubuntu-24.04-arm], map[build_args:USE_CUDA=true
USE_CUDA_VER=cu126
free_disk:true name:cuda126 suffix:-cuda126]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/arm64 runner:ubuntu-24.04-arm], map[build_args:USE_CUDA=true free_disk:true name:cuda suffix:-cuda]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/arm64 runner:ubuntu-24.04-arm], map[build_args:USE_OLLAMA=true free_disk:false name:ollama suffix:-ollama]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/arm64 runner:ubuntu-24.04-arm], map[build_args:USE_SLIM=true free_disk:false name:slim suffix:-slim]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/amd64 runner:ubuntu-latest], map[build_args: free_disk:false name:main suffix:]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/amd64 runner:ubuntu-latest], map[build_args:USE_CUDA=true free_disk:true name:cuda suffix:-cuda]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/amd64 runner:ubuntu-latest], map[build_args:USE_OLLAMA=true free_disk:false name:ollama suffix:-ollama]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/amd64 runner:ubuntu-latest], map[build_args:USE_SLIM=true free_disk:false name:slim suffix:-slim]) (push) Waiting to run
Create and publish Docker images with specific build args / build (map[arch:linux/arm64 runner:ubuntu-24.04-arm], map[build_args: free_disk:false name:main suffix:]) (push) Waiting to run
Context compaction summarizes older messages and keeps the most recent ones verbatim, splitting the chat at a user message. It skipped the chat whenever the first follow-up message sat too close to the end to keep the share set in the Retained Messages admin setting. So a fresh chat with one question and one reply carrying a lot of tool output never compacted: the follow-up failed with a context length error, and regenerating or editing that follow-up failed the same way. Now compaction splits at the first follow-up message in that case, keeping fewer messages than Retained Messages asks for, so the chat keeps working. Chats where a split already met that share compact as before, and compaction between tool calls is unchanged.
Fixes#32781
When a tool on a server built with the standalone FastMCP package returned a list, the model got the list twice, once as plain text and once as structured data, so every list result cost two to three times the tokens. That package sends the whole list as a single piece of text, a format Open WebUI did not recognise as a duplicate. The list now reaches the model once, and structured data that the text does not already contain is still passed along.
Fixes#32719
When the voice provider ended a realtime call, the overlay sometimes said "Voice connection failed" instead of "Voice provider connection closed". It happened when microphone audio reached the server at the same moment the provider hung up, so forwarding that audio failed and the generic error was shown. Anything that fails to reach the provider because it just closed the connection now reports that the provider closed the call.
Fixes#32729
When a model sent the ask_user questions as anything other than a list, for example a JSON-encoded string, the tool answered "ask_user requires 1-3 questions." The model had sent the right number of questions, so it did not understand the error and often repeated the same call in a loop. It now gets a separate error saying the questions must be an array of question objects, and the count error only appears when the count is actually wrong.
Fixes#32662
Closing a page while the server was still sending it data (a file's processing status, a chat export) could interrupt a database read halfway. On SQLite the connection used for it was then never given back, and a later unrelated request could hang forever when that connection was finally cleaned up; once enough were lost, every request needing the database waited 30 seconds and failed with a 503. The connection is now kept and rolled back instead of being thrown away inside the interrupted request, and the session is closed once instead of twice, as either alone still lost connections. Closing 600 chat exports and 300 file status streams mid-load on SQLite used to lose 60 (the whole pool in that test) and 56 connections, now none; Postgres lost none before or after.
Fixes#32609
With ENABLE_FORWARD_USER_INFO_HEADERS turned on, voice calls in Realtime mode connected to the configured realtime provider without any user info headers, so a gateway in front of the provider could not tell which user was on the call. The call connection now sends the same user headers (or the signed user JWT, when configured) as chat requests and realtime text-to-speech already do.
When the model asked the user a question, or a tool call was approved or rejected, the reply was saved in a way that broke adding anything to it later in the same turn. If the model then generated an image, the image was created but never shown, the tool returned "unsupported operand type(s) for +: 'NoneType' and 'list'" and the model kept retrying, generating more hidden images. Progress status updates for that reply were also silently dropped. Both now work after a question or tool approval.
Fixes#32678
