The view_file and view_knowledge_file built-in tools let a model ask for a start and end line, but passing only the end line did nothing: the tool returned the first block of characters and dropped the end line without a word. Models that asked for "up to line N" kept getting the same opening slice and no error, so they retried the call over and over. An end line on its own now reads from line 1 up to that line, the same result as passing start line 1 explicitly.
Fixes#33100
When a model reads a file or knowledge-base file in pages with line numbers turned on, the position it was told to continue from pointed past the end of the previous page, so a chunk of text between pages was silently skipped and never returned. The gap grew with every page, dropping a few percent of a large file. Reading now continues from the right place and returns every character exactly once; paging with line numbers off is unchanged.
Fixes#33099
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
Clicking the title of a citation from an external knowledge base (Qdrant, Milvus, pgvector), or its Content link, opened a link to a file inside Open WebUI that does not exist, so the browser showed a not found error. These results are no longer treated as uploaded files, so when the citation's source is a web address both links open that page, and otherwise the title is plain text. This works whether or not the model uses native tool calling.
Fixes https://github.com/open-webui/open-webui/issues/32231
With ENABLE_FORWARD_USER_INFO_HEADERS on and hybrid search enabled, rerank requests went out without the user headers when a chat searched attached knowledge, when a model used the built-in knowledge search tool, and when the collection query API was called with hybrid turned off for that one request. The embedding requests of the same search did carry them, so external rerankers that use these headers for per-user auth, rate limits or auditing saw anonymous calls. Rerank requests now carry the signed-in user, the same as embedding requests.
Fixes#32060
Custom metadata attached to a file upload now reaches the vector DB, but the model still never sees it. Both prompt-assembly paths build their output from a fixed field set: the classic RAG <source> tag carries only id, name and resource type, and the retrieval tools return only content, source and file id per chunk. A scraper that records where each document came from therefore cannot get that origin in front of the model, so answers cannot state it.
RAG_SOURCE_METADATA_KEYS names the chunk metadata keys allowed through to the model. Configured keys are emitted as extra attributes on the <source> tag and as extra fields on tool result chunks, covering both retrieval paths. It is empty by default, so nothing changes for existing deployments.
An allowlist instead of passing everything through, because chunk metadata also carries file hashes, collection names, embedding config and relevance scores, which would then be added to every retrieved chunk of every request. Values are attacker-controllable through an uploaded file, so they are escaped before they go into the tag, and a configured key can never displace a field the tag or the chunk already defines.
Reported in open-webui/open-webui#29486.
The ask_user card badges the first option of every question as "Recommended", but nothing ever told the model that. The model picks whatever order it likes, so the badge really means "listed first" and users act on a recommendation the model never made.
The ask_user tool description now states that the first option is labelled Recommended and that the model should list the option it recommends first, so the badge reflects an actual choice.
Kept the badge and instructed the model instead of adding a per-option "recommended" flag: the flag would need a schema change, validation in the request normalizer and a frontend change, for the same result in the common case. Dropping the badge was the other option, but it removes a useful affordance rather than fixing it.
Verified that the added line reaches the model by running the docstring through the tool-spec builder and checking the generated OpenAI function schema.
Fixes#30195
Asked to add a section or change a few lines, models answer with a whole-note
replace_note_content call and the rest of the note is gone, with nothing to
undo because the editor only records versions on chat inserts. The tool
already supports replace_range operations with an expected guard, but its
description never said when to use them or how the offsets work, so models
defaulted to sending the whole note back.
The docstring, which is the description every model receives for this tool
in note chats and normal chats alike, now states the preference for range
edits and the offset, overlap and expected rules the handler enforces.
Verified the text lands in the generated tool spec unchanged and that range
edits, the expected mismatch rejection and whole-note replace behave as
described against a sqlite data dir.
kb_exec silently ignored ls -t. It accepted the flag, dropped it and
returned the same undefined database order as a plain ls, so the model
believed it had a newest-first list when it did not. With a few thousand
files in a knowledge base there was no way to ask what changed recently
without reading the whole listing and comparing dates by eye.
ls, tree and find now sort their file lines by name by default, so the
same knowledge base always lists the same way. -t sorts newest first,
-S largest first and -r reverses, combinable like -at or -tr, matching
the flags the model already knows from a shell. Directories keep their
existing name order and stay grouped first. No query changes: the
timestamps and sizes were already loaded for the date and size columns.
The built-in chat and knowledge grep tools awaited their matching helper directly, so the search ran on the event loop and held it for as long as the match took. Both call sites now hand the helper to a worker thread.
Output and error handling are unchanged: 17 cases (literal, regex, case-insensitive, count-only, no-match, invalid pattern, rejected quantifiers, missing file data, result truncation) compare byte-for-byte against the previous behaviour. The matcher's time budget lives in a contextvar, which asyncio.to_thread copies into the worker, so budget scoping still behaves as before.
The regex detection helpers wrote their backslash escapes in ordinary string
literals, so Python reported six invalid escape sequences on import. They work
today because Python leaves an unrecognised escape as its two characters, but
that behaviour is deprecated and becomes a syntax error in a future release, at
which point the knowledge filesystem tools stop importing at all.
The literals are now raw, which is the same two characters with no warning.
Pattern detection and normalisation are unchanged: verified identical output
over every string up to length five drawn from the characters these helpers
look at.
* fix: preserve user info in agentic RAG tools
* fix: preserve user info in file access checks
---------
Co-authored-by: Damien SPINELLI <damien.spinelli@external.list.lu>
Timothy Jaeryang Baek
Classic298andGitHub
G30andGitHub
