[GH-ISSUE #24714] issue: Filter outlet-modified assistant content is persisted in chat_message.content but lost from chat.chat history after reload #123696

New Issue

2026-05-21T03:08:53-05:00

GiteaMirror commented

2026-05-21 03:08:53 -05:00

Originally created by @etiennegnome on GitHub (May 14, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24714

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.9.5

Ollama Version (if applicable)

v0.23.1

Operating System

LinuxMint 21.3

Browser (if applicable)

Firefox 150.0.1

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When a Filter Function modifies the final assistant message in outlet(), the final modified assistant content should be persisted consistently across all internal representations used by Open WebUI.

In particular, after outlet() modifies:

body["messages"][-1]["content"]

the final assistant content should be synchronized to:

chat_message.content
chat.chat.history.messages[assistant_id].content
chat.chat.messages[].content

or Open WebUI should use a single canonical message source when reloading a chat.

After navigating away from the chat and coming back, the UI should display the same final assistant content that was visible immediately after generation.

Actual Behavior

The modified content appears immediately after generation, which confirms that the Filter Function outlet is executed.

However, after leaving the chat and reopening it:

the footer disappears from the displayed assistant response;
the copied text no longer contains the full footer;
chat_message.content still contains the outlet-modified content;
chat.chat.history.messages[assistant_id].content does not contain the same final content;
chat.chat.messages[].content also appears not to contain the same final content.

This suggests that Open WebUI persists or reloads different versions of the assistant message depending on the internal data structure being used.

Description

I am experiencing a synchronization/persistence issue with Open WebUI Filter Functions that modify the final assistant response in outlet().

The filter appends an AI transparency footer to the final assistant message after generation. The footer appears correctly in the current chat after a short delay, which suggests that the outlet() post-processing is being executed correctly.

However, when I switch to another chat, create a new chat, or reload/open the same conversation again, the footer disappears from the displayed assistant message.

After inspecting the SQLite database, I found that the outlet-modified content is correctly persisted in:

chat_message.content

but is not consistently reflected in:

chat.chat.history.messages[assistant_id].content
chat.chat.messages[].content

As a result, the UI appears to reload the conversation from a stale or non-synchronized representation of the assistant message, instead of using the final outlet-modified content stored in chat_message.content.

This makes Filter Functions that append, transform, watermark, label, redact, or otherwise modify final assistant outputs unreliable after chat reload/navigation.

Why this matters

According to the Open WebUI documentation, Filter Functions can modify model outputs through outlet(). This is useful for post-processing assistant responses, including:

appending compliance labels;
adding transparency notices;
adding machine-readable markers;
redacting or transforming outputs;
logging or adapting final assistant content.

In my case, the filter appends an AI transparency footer for compliance-oriented workflows.

The footer is not cosmetic only. It must remain part of the final assistant message when the conversation is reopened, exported, copied, or reviewed later.

Currently, the modified content is visible immediately after generation, but is lost from the UI after navigating away and returning to the chat.

Installation Method

Pinokio installation and Docker installation : Same effects.

From the user perspective, this behaves like a native Linux installation, not a Docker deployment.

Open WebUI Version

0.9.5

Operating System

Linux Mint 21.3

Database

Default SQLite database.

I did not manually change the Open WebUI database backend.

Browser

The issue is not browser-cache related.

I tested:

normal browser window;
private/incognito window;
hard refresh;
switching to another chat and coming back;
creating a new chat and coming back.

The footer still disappears from the displayed chat after reload/navigation.

Function Type

Filter Function.

The filter is:

active: true
global: true
target_models: "*"
toggleable: false

The filter uses outlet() to append content to the last assistant message.

Minimal Reproduction Filter

A simplified version of the behavior is:

from pydantic import BaseModel, Field
from typing import Optional
import datetime


class Filter:
    class Valves(BaseModel):
        enable_label: bool = Field(default=True)
        label_text: str = Field(
            default="AI-generated content - transparency marker."
        )

    def __init__(self):
        self.valves = self.Valves()
        self.marker = "[AI_TRANSPARENCY_MARKER_TEST]"

    def outlet(self, body: dict, __user__: Optional[dict] = None) -> dict:
        messages = body.get("messages", [])
        if not messages:
            return body

        last_message = messages[-1]
        if last_message.get("role") != "assistant":
            return body

        content = last_message.get("content", "")

        if self.marker in content:
            return body

        now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        footer = (
            f"\n\n---\n"
            f"*AI-generated content - transparency marker.*\n"
            f"*Generated at: {now}*\n\n"
            f"{self.marker}"
        )

        last_message["content"] = f"{content}{footer}"

        return body

SQLite Inspection Results

The database contains the following relevant tables:

chat
chat_message
message
function
model
config

The relevant columns are:

chat.chat
chat_message.content
chat_message.output
chat_message.model_id
chat_message.sources
chat_message.status_history

In recent test chats:

chat_message.content: contains the outlet-added footer and marker
chat.chat.history.messages[assistant_id].content: does not contain the footer
chat.chat.messages[].content: does not contain the footer

Example observation:

MARKER in chat_message.content: true
MARKER in chat.chat: false

In another older conversation, some messages still had the marker in both places, suggesting that the behavior may have changed after recent updates or internal schema/message-handling changes.

Impact

This issue makes output-modifying Filter Functions unreliable for any workflow that requires the final assistant message to remain stable after generation.

It affects use cases such as:

transparency notices;
compliance labels;
AI-generated content markers;
post-generation redaction;
output normalization;
machine-readable markers;
audit-oriented transformations;
export workflows relying on the final assistant content.

For compliance-oriented deployments, this is a serious issue because a message shown to the user immediately after generation is not the same message shown after reopening the chat.

Technical Hypothesis

It looks like Open WebUI may now persist the outlet-modified assistant message into chat_message.content, but does not update the denormalized or legacy chat JSON structures stored in chat.chat.

When the chat is reopened, the frontend or backend may still rely on:

chat.chat.history.messages[assistant_id].content
chat.chat.messages[].content

instead of the canonical content stored in:

chat_message.content

This creates a mismatch between the message shown immediately after generation and the message shown after chat reload/navigation.

Suggested Fix

The best fix would be to define one canonical source of truth for final assistant message content after all filters have run.

Possible approaches:

After all Filter Function outlet() calls are completed, synchronize the final assistant message content to all relevant storage representations:

chat_message.content
chat.chat.history.messages[assistant_id].content
chat.chat.messages[].content

Or, preferably, make chat_message.content the canonical source of truth and ensure the UI reload path uses it consistently.
If chat.chat.history and chat.chat.messages are retained for backward compatibility or performance reasons, ensure they are updated after outlet post-processing.
Add a regression test verifying that content modified by a Filter Function outlet remains visible after:
- chat reload;
- switching chats;
- hard refresh;
- opening the same chat in a private window;
- exporting or copying the message.

Regression Test Proposal

A minimal automated test could be:

Register a test Filter Function that appends:

[OUTLET_PERSISTENCE_TEST]

to the assistant response in outlet().

Create a chat and generate one assistant response.
Assert that the marker is present immediately after generation.
Reload the chat through the same API path used by the frontend.
Assert that the marker is still present.
Inspect persisted data and assert that the final content is consistent between:
- chat_message.content;
- chat.chat.history.messages[assistant_id].content;
- chat.chat.messages[].content, if still used.

Workaround Tried

I also tested a custom function intended to synchronize outlet-modified content back into chat history.

This created two major issues:

the footer still disappeared after switching chats and returning;
reopening a marked chat caused the conversation loading to spin indefinitely.

I had to disable that function and delete the affected test chat from the Open WebUI interface to return to normal behavior.

This suggests that external Functions should probably not be responsible for manually repairing internal message synchronization. The synchronization should happen inside Open WebUI after all filters have completed.

Final Note

This issue is not only about one AI transparency footer.

It seems to be a more general persistence/synchronization issue affecting any Filter Function that modifies final assistant output in outlet().

The displayed message after generation and the displayed message after reopening the chat should be identical.



### Steps to Reproduce

1. Install or use Open WebUI 0.9.5.
2. Use the default SQLite database.
3. Add a global active Filter Function using `outlet()` to append a footer to assistant messages.
4. Create a new chat.
5. Send a simple prompt, for example:

```text
Reply simply: AI marking test.
```

6. Wait for the assistant response to complete.
7. Observe that the footer appears after a short delay, typically 1–2 seconds after the assistant response.
8. Copy the message immediately to a text editor.
9. Confirm that the footer is present in the copied text.
10. Switch to another chat, or create a new chat.
11. Return to the original chat.
12. Observe that the footer is no longer visible in the displayed assistant response.
13. Copy the same message again to a text editor.
14. Confirm that the full footer is no longer present in the copied text.
15. Inspect the SQLite database.
16. Confirm that `chat_message.content` contains the footer.
17. Confirm that `chat.chat.history.messages[assistant_id].content` and/or `chat.chat.messages[].content` do not contain the same final outlet-modified content.


### Logs & Screenshots

I can provide:

* SQLite inspection outputs;
* test chat IDs;
* example rows from `chat_message`;
* example `chat.chat` JSON excerpts;
* the full Filter Function used for reproduction;
* screenshots or screen recording if useful.


### Additional Information

There is also a global UI watermark configured in:

```text
config.data.ui.watermark
```

Example value:

```text
Content generated by AI - AI Act transparency notice
```

This watermark is copied with messages even when the custom outlet footer disappears.

However, this appears to be a different UI-level watermark mechanism and does not solve the issue with Filter Function outlet-modified assistant content not being synchronized across stored chat representations.

Originally created by @etiennegnome on GitHub (May 14, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24714 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.9.5 ### Ollama Version (if applicable) v0.23.1 ### Operating System LinuxMint 21.3 ### Browser (if applicable) Firefox 150.0.1 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When a Filter Function modifies the final assistant message in `outlet()`, the final modified assistant content should be persisted consistently across all internal representations used by Open WebUI. In particular, after `outlet()` modifies: ```python body["messages"][-1]["content"] ``` the final assistant content should be synchronized to: ```text chat_message.content chat.chat.history.messages[assistant_id].content chat.chat.messages[].content ``` or Open WebUI should use a single canonical message source when reloading a chat. After navigating away from the chat and coming back, the UI should display the same final assistant content that was visible immediately after generation. ### Actual Behavior ### Actual Behavior The modified content appears immediately after generation, which confirms that the Filter Function outlet is executed. However, after leaving the chat and reopening it: * the footer disappears from the displayed assistant response; * the copied text no longer contains the full footer; * `chat_message.content` still contains the outlet-modified content; * `chat.chat.history.messages[assistant_id].content` does not contain the same final content; * `chat.chat.messages[].content` also appears not to contain the same final content. This suggests that Open WebUI persists or reloads different versions of the assistant message depending on the internal data structure being used. --- ### Description I am experiencing a synchronization/persistence issue with Open WebUI Filter Functions that modify the final assistant response in `outlet()`. The filter appends an AI transparency footer to the final assistant message after generation. The footer appears correctly in the current chat after a short delay, which suggests that the `outlet()` post-processing is being executed correctly. However, when I switch to another chat, create a new chat, or reload/open the same conversation again, the footer disappears from the displayed assistant message. After inspecting the SQLite database, I found that the outlet-modified content is correctly persisted in: ```text chat_message.content ```` but is not consistently reflected in: ```text chat.chat.history.messages[assistant_id].content chat.chat.messages[].content ``` As a result, the UI appears to reload the conversation from a stale or non-synchronized representation of the assistant message, instead of using the final outlet-modified content stored in `chat_message.content`. This makes Filter Functions that append, transform, watermark, label, redact, or otherwise modify final assistant outputs unreliable after chat reload/navigation. --- ### Why this matters According to the Open WebUI documentation, Filter Functions can modify model outputs through `outlet()`. This is useful for post-processing assistant responses, including: * appending compliance labels; * adding transparency notices; * adding machine-readable markers; * redacting or transforming outputs; * logging or adapting final assistant content. In my case, the filter appends an AI transparency footer for compliance-oriented workflows. The footer is not cosmetic only. It must remain part of the final assistant message when the conversation is reopened, exported, copied, or reviewed later. Currently, the modified content is visible immediately after generation, but is lost from the UI after navigating away and returning to the chat. --- ### Installation Method Pinokio installation and Docker installation : Same effects. From the user perspective, this behaves like a native Linux installation, not a Docker deployment. --- ### Open WebUI Version ```text 0.9.5 ``` --- ### Operating System ```text Linux Mint 21.3 ``` --- ### Database Default SQLite database. I did not manually change the Open WebUI database backend. --- ### Browser The issue is not browser-cache related. I tested: * normal browser window; * private/incognito window; * hard refresh; * switching to another chat and coming back; * creating a new chat and coming back. The footer still disappears from the displayed chat after reload/navigation. --- ### Function Type Filter Function. The filter is: ```text active: true global: true target_models: "*" toggleable: false ``` The filter uses `outlet()` to append content to the last assistant message. --- ### Minimal Reproduction Filter A simplified version of the behavior is: ```python from pydantic import BaseModel, Field from typing import Optional import datetime class Filter: class Valves(BaseModel): enable_label: bool = Field(default=True) label_text: str = Field( default="AI-generated content - transparency marker." ) def __init__(self): self.valves = self.Valves() self.marker = "[AI_TRANSPARENCY_MARKER_TEST]" def outlet(self, body: dict, __user__: Optional[dict] = None) -> dict: messages = body.get("messages", []) if not messages: return body last_message = messages[-1] if last_message.get("role") != "assistant": return body content = last_message.get("content", "") if self.marker in content: return body now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") footer = ( f"\n\n---\n" f"*AI-generated content - transparency marker.*\n" f"*Generated at: {now}*\n\n" f"{self.marker}" ) last_message["content"] = f"{content}{footer}" return body ``` --- ### SQLite Inspection Results The database contains the following relevant tables: ```text chat chat_message message function model config ``` The relevant columns are: ```text chat.chat chat_message.content chat_message.output chat_message.model_id chat_message.sources chat_message.status_history ``` In recent test chats: ```text chat_message.content: contains the outlet-added footer and marker chat.chat.history.messages[assistant_id].content: does not contain the footer chat.chat.messages[].content: does not contain the footer ``` Example observation: ```text MARKER in chat_message.content: true MARKER in chat.chat: false ``` In another older conversation, some messages still had the marker in both places, suggesting that the behavior may have changed after recent updates or internal schema/message-handling changes. --- ### Impact This issue makes output-modifying Filter Functions unreliable for any workflow that requires the final assistant message to remain stable after generation. It affects use cases such as: * transparency notices; * compliance labels; * AI-generated content markers; * post-generation redaction; * output normalization; * machine-readable markers; * audit-oriented transformations; * export workflows relying on the final assistant content. For compliance-oriented deployments, this is a serious issue because a message shown to the user immediately after generation is not the same message shown after reopening the chat. --- ### Technical Hypothesis It looks like Open WebUI may now persist the outlet-modified assistant message into `chat_message.content`, but does not update the denormalized or legacy chat JSON structures stored in `chat.chat`. When the chat is reopened, the frontend or backend may still rely on: ```text chat.chat.history.messages[assistant_id].content chat.chat.messages[].content ``` instead of the canonical content stored in: ```text chat_message.content ``` This creates a mismatch between the message shown immediately after generation and the message shown after chat reload/navigation. --- ### Suggested Fix The best fix would be to define one canonical source of truth for final assistant message content after all filters have run. Possible approaches: 1. After all Filter Function `outlet()` calls are completed, synchronize the final assistant message content to all relevant storage representations: ```text chat_message.content chat.chat.history.messages[assistant_id].content chat.chat.messages[].content ``` 2. Or, preferably, make `chat_message.content` the canonical source of truth and ensure the UI reload path uses it consistently. 3. If `chat.chat.history` and `chat.chat.messages` are retained for backward compatibility or performance reasons, ensure they are updated after outlet post-processing. 4. Add a regression test verifying that content modified by a Filter Function outlet remains visible after: * chat reload; * switching chats; * hard refresh; * opening the same chat in a private window; * exporting or copying the message. --- ### Regression Test Proposal A minimal automated test could be: 1. Register a test Filter Function that appends: ```text [OUTLET_PERSISTENCE_TEST] ``` to the assistant response in `outlet()`. 2. Create a chat and generate one assistant response. 3. Assert that the marker is present immediately after generation. 4. Reload the chat through the same API path used by the frontend. 5. Assert that the marker is still present. 6. Inspect persisted data and assert that the final content is consistent between: * `chat_message.content`; * `chat.chat.history.messages[assistant_id].content`; * `chat.chat.messages[].content`, if still used. --- ### Workaround Tried I also tested a custom function intended to synchronize outlet-modified content back into chat history. This created two major issues: 1. the footer still disappeared after switching chats and returning; 2. reopening a marked chat caused the conversation loading to spin indefinitely. I had to disable that function and delete the affected test chat from the Open WebUI interface to return to normal behavior. This suggests that external Functions should probably not be responsible for manually repairing internal message synchronization. The synchronization should happen inside Open WebUI after all filters have completed. --- ### Final Note This issue is not only about one AI transparency footer. It seems to be a more general persistence/synchronization issue affecting any Filter Function that modifies final assistant output in `outlet()`. The displayed message after generation and the displayed message after reopening the chat should be identical. ```` ### Steps to Reproduce 1. Install or use Open WebUI 0.9.5. 2. Use the default SQLite database. 3. Add a global active Filter Function using `outlet()` to append a footer to assistant messages. 4. Create a new chat. 5. Send a simple prompt, for example: ```text Reply simply: AI marking test. ``` 6. Wait for the assistant response to complete. 7. Observe that the footer appears after a short delay, typically 1–2 seconds after the assistant response. 8. Copy the message immediately to a text editor. 9. Confirm that the footer is present in the copied text. 10. Switch to another chat, or create a new chat. 11. Return to the original chat. 12. Observe that the footer is no longer visible in the displayed assistant response. 13. Copy the same message again to a text editor. 14. Confirm that the full footer is no longer present in the copied text. 15. Inspect the SQLite database. 16. Confirm that `chat_message.content` contains the footer. 17. Confirm that `chat.chat.history.messages[assistant_id].content` and/or `chat.chat.messages[].content` do not contain the same final outlet-modified content. ### Logs & Screenshots I can provide: * SQLite inspection outputs; * test chat IDs; * example rows from `chat_message`; * example `chat.chat` JSON excerpts; * the full Filter Function used for reproduction; * screenshots or screen recording if useful. ### Additional Information There is also a global UI watermark configured in: ```text config.data.ui.watermark ``` Example value: ```text Content generated by AI - AI Act transparency notice ``` This watermark is copied with messages even when the custom outlet footer disappears. However, this appears to be a different UI-level watermark mechanism and does not solve the issue with Filter Function outlet-modified assistant content not being synchronized across stored chat representations.

GiteaMirror added the bug label 2026-05-21 03:08:53 -05:00

GiteaMirror commented

2026-05-21 03:08:56 -05:00

@owui-terminator[bot] commented on GitHub (May 14, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #14785 issue: Filter Functions losting system prompts and advanced parameters
This is the closest prior issue about Filter Functions interfering with message-related state. Although it focuses on system prompts/parameters rather than assistant content persistence, it supports that filter processing can desynchronize or drop parts of the request/representation.
by vibe-Chen · bug
🟢 #24711 issue: Chat not accessible/loading in interface
Both issues involve chat reload/navigation problems in v0.9.5 where a conversation appears correct initially but is wrong or incomplete when reopened. It is not specifically about filter outlets, but it matches the same reload-path persistence class of bug.
by HenkieTenkie62 · bug
🟣 #24310 issue: Chat-specific model/system prompt/settings are not persisted after switching chats in v0.9.2
This earlier bug shows chat-specific state not persisting after switching chats and returning. It is related because the new issue also describes data that exists in one representation but is lost when the chat is reopened.
by Bennowan · bug
🟣 #24522 issue: When continuing a conversation in the new version using a chat created in an older version, the system fails to send the full context to the model
This issue reports stale/incorrect chat context when continuing older chats, which suggests problems in how Open WebUI reconstructs or reloads stored conversation state. It is adjacent to the same history-loading pipeline implicated here.
by CookSleep · bug
🟣 #24142 Issue #24142
This is another reload/chat-switch persistence bug where selected context disappears after page reload or chat switch. While about knowledge selection rather than message content, it is the same symptom pattern of state being lost on navigation.
by unknown

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (May 14, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#14785](https://github.com/open-webui/open-webui/issues/14785) **issue: Filter Functions losting system prompts and advanced parameters** *This is the closest prior issue about Filter Functions interfering with message-related state. Although it focuses on system prompts/parameters rather than assistant content persistence, it supports that filter processing can desynchronize or drop parts of the request/representation.* *by vibe-Chen · `bug`* 2. 🟢 [#24711](https://github.com/open-webui/open-webui/issues/24711) **issue: Chat not accessible/loading in interface** *Both issues involve chat reload/navigation problems in v0.9.5 where a conversation appears correct initially but is wrong or incomplete when reopened. It is not specifically about filter outlets, but it matches the same reload-path persistence class of bug.* *by HenkieTenkie62 · `bug`* 3. 🟣 [#24310](https://github.com/open-webui/open-webui/issues/24310) **issue: Chat-specific model/system prompt/settings are not persisted after switching chats in v0.9.2** *This earlier bug shows chat-specific state not persisting after switching chats and returning. It is related because the new issue also describes data that exists in one representation but is lost when the chat is reopened.* *by Bennowan · `bug`* 4. 🟣 [#24522](https://github.com/open-webui/open-webui/issues/24522) **issue: When continuing a conversation in the new version using a chat created in an older version, the system fails to send the full context to the model** *This issue reports stale/incorrect chat context when continuing older chats, which suggests problems in how Open WebUI reconstructs or reloads stored conversation state. It is adjacent to the same history-loading pipeline implicated here.* *by CookSleep · `bug`* 5. 🟣 [#24142](https://github.com/open-webui/open-webui/issues/24142) **Issue #24142** *This is another reload/chat-switch persistence bug where selected context disappears after page reload or chat switch. While about knowledge selection rather than message content, it is the same symptom pattern of state being lost on navigation.* *by unknown* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

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#123696