Choosing Add Details, More Concise, or typing a suggestion under a reply sent the model your original question followed straight by the bare instruction, with the reply itself missing, so it answered the instruction on its own (for example "OK, I'll keep answers shorter") instead of rewriting that reply. The model now receives the reply it is being asked to change, so it returns a shorter, more detailed or altered version of it. Plain Try Again and temporary chats were not affected.
Fixes#33083
* 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.
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.
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>
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
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 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
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
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) Has been cancelled
With Redis, if every tool server was unreachable when Open WebUI loaded the tool server list, it cached an empty list and served it forever. The tools stayed missing from chats and the tool list after the servers came back, until a restart, a save in the tool server settings or a manual delete of the cached Redis key. An empty cached list is now only trusted while no OpenAPI tool server is enabled, so the next request that loads tools fetches the servers again, the same way terminal servers already behave. While an enabled server stays unreachable, each such request tries it again and can wait for its timeout.
Fixes#29573
Adding a custom parameter named tools to a model, for example to turn on a provider's native web search, made Open WebUI drop all of its own tools for that model: notes, knowledge, tasks and any tools attached to the model stopped working, and attached files lost their context. Those tools now stay, and the model's custom tools are sent alongside them. API calls that pass their own tools, or an empty list to turn tools off, behave as before.
Fixes#32528
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/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
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/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/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: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
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
When Open WebUI authenticates to the OAuth provider with client_secret_basic, either because OAUTH_TOKEN_ENDPOINT_AUTH_METHOD is set to it or because an MCP tool server's OAuth provider only offers that method, sign-in sent the client ID and secret in an HTTP Basic header but the token refresh always put them in the request body. Providers that only accept Basic rejected every refresh with invalid_client, so once the access token expired Open WebUI deleted the user's saved OAuth tokens, and model connections and tool servers set to forward the user's OAuth token stopped working until the user signed in again. The refresh now authenticates the same way sign-in does for client_secret_basic, with the credentials only in the Basic header. Setups using client_secret_post, or leaving the setting unset, still send the credentials in the request body exactly as before.
Fixes#32506
With audit logging on, requests that used an API key in the x-api-key header (what Anthropic SDKs send) worked but never showed up in the audit log, because the audit check only looked for a Bearer token or a session cookie. These requests are now logged with the user the key belongs to, and this also covers a custom header set through CUSTOM_API_KEY_HEADER. Failed attempts with a wrong key in that header now appear in the log without a user, just like a wrong Bearer key. A malformed Authorization header with no other credential is no longer logged, since it can never authenticate.
With tool approval set to ask, a knowledge or file tool the user approved ran and answered, but no sources were saved on the reply or shown below it. The same call without approval listed them as usual. The sources of an approved call are now saved and shown the same way.
Fixes#32436
With websocket support turned off, the browser falls back to HTTP long polling and every poll was written to the audit log as its own entry, flooding it. The same traffic over a websocket was never audited, and AUDIT_EXCLUDED_PATHS only matches API routes, so there was no way to filter it out. Polling requests are now skipped as well, so the audit log looks the same whichever transport is in use.
Fixes#31871
Custom headers on connections and tool servers could pass the chat, message, user and task to downstream services, but not which model the request was for. Chat requests can now use {{MODEL_ID}}, which holds the ID of the model handling the request; for a workspace model that is the workspace model's own ID. In a multi-model chat each model's request carries its own ID, so downstream services can route by model or log usage per model.
Fixes#30006
The audit log only showed which model a request used inside the logged request body, which is cut off at MAX_BODY_LOG_SIZE, so the model went missing whenever a long prompt came before it. Audit entries for chat and completion requests, including the OpenAI, Ollama and Anthropic-compatible endpoints, now carry a model_id field with the model the client asked for, at every AUDIT_LOG_LEVEL and however long the request is. Other requests log it as null.
Fixes#30097
Pipes and tools received None instead of a list of files on messages without attachments, which does not match the docs and breaks plugins that loop over the files. Pipes and tools now get an empty list in that case.
Fixes#32379
Connecting an OAuth 2.1 MCP tool server such as Canva failed with "OAuth client registration is still invalid after re-registration" whenever Cloudflare answered Open WebUI's own server-side check of the provider's sign-in page with a bot challenge. The challenge page repeats the requested address, which contains the redirect URL, so Open WebUI read it as the provider rejecting its registration. Open WebUI now skips its check when it gets a bot challenge, and the browser goes on to the provider's sign-in page as usual. Real provider errors about an unknown client or redirect URL still trigger re-registration as before.
Fixes#32363
