[GH-ISSUE #23362] Bug: Notes added to folders are not treated as context #58627

New Issue

GiteaMirror · 2026-05-05T23:35:30-05:00

GiteaMirror commented

2026-05-05 23:35:30 -05:00

Originally created by @sugoidesune on GitHub (Apr 3, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23362

EDIT: See below for bug description.

Problem Description

On a general level I would like the LLM in a Folder (a specific Project) to have a shared default context (like Knowledge) and be able to edit that shared context.

Use cases are:

self improving prompts
Planning and Tracking
default 'memory' yet adaptable
alternative to chat compression

Desired Solution you'd like

Being able to add Notes to a Folder would by default give all chats in that Folder these notes as context and as it is already allow the LLM to edit it.

The benefit of using Notes is that they are already made to be easy to inspect and edit by humans and LLMs.
Adding them to Folders would allow them to function as Folder based interactive "Knowledge and Deliverables"

Alternatives Considered

Knowledge unfortunately is not editable by LLM's
Memory is not provided by default, it must be requested, memory also costs an additional tool call.
Letting the LLM search for the notes - again can cost multiple API calls (Also philosophy wise - we are telling an LLM to tell our PC to attach documents, that we knew we needed to attach right from the start, and we pay the LLM for it which can get expensive with Claude Opus)
Adding notes manually for every chat - where's the fun in that

Additional Context

No response

Originally created by @sugoidesune on GitHub (Apr 3, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23362 > ### [EDIT: See below for bug description.](#issuecomment-4184922327) ### Problem Description On a general level I would like the LLM in a Folder (a specific Project) to have a shared default context (like Knowledge) and be able to edit that shared context. Use cases are: - self improving prompts - Planning and Tracking - default 'memory' yet adaptable - alternative to chat compression ### Desired Solution you'd like Being able to add Notes to a Folder would by default give all chats in that Folder these notes as context and as it is already allow the LLM to edit it. The benefit of using Notes is that they are already made to be easy to inspect and edit by humans and LLMs. Adding them to Folders would allow them to function as Folder based interactive "Knowledge and Deliverables" ### Alternatives Considered - Knowledge unfortunately is not editable by LLM's - Memory is not provided by default, it must be requested, memory also costs an additional tool call. - Letting the LLM search for the notes - again can cost multiple API calls (Also philosophy wise - we are telling an LLM to tell our PC to attach documents, that we knew we needed to attach right from the start, and we pay the LLM for it which can get expensive with Claude Opus) - Adding notes manually for every chat - where's the fun in that ### Additional Context _No response_

GiteaMirror added the bug label 2026-05-05 23:35:30 -05:00

GiteaMirror commented

2026-05-05 23:35:31 -05:00

@silentoplayz commented on GitHub (Apr 3, 2026):

Notes can already be added to a folder, no?

@silentoplayz commented on GitHub (Apr 3, 2026): Notes can already be added to a folder, no? <img width="693" height="566" alt="Image" src="https://github.com/user-attachments/assets/ba995a29-5fe8-47d5-8e0a-68851705cca2" /> <img width="832" height="512" alt="Image" src="https://github.com/user-attachments/assets/48434164-47d0-4fc5-9f58-c1b7b5d57855" />

GiteaMirror commented

2026-05-05 23:35:32 -05:00

@sugoidesune commented on GitHub (Apr 3, 2026):

❌ Then it might be a bug, because currently it does nothing for me.
I do have a note added, even as entire document which promises to attach the entire document to context...

❌ but it is not actually added as context, it's just 'available' via tool use and so in this case it searches memories and doesn't even check the notes :

❌ You can of course system prompt it to force looking up notes always but that wastes a lot of API calls as I explained in the opening post:

❌❌ What's worse is that in a follow up message the note will no longer be part of the context, forcing us to make tool calls for each message. Doubling input token costs.

✅ The behavior is much more as expected when adding a note directly to the chat.

It answered correctly
it didn't need to waste time and 5 tool calls to search and get to the information that it was supposed to have from the start.

❌ Although I don't understand what and why it's running queries on a file I am providing as context 1:1

@sugoidesune commented on GitHub (Apr 3, 2026): ❌ Then it might be a bug, because currently it does nothing for me. I do have a note added, even as `entire document` which promises to attach the entire document to context... <img width="550" height="132" alt="Image" src="https://github.com/user-attachments/assets/9ec5a8fa-f50a-4ee7-95ed-1b9251ac83f7" /> <hr/> ❌ but it is not actually added as context, it's just 'available' via tool use and so in this case it searches memories and doesn't even check the notes : <img width="500" height="198" alt="Image" src="https://github.com/user-attachments/assets/e85324e9-676d-4ecf-932c-3129fa68e6ff" /> <hr/> ❌ You can of course system prompt it to force looking up notes always but that wastes a lot of API calls as I explained in the opening post: <img width="450" height="200" style="margin-left: 50px" alt="Image" src="https://github.com/user-attachments/assets/33edfb7e-49fb-49a2-854d-f43b2cb578b2" /> <hr/> ❌❌ What's worse is that in a follow up message the note will no longer be part of the context, forcing us to make tool calls for each message. Doubling input token costs. <hr/> ✅ The behavior is much more as expected when adding a note directly to the chat. - It answered correctly - it didn't need to waste time and 5 tool calls to search and get to the information that it was supposed to have from the start. <img width="541" height="268" alt="Image" src="https://github.com/user-attachments/assets/82b7a1f2-8ce4-418f-bf4b-67e7343a2498" /> <hr/> ❌ Although I don't understand what and why it's running queries on a file I am providing as context 1:1 <img width="550" height="324" alt="Image" src="https://github.com/user-attachments/assets/e911502d-7192-4cf1-9985-ba91ebeb0d14" />

GiteaMirror commented

2026-05-05 23:35:33 -05:00

@frost19k commented on GitHub (Apr 4, 2026):

The trouble is that if you have a model in native tool mode and you attach a something as context for a folder then it might so happen that OWUI injects context and then the model decides to do a search anyway leading to context bloat.

However, if there's a model in native mode for whom you've disabled knowledgebase then (if you don't inject the folder context) it might as well be that the folder has no context. Model doesn't have the native tool nor does OWUI inject the context.

@frost19k commented on GitHub (Apr 4, 2026): The trouble is that if you have a model in native tool mode and you attach a something as context for a folder then it might so happen that OWUI injects context and then the model decides to do a search anyway leading to context bloat. However, if there's a model in native mode for whom you've disabled knowledgebase then (if you don't inject the folder context) it might as well be that the folder has no context. Model doesn't have the native tool nor does OWUI inject the context.

GiteaMirror commented

2026-05-05 23:35:33 -05:00

@sugoidesune commented on GitHub (Apr 4, 2026):

The case you described can already happen when attaching notes directly to the chat. The content is always added as context yet the LLM doesn't really know where that context is from and so might search and read the note again - #23392 addresses this.

#23392 in my case, helped the llm to avoid opening the already added note - only when for editing the note does it view_note again 'to be sure' as it says - which can be mitigated with a single sentence prompt.
It might of course search for other context, memories, knowledge, other notes but I that would be desired behavior.

Nevertheless we have almost all types of context but we lack folder wide + dynamic persistent context.

Context Types	Static Persistent	Dynamic Persistent	Ephemeral
📁 Folder Wide	System Prompt	❌ None	Knowledge, Notes, Tools
💬 Chat Wide	Chat Messages Attached File	Attached Note (latest version is added to each message)	Knowledge, Notes, Tools
👤 User Wide	Model System Prompt	None (few use cases)	Memory ( should be Folder wide)

Static - can't be changed by the LLM
Dynamic - can be changed by the LLM
Persistent - added as context to each message
Ephemeral - context is only added to individual messages

@sugoidesune commented on GitHub (Apr 4, 2026): The case you described can already happen when attaching notes directly to the chat. The content is always added as context yet the LLM doesn't really know where that context is from and so might search and read the note again - #23392 addresses this. #23392 in my case, helped the llm to avoid opening the already added note - only when for editing the note does it `view_note` again 'to be sure' as it says - which can be mitigated with a single sentence prompt. It might of course search for other context, memories, knowledge, other notes but I that would be desired behavior. <hr/> Nevertheless we have almost all types of context but we lack `folder wide` + ` dynamic persistent` context. | Context Types | Static Persistent | Dynamic Persistent | Ephemeral | |--------------------------|-------------------|-------------|---------| | 📁 Folder Wide | System Prompt | ❌ None | Knowledge, Notes, Tools | | 💬 Chat Wide  | Chat Messages Attached File | Attached Note (latest version is added to each message) | Knowledge, Notes, Tools   | | 👤 User Wide | Model System Prompt | None (few use cases) | Memory ( should be Folder wide) `Static` - can't be changed by the LLM `Dynamic` - can be changed by the LLM `Persistent` - added as context to each message `Ephemeral` - context is only added to individual messages

GiteaMirror commented

2026-05-05 23:35:34 -05:00

@jgill83 commented on GitHub (Apr 9, 2026):

Verifying this behavior in OWUI latest (0.8.12)

I’m seeing the same issue with Notes-based RAG/context not behaving as expected in folders.

In my setup, the folder clearly has Notes attached under Knowledge, but when I ask a chat in that folder something that should be answered from those notes, OWUI shows search_notes being explored and then returns no usable results. The assistant then says it has no stored notes or prior context, even though the folder contains relevant notes.

From the screenshots:

The folder “Palo Alto” has multiple Notes attached under Knowledge.
A chat inside that folder is explicitly trying to use folder context / notes for “PA-450” related questions.
The tool trace shows search_notes being called, but the result is empty [].
The assistant response falls back to saying it has no stored notes or prior context.

This makes it look like Notes added to a folder are not being surfaced as usable context for chats inside that folder, or that search_notes is not returning attached note content correctly.

Using Anthropic Sonnet 4.6 with Native tooling calls enabled and Builtin Tools with Notes enabled. Adding the notes directly to the model as knowledge also do not result in RAG context working correctly.

@jgill83 commented on GitHub (Apr 9, 2026): Verifying this behavior in OWUI latest (0.8.12) I’m seeing the same issue with Notes-based RAG/context not behaving as expected in folders. In my setup, the folder clearly has Notes attached under Knowledge, but when I ask a chat in that folder something that should be answered from those notes, OWUI shows search_notes being explored and then returns no usable results. The assistant then says it has no stored notes or prior context, even though the folder contains relevant notes. From the screenshots: The folder “Palo Alto” has multiple Notes attached under Knowledge. A chat inside that folder is explicitly trying to use folder context / notes for “PA-450” related questions. The tool trace shows search_notes being called, but the result is empty []. The assistant response falls back to saying it has no stored notes or prior context. This makes it look like Notes added to a folder are not being surfaced as usable context for chats inside that folder, or that search_notes is not returning attached note content correctly. <img width="1467" height="446" alt="Image" src="https://github.com/user-attachments/assets/a3c6fd8a-d960-4659-82b2-de269ae29c15" /> <img width="771" height="521" alt="Image" src="https://github.com/user-attachments/assets/b5e7b4e5-c7d2-495f-8a1b-01e5f94541ee" /> <img width="1449" height="603" alt="Image" src="https://github.com/user-attachments/assets/46230fa8-f699-40dd-a8ad-69cf1f48283c" /> Using Anthropic Sonnet 4.6 with Native tooling calls enabled and Builtin Tools with Notes enabled. Adding the notes directly to the model as knowledge also do not result in RAG context working correctly.

GiteaMirror commented

2026-05-05 23:35:34 -05:00

@jlgill commented on GitHub (Apr 10, 2026):

Update: Issue identified for search_notes returning empty on multi-word queries

After digging into this further, it looks like the behavior I reported (folder-attached notes not being found) may be related to two separate issues:

1. search_notes SQL bug:
The search_notes() method in models/notes.py concatenates the entire multi-word query into one string after stripping all hyphens and spaces, then performs a single ILIKE substring match. Any query containing spaces or hyphens (e.g., "term-one term-two term-three" becomes "termonetermtwotermthree") always returns [] because that concatenated string never appears contiguously in any note content. I've opened a separate issue for this with a fix ready: #23565

2. Native FC folder knowledge design:
When a model uses native function calling, notes attached to a folder are not auto-injected into the prompt. Instead, they're made available via builtin tools (list_knowledge, query_knowledge_files, view_note). The LLM must call those tools to access them. In my case, the LLM chose search_notes instead -- which hit the bug above -- making it appear as though folder notes weren't working at all.

Disclosure: I did use AI tooling (GitHub Copilot) to assist with code analysis and drafting the fix. Changes were validated by manual human review, direct PostgreSQL queries, and confirming the SQL behavior before and after the fix, and end-to-end testing inside the running container to verify that multi-word queries now return the expected notes via the search_notes native function call.

@jlgill commented on GitHub (Apr 10, 2026): **Update: Issue identified for `search_notes` returning empty on multi-word queries** After digging into this further, it looks like the behavior I reported (folder-attached notes not being found) may be related to **two separate issues**: **1. `search_notes` SQL bug:** The `search_notes()` method in `models/notes.py` concatenates the entire multi-word query into one string after stripping all hyphens and spaces, then performs a single `ILIKE` substring match. Any query containing spaces or hyphens (e.g., `"term-one term-two term-three"` becomes `"termonetermtwotermthree"`) always returns `[]` because that concatenated string never appears contiguously in any note content. I've opened a separate issue for this with a fix ready: #23565 **2. Native FC folder knowledge design:** When a model uses native function calling, notes attached to a folder are **not** auto-injected into the prompt. Instead, they're made available via builtin tools (`list_knowledge`, `query_knowledge_files`, `view_note`). The LLM must call those tools to access them. In my case, the LLM chose `search_notes` instead -- which hit the bug above -- making it appear as though folder notes weren't working at all. **Disclosure:** I did use AI tooling (GitHub Copilot) to assist with code analysis and drafting the fix. Changes were validated by manual human review, direct PostgreSQL queries, and confirming the SQL behavior before and after the fix, and end-to-end testing inside the running container to verify that multi-word queries now return the expected notes via the `search_notes` native function call.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58627