Terminal Contexts
An orchestrator connection can be scoped per context. For chats and for automations separately, an administrator decides two things:
- whether the terminal can be used there at all
- whether everything shares one workspace, or every saved chat (or every automation) gets a workspace of its own
Connections to a plain Open Terminal server have no contexts. They stay available everywhere and always resolve to the same workspace.
The orchestrator provides the separate workspaces per chat and per automation. On an earlier orchestrator, Per chat and Per automation behave like Shared. Open WebUI applies Off and the saved-chat requirement either way.
Configure
- Open Settings > Admin > Integrations and scroll to the Terminal section.
- Add or edit a connection, then use Verify Connection next to the URL so Open WebUI detects the server type. The Orchestrator section only appears once the connection is detected as an orchestrator, or when it already carries a Policy ID.
- Expand Orchestrator and set Terminal Contexts.
| Row | Options |
|---|---|
| Chat | Shared, Per chat, Off |
| Automation | Shared, Per automation, Off |
Both rows default to Shared.
What Each Mode Does
| Mode | Effect |
|---|---|
| Shared | Every chat (or every automation) of the same user works in the same workspace |
| Per chat | Each saved chat gets its own workspace, with its own files |
| Per automation | Each automation gets its own workspace, reused across that automation's runs |
| Off | The terminal is not offered in that context, and requests for it are refused |
The two rows are independent. A terminal can be Per chat in chats and Off in automations, or Off in chats and Shared in automations.
Whichever mode you pick applies to the whole terminal: the model's tools, the file browser and the terminal panel all work in the same place.
A terminal that is Off for chats is not listed in the chat terminal picker, and one that is Off for automations is not listed in the automation editor, so users do not run into them. The model editor lists every terminal. A model pointed at a terminal that is closed to automations still works in chat, and its automation runs fail with an error saying the terminal is not available for automation.
Per Chat Needs a Saved Chat
A per chat workspace belongs to a specific conversation, so the conversation has to exist first. It does once the first message has been sent and the chat appears in the sidebar.
- In a new conversation that has not been sent yet, the terminal panel and file browser for that terminal are not available. They appear once the chat is saved. A file attached to the first message with Chat Uploads set to
Filesystemwaits until you send it, then uploads into the new chat's workspace. - In a temporary chat, a per chat terminal has nothing to attach to, because a temporary chat is never saved. The terminal picker hides it while temporary chat is on, and turning temporary chat on deselects it.
- Nothing in the interface quietly falls back to the shared workspace. Before the chat is saved the terminal is refused, and a model told to use it reports an error naming the terminal.
- A request that reaches the proxy with no chat id at all, such as a direct API call, is not scoped to any chat and lands in the shared workspace even when the row is Per chat. The Open WebUI interface always sends the chat id. System info is the exception: on a Per chat terminal it needs a saved chat, and the proxy answers
409withA saved chat is required for this terminalotherwise.
Capacity
Per chat multiplies the number of workspaces a single user can have running, one per chat they work in, each counting against the policy's resource limits. Before switching a busy connection to Per chat, set idle_timeout_minutes on the policy so workspaces for abandoned chats are cleaned up. See Policies.
Pre-Configuring It
The same setting can be shipped in TERMINAL_SERVER_CONNECTIONS under the connection's config.contexts, which is useful for deployments that configure everything at startup.
What This Does Not Do
Contexts are not a way to separate users from each other. That is what the orchestrator already does by giving each user their own workspace; contexts subdivide one user's own workspaces further. See Multi-User Setup for the isolation tiers.
Contexts also do not apply to a plain Open Terminal server, to connections added through personal Settings > Integrations or to any connection Open WebUI has not detected as an orchestrator.