The wire · review · first seen Nov 9, 10:32 UTC

Open WebUI fixes plain-HTTP chats and editing

Open WebUI v0.13.2 shipped fixes for chats, comments, and Markdown editing over plain HTTP, plus a separate Side Chat permission switch. Builders using LAN or Docker addresses should care because the release addresses a UUID error that blocked those workflows (782, 783, 784, 785).

L0 · primary1 source4 claims checked4 min read

What shipped

The immediate change is in chat loading. In v0.13.2, opening Open WebUI over plain HTTP at a LAN or Docker address loads both new and existing chats. The release notes describe the previous failure as a spinner with the error “crypto.randomUUID is not a function”. This is a shipped fix, not a scheduled change or a proposed workaround. The claim is about the stated plain-HTTP access path; it does not establish behavior for every other way of reaching the application. [1]

The same release fixes the UUID error across two editing paths over plain HTTP. Creating a comment, replying to one, and editing one are covered. Editing a Markdown file containing rendered blocks is also covered; the release excerpt names Mermaid diagrams and callouts as examples. These are separate operations worth checking separately if your workflow moves between chat, discussion, and document editing. The notes say these operations no longer fail with the same UUID error. They do not claim that every editing failure has been removed. [1][2]

There is also a permission-interface change. The Allow Side Chat switch is visible when Temporary Chat is off, so administrators can configure the two permissions independently. That is a distinct shipped change, not a stated consequence of the UUID fixes. Visibility of the switch is the precise claim: the supplied material does not describe new defaults, a migration of existing settings, or a change to what either permission allows. Check the control on its own terms rather than treating it as evidence that a chat-loading fix changed your permissions. [1][2]

Why it matters if you build

For a builder accessing Open WebUI through a plain-HTTP LAN or Docker address, the practical question is whether a session can get past loading and into a chat. A spinner on new or existing chats stops that workflow before a reply can be used. In v0.13.2, the stated path loads those chats instead of stopping at the UUID error. That is a targeted reason to evaluate the release today if this exact failure is interrupting work. It is not evidence that unrelated loading problems, or access through other kinds of address, are fixed. [1]

The editing fixes address another interruption in the same plain-HTTP setting. A builder can create, reply to, and edit comments, then edit a Markdown file containing a rendered block without the identified UUID failure. A useful check should include the operations you perform rather than just opening the editor. In particular, a file with a Mermaid diagram or callout exercises the kind of rendered block named in the release excerpt. The material provides no timing measurements, reliability rate, or estimate of effort saved. It supports the narrower conclusion that the specified UUID failures are fixed in v0.13.2. [1][2]

For administrators, the decision is different. If Temporary Chat is off, the Allow Side Chat switch remains visible and can be configured independently. That removes the stated visibility coupling between the two controls. An administrator can inspect the intended Side Chat setting without turning Temporary Chat on to expose its switch. The claim does not say existing policies changed automatically, so seeing the switch calls for a configuration check rather than an assumption about a new policy. This item may matter even if the team has not encountered the plain-HTTP UUID error. [1][2][3][4]

How to try it today

1. Open v0.13.2 over plain HTTP at a LAN or Docker address. Open a new chat and an existing chat; check for the spinner or UUID error (782).
2. At that address, create a comment, reply to a comment, and edit a comment. Check for the UUID error (783).
3. Over plain HTTP, edit a Markdown file containing a rendered block such as a Mermaid diagram or callout. Check for the UUID error (784).
4. With Temporary Chat off, find the Allow Side Chat switch and configure it independently (785).

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Open WebUI v0.13.2 loads new and existing chats over plain HTTP at LAN or Docker addresses instead of remaining on a spinner with a UUID error.

   per GitHub releases · open-webui/open-webui (L0)
2. shipped L0 · primary

   Open WebUI v0.13.2 fixes the UUID error when creating, replying to, or editing comments over plain HTTP.

   per GitHub releases · open-webui/open-webui (L0)
3. shipped L0 · primary

   Open WebUI v0.13.2 fixes the UUID error when editing Markdown files with rendered blocks over plain HTTP.

   per GitHub releases · open-webui/open-webui (L0)
4. shipped L0 · primary

   Open WebUI v0.13.2 shows the Allow Side Chat switch when Temporary Chat is off.

   per GitHub releases · open-webui/open-webui (L0)

What is not confirmed

The supplied release excerpt does not establish a fix for other address types or for chat and editing errors other than those named here. It gives no performance measurements or assurance about every kind of rendered block. It also does not specify Side Chat or Temporary Chat defaults, migration of existing settings, or a broader permission change. Those questions need separate evidence before they become deployment claims. [1][2][3][4]

Who should act, who should wait

Act now if you use plain HTTP at a LAN or Docker address and need new or existing chats, comments, or rendered-block Markdown editing without this UUID error in v0.13.2. Exercise each operation relevant to your workflow before relying on it. Administrators who keep Temporary Chat off should inspect the now-visible Allow Side Chat switch and configure it deliberately. Wait for further evidence if your decision depends on other access paths, different errors, measured gains, or undocumented permission defaults. None of those outcomes is established by these claims. [1][2][3][4]

Sources

• v0.13.2 — GitHub releases · open-webui/open-webui L0 · primary