agents · review · first seen Nov 9, 10:32 UTC

Open WebUI adds coding agents to automations

Open WebUI v0.13.3 shipped coding-agent selection for automations and terminal and folder changes within a chat. Builders can now test scheduled agent work and change a chat’s workspace without starting over.

L0 · primary1 source5 claims checked4 min read

What shipped

In v0.13.3, the automation editor lets you choose a terminal and working folder, then select a coding agent available in that terminal. This is a selection from agents available there, not a claim that every agent works in every terminal. Scheduled runs use the saved terminal and folder. That makes the editor’s terminal choice part of the automation’s execution context, rather than merely a way to browse files while configuring it. [1][2]

Before a scheduled agent automation starts, Open WebUI checks whether its saved terminal and agent are still available. The release notes do not describe this as a guarantee that the agent will complete its work. Agent automations send results to a chat. Channel destinations remain available for ordinary models, so do not assume an agent automation can be routed to a channel in the same way. [1][2]

A chat can now switch terminals or working folders after messages have been sent, including in temporary chats. The terminal and folder controls are disabled while a reply is being generated. The release notes also say that switching terminals updates open Files tabs to the new terminal’s files; with a terminal set to “Per chat,” the Files tab switches to that chat’s own files. Those details matter when checking which workspace is on screen after a switch. [1][2]

Why it matters if you build

For a builder maintaining work across several folders, this removes one rigid point in the chat workflow: sending a message no longer locks in the terminal or working folder for subsequent interaction. I would still check the selected terminal and folder before continuing, especially after a terminal switch. The release notes say the Files tabs follow that switch, but they do not establish how an earlier message should be interpreted after the workspace changes. [1][2]

For scheduled work, the practical unit to review is the saved combination of terminal, folder and available agent. Selecting an agent in the editor is not enough to establish that it will still be available when the schedule runs. The pre-start check addresses that specific availability question. It does not, on the evidence here, describe what happens after a check fails or what an agent can do once it starts. Treat those as questions to test before depending on an unattended run. [1][2]

The destination distinction can change an existing reporting habit. If you expect to inspect an agent automation in a chat, the stated result path fits. If your workflow expects a channel destination, the excerpt reserves that option for ordinary models. There is no stated performance gain, pricing effect, or resource requirement in these claims. The immediate operational work is checking the saved workspace and the chat that receives the result, rather than assuming an existing channel-oriented automation behaves the same way. [1][2][3]

How to try it today

1. In the automation editor, choose a terminal and working folder.
2. Select a coding agent shown as available in that terminal.
3. Save a scheduled agent automation, then check that its terminal and agent remain available before a run.
4. Inspect the chat for the agent automation’s result.
5. In a chat with messages, change the terminal or working folder; check the Files tab after a terminal change.
6. While a reply is being generated, observe that the terminal and folder controls are disabled.

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.3 lets users select a coding agent available in the chosen terminal for an automation.

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

   Scheduled agent automations check that the saved terminal and agent are still available before starting.

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

   Agent automations send their results to a chat.

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

   Users can change a chat’s terminal or working folder after sending messages.

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

   Terminal and folder controls are disabled while a reply is being generated.

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

What is not confirmed

The supplied release notes do not establish the behavior when a scheduled run finds its saved terminal or agent unavailable. They say a check happens before starting, not whether the run is retried, reported as failed, or surfaced to someone. They also do not establish execution permissions, isolation, or a measure of reliability for the agent’s work. Do not read those guarantees into an availability check. [1]

The excerpts do not establish that agent automation results can go to a channel; they say agent results go to a chat and that channel destinations remain available for ordinary models. Nor do they specify whether switching a chat’s terminal or folder changes the interpretation of earlier messages. The controls being disabled during generation is a stated boundary, not a description of how context is reconciled afterward. [1][2][3]

Who should act, who should wait

Move now if you already use an available coding agent in a chosen terminal and can inspect results in a chat. Configure one automation with a deliberate folder, then check the selected terminal and agent before its scheduled run. Separately, use the chat controls when you need to continue a conversation in a different working folder, and check the Files view after changing terminals. Those are the behaviors this release says shipped. [1][2][3][4]

Wait before relying on this for unattended work that requires a known failure response, an agent result delivered to a channel, or a documented guarantee about agent permissions. None is established by the supplied material. If those requirements are not binding, try the shipped controls and inspect the actual chat result before expanding the workflow. The pre-start availability check narrows one risk; it does not settle the rest. [1][2][3][4]

Sources

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