When files were attached to a chat message and one of them was already attached to that chat (on the same message or another one), none of the new files were recorded as part of the chat, and nothing showed up in the logs. The sender still saw every file in their own chat, but anyone opening a shared copy of the chat could not open the new ones. Files already attached to the chat are now skipped and the new ones are recorded normally.
Fixes#31648
iPhone photos were only converted to JPEG when the browser reported their type as exactly image/heic. Firefox reports image/heif and some browsers report no type at all, so those photos were uploaded as HEIC and vision models failed with an error. When conversion did run, the JPEG was still uploaded with the HEIC file name and type, so the model was told it was HEIC anyway. HEIC and HEIF photos are now converted whatever type the browser reports and are uploaded as a .jpg with the JPEG type, in chats, channels and notes.
Fixes#28411
Since 0.11.1, when a filter function wrote part of the reply before the model answered (for example some text and an HTML block), the artifact preview opened and then closed straight away. The page showed the filter text but was never sent it as part of the reply, so the model's first output overwrote it, the page briefly saw no HTML block and closed the preview. The filter text is now sent to the page before the model's output, so the preview stays open.
Fixes#31643
When a reply contained an artifact and the preview opened automatically, it could check for artifacts before they had been picked up from that reply, find none and close again. This happens occasionally in normal chats, with or without filters, and is older than 0.11.1. The preview now looks for artifacts again at the moment it opens, so it stays open. It is a separate cause from #31643, found while looking into that issue.
When someone mentioned a user or channel in a channel message, the notification toast and the browser notification showed the raw mention markup, including the internal id. They now show the mention the same way the message does in the channel, for example "@Alex".
Fixes#31586
On an Amazon Bedrock OpenAI-compatible connection, GPT-5.6 and GPT-6 models have ids like `us.openai.gpt-6-sol` or `openai.gpt-6-luna`. These were not recognised as new OpenAI models, so `max_tokens` went upstream unchanged and Bedrock rejected it with a 400. Title and emoji generation failed on every chat, and any request with a token limit failed too. Setting `max_completion_tokens` by hand did not help, because non-OpenAI URLs convert it back to `max_tokens`.
`is_openai_new_model()` now drops a leading `openai.` or `<region>.openai.` (`us.`, `eu.`, `global.`, `us-gov.`) before matching, so these ids get the same handling as bare `gpt-5` ids. Ids that are not new models, such as `openai.gpt-oss-120b-1:0` and `gpt-4o`, are unchanged, and so is the LiteLLM `openai/` prefix.
Fixes#30510
Tools that return inline HTML showed no embed at all when the HTML contained an entity such as `"` or `"`, and HTML containing `&` or `<` showed up with those turned into real characters. The chat view unescaped HTML entities in a tool's embeds, arguments and file links, which is only right for chats saved by older versions, so on current chats it changed the tool's own HTML before displaying it. Embeds, tool arguments and file links now show exactly what the tool returned, and older chats render as before.
Fixes#28085
Ejecting a loaded model from the model selector failed with a certificate error on llama.cpp and Ollama connections served over HTTPS with a self-signed or internal CA, even though chatting with the same connection worked. The unload request skipped the AIOHTTP_CLIENT_SESSION_SSL setting and always verified against the default system certificates, so setting it to a CA bundle or to false had no effect there. It now uses that setting, the same way chat requests to the connection already do.
Fixes#31371
After a reply, the first suggested follow-up question sits as grey ghost text in the empty chat input. Typing into it with an input method (Chinese, Japanese or Korean) broke the word being composed: on iOS the input lost focus after the first character, and in Chromium the first letter was left behind, so typing "ni" and picking "你" gave "n你". Clearing the ghost text rebuilt the input's line of text while the keyboard was still composing the word. The ghost text is now drawn over the empty input without being written into it, so input methods work again, and Tab to accept it and the follow-up buttons under the reply behave as before.
Fixes#31372
MCP tool servers that sign in through Google, such as Google's hosted Gmail, Drive and Calendar servers, never got a refresh token, because Google only issues one when the sign-in explicitly asks for offline access. When the one-hour access token ran out the refresh failed and the connection was removed, so every user had to sign in again every hour. When the server's sign-in page is Google's, the sign-in now asks for offline access and a fresh consent, so the token renews on its own. Other providers get the same sign-in request as before, and existing Google connections pick this up the next time the user signs in.
Fixes#28319
Every member listed in a SCIM group response came back with "$ref": null, so identity providers had no link from a group member to that user's SCIM resource. Members now carry the URL of the user they point to, on both the single group and the group list responses.
Fixes#31525
An automation whose schedule ends after a fixed number of runs (COUNT in its RRULE) showed extra future runs in the Scheduled Tasks calendar after each run. With COUNT=3, the calendar kept showing three upcoming runs after the first and second run, although only the remaining ones execute. The calendar now counts runs from the schedule's own start date, the same way automations are actually run, so it shows exactly the runs that are still going to happen. The 5000-entry display limit now only counts entries inside the visible range, so very frequent schedules that started shortly before it no longer show up short or empty.
Fixes#31600
With the Artifacts pane open, the Copy Last Code Block shortcut put the pane's full HTML document on the clipboard instead of the last code block in the chat. The pane opens on its own whenever a reply contains an HTML block, so the shortcut was wrong in every such chat.
The shortcut clicks the last Copy button of chat code blocks on the page, and the Artifacts Copy button carried the same marker class. The pane renders after the messages, so it always won. The marker class is now removed from the Artifacts button. It had no styling attached, so the button looks and works as before.
Fixes#31476
When a background sub-agent finished while the model was still writing the answer that started it, the sub-agent's report was placed as a reply to the previous answer instead. Once the answer ended, the chat switched to that other branch of the conversation, which hid the latest question and answer, and the model replied to the report without seeing that question and answer. The report now follows the answer that started the sub-agent (or the newest completed reply after it), so the conversation stays on one branch.
Fixes#31507
ENABLE_ORJSON has shipped as an option since v0.11.0 (2026-07-27), five releases and two months ago, and orjson is already installed with every instance. The only two problems ever found with it (rare line break characters splitting a stream, and extra encoding options being ignored) were fixed in v0.11.1 and nothing has come up since. The regression suite at https://github.com/open-webui/tests now runs 222 tests with the option on and off side by side, on SQLite, Postgres, several workers sharing one Redis with some on and some off, and in the browser: chats, completions for every provider format, tool calls, citations, all workspace and admin data, exports and imports, notes and live socket updates behave the same, and every API response is byte for byte identical. The only differences were in how non-English text gets saved to the database, where the standard encoder is the one with bugs (missed searches and too small size limits). Turning it on by default gives every instance the speedup measured in #27583 (live socket updates encode 17x and decode 3x faster), and ENABLE_ORJSON=false keeps the old encoder.
With ENABLE_OTEL, ENABLE_OTEL_TRACES and ENABLE_OTEL_LOGS all on, the collector received each log line twice, once with code location attributes and once without, because the logging instrumentation for traces now attaches its own log exporter next to Open WebUI's. It now keeps trace context on log lines without adding that second exporter, so each log line reaches the collector once, and OTEL_PYTHON_LOG_AUTO_INSTRUMENTATION=false is no longer needed as a workaround.
Fixes#31524
Starting a new chat from the search dialog with "Start a new conversation" sent a different message than the one typed: everything from a # or & onwards was dropped and + turned into a space. The typed text now reaches the new chat unchanged.
Fixes#31469
Choosing jinaai/jina-colbert-v2 as the reranking model failed on the current transformers release with "'HF_ColBERT' object has no attribute 'all_tied_weights_keys'", and saving the Documents settings quietly switched hybrid search back off. The ColBERT reranker now finishes loading, reranks search results and hybrid search stays on after saving.
Fixes#31522
With Weaviate as the vector database, a chunk identical to the query (distance 0) was treated as having no distance and got a relevance score of 0. Perfect matches could land at the bottom of the results or fall below the relevance threshold. They now score 1 as expected.
Fixes#31527
Since v0.11.4 a new visitor always got their browser's language even when an admin set DEFAULT_LOCALE, because the browser language was remembered as if the user had picked it, so the configured default never applied. The configured default now applies on the first visit again, as it did up to v0.11.3. A language the user picks in Settings and a ?lang= link still take precedence, and instances without DEFAULT_LOCALE keep following the browser language.
Fixes#31548
With WEBSOCKET_MANAGER=redis and several instances or workers, an instance only subscribed to Redis once a browser tab had connected to it. Until then, when a tool or Function asked the user something (a confirmation or an input dialog) and the user's tab was connected to another instance, the user's reply never reached the tool and it waited until it timed out. Every instance now subscribes at startup, so the reply arrives whichever instance the tab is on.
With ENABLE_ORJSON off (the default), non-English letters were saved to the database as escape codes, so "Ü" was stored as \u00dc. Searches that ignore upper and lower case compare against that saved text, so they missed any match that differs only in the case of a non-English letter: filtering models by the tag "Überblick" found nothing on Postgres, and searching automations for "отчёт" missed a prompt containing "Отчёт" on SQLite and Postgres. The 100,000 character size limit for user and chat variables counted the escape codes too, so Cyrillic or Chinese variables were refused as too large (or chat variables silently came out empty in the system prompt) at about a sixth of that size. Non-English text is now saved as written, which is how it is already saved with ENABLE_ORJSON on, so nothing changes for those instances, and the limit counts real characters. Anything saved before this keeps the escape codes until it is next edited.
Renaming a folder in the sidebar and pressing Enter sent the rename to the server twice and showed "Folder updated successfully" twice, because Enter saved the name and closing the text field saved it again. Enter now just closes the text field, which saves the new name once and shows one confirmation.
Fixes#31582
With request auditing turned on, the audit log only masked fields named exactly "password". The new password from a password change, and passwords entered in admin settings such as YaCy or Jupyter, were written to the log as-is. Any field whose name ends in "password", in any letter case, is now replaced with asterisks.
When an image generation backend returns a link instead of the image itself, the download now goes through the same safety checks used for other external image downloads. Links on the configured ComfyUI address are still trusted as before, so a ComfyUI server on a local network keeps working.
When signing in through an OAuth/OIDC provider failed, for example because the provider denied access, the account had no email or its email domain was not allowed, the login page told the user their email or password was wrong, even though they never typed one. Every such failure now shows "Sign-in with your identity provider failed. Please contact your administrator for assistance." The text is the same for every cause so it does not reveal which check failed, and the exact reason is still written to the server log as a warning.
Fixes#31627
The link in "chat finished" and "chat failed" webhook notifications was missing the `/c/` part of the chat address, so clicking it opened a 404 page. The link is sent as `/c/<chat id>` again and opens the chat.
Fixes#31565
In a temporary chat, when the model handed a task to a sub-agent, the sub-agent's conversation with the task and its answer was saved on the server, although a temporary chat should leave nothing behind. The model is no longer offered sub-agents in temporary chats.
Fixes#31567
The person who started a direct message could add or remove people through the API, although the app only offers this in group channels. Someone added this way could read the whole earlier conversation, and because the original pair no longer matched the conversation, their next message opened a second, empty direct message. Changing the members of a direct message now answers with a 403.
Fixes#31570
When a sub-agent running in the background finished, or a timer the model set went off, the result and the model's follow-up reply were saved but did not show in the chat the user had open. They only appeared after a manual page reload. They now show in the open chat as soon as they arrive.
Fixes#31566
* fix: automation still shows "Last run Never" after "Run now"
Running an automation with "Run now" added the run to its history, but the automation page and the Automations list kept showing "Last run Never" (or the time of the last scheduled run). Only scheduled runs recorded a last run time. A manual run now records it too, so the automation page and the Automations list show the time of the run you just started.
Fixes#31580
* fix: show the new last run time right after Run now
The automation page now takes the automation the server returns after Run now, so the last run time updates on the spot and no reload is needed.
