Open WebUI put coding agents in the model picker. Keep the permission receipt

THE SIGNAL IN ONE SENTENCE

A model picker used to answer a simple question: which model do you want to talk to? Open WebUI 0.13.1 turns that menu into something more consequential. Coding agents exposed through Open Terminal, including Claude Code, Codex and Pi, can now appear beside regular chat models. A user can start an agent conversation, choose reasoning effort and service tier where supported, approve tool requests inside the chat and even talk to the agent by voice. That sounds like a tidy interface improvement. It is actually a change in authority. A chat model drafts text. A coding agent may inspect a repository, edit files, run commands, install packages, open network connections and leave behind changes that outlive the conversation. When those two things occupy the same familiar picker, the interface has to communicate the difference before the user clicks. Open WebUI's November 8 release notes describe several guardrails and several rough edges. Each agent conversation is bound to one agent. Agent messages cannot be regenerated, and a user cannot edit and resubmit an earlier prompt in the ordinary chat pattern. If the connected terminal disappears, existing and new agent conversations can fall back to the default model, while earlier replies keep the original agent name. That fallback detail deserves more attention than it will probably get. If a conversation begins with an agent that can act on a computer and later continues with a model that cannot, the identity on screen can become historically true but operationally stale. The user needs to know which system produced each answer, which system currently holds the turn and whether any pending tool action survived the handoff. The same release introduces Tether, a desktop companion for macOS, Windows and Linux. Open WebUI says Tether connects a computer outward to an Open WebUI instance, so no inbound port needs to be opened. Once connected, models, agents and automations can work with real files, repositories and local tools from a browser or phone. The project says output can resume after a temporary drop and that unused sessions expire after 90 days by default. That is a useful architecture. It also means the browser can become a remote control for a machine that contains unfinished code, credentials, customer material and personal files. The correct mental model is not chat with extra buttons. It is a remote execution system wearing chat's comfortable clothes. Open WebUI also adds an optional Auto tool permissions mode. It is off by default. When enabled, a configured scoring model can review a requested tool call and decide whether to allow it automatically. The release notes say that review can include the tool name, its arguments and recent conversation context. If the scoring request fails, times out or cannot fit the needed context, the interface falls back to asking the user. This can reduce approval fatigue. It can also create permission laundering if the human sees fewer requests without receiving a durable explanation of what the scoring model allowed. An automatic reviewer is still a model making a judgment from selected context. It may miss that a path contains production secrets. It may approve a command that is safe in one repository and destructive in another. It may not know that the user asked for analysis, not modification. It may receive sensitive recent messages through a separate API path. So every consequential action needs a permission receipt. The receipt starts with identity. Name the agent, provider, model and version. Show the Open Terminal session and the Tether device that will execute the action. If either identity changes, stop and ask again for actions that were approved under the old identity. Then show scope. Display the exact tool, arguments, working directory, files and network destinations. Summaries such as access files or run command are too vague. A user should be able to tell the difference between reading package.json and recursively rewriting an entire workspace. Next comes consequence. Label whether the action is read-only, creates a file, changes tracked code, installs software, sends data, uses credentials, changes a remote service or can delete material. A plain-language risk class is more useful than a wall of shell syntax, but the exact syntax should remain available. Then record the decision. Was the request approved by the user, a standing rule or the Auto tool permissions model? Which policy and scoring model version were used? What recent context was sent for review? What reason did the reviewer give? When will the grant expire? Finally, record execution. Approval does not prove that a command ran, and a command's exit code does not prove that the intended result occurred. The receipt should keep the start time, end time, output summary, changed files, network calls, errors, retries and final repository state. If a tool loop stops after the same failure twice, as version 0.13.1 now does, the receipt should show both failures and the stop. This is not bureaucracy for its own sake. It is how a person reconstructs a surprising change on Tuesday that began as a casual request on Monday. The release includes other useful improvements. Open WebUI says it no longer rewrites tool definitions on every round, which can improve prompt-cache reuse and reduce cost. Tool Search calls can be batched, tool labels are clearer and search scoring has changed. These are performance and usability improvements, not permission guarantees. Version 0.13.2 followed later on November 8 with targeted fixes, including UUID-related problems. That quick patch is ordinary software practice. It is also a reminder that this is a fresh integration surface. Teams should expect identity, state, reconnection and compatibility bugs while the feature settles. There is a strong reason to try it. Open WebUI gives teams a self-hostable place to reach multiple models and tools. Putting coding agents into the same workspace can make them easier to compare, easier to share and easier to supervise. Tether can let a person start a task from a phone while the actual work happens on a chosen computer. A visible approval panel can be much safer than burying permission questions in a terminal scrollback. The interface can become the control room, provided it behaves like one. That means the picker should distinguish an answer-only model from an acting agent before selection. A persistent badge should show the current agent and device. Pending actions should pause if the terminal disconnects. Reconnection should require proof that the same session and workspace returned. A fallback model should never inherit an old action grant simply because it inherited the conversation. Standing rules need tight boundaries. Allow reading inside one repository, not the whole home directory. Permit tests, not arbitrary package installation. Allow network access to named registries, not the open internet. Expire every grant. Make the emergency stop independent of the agent and the scoring model. Privacy also needs a map. A local computer can send file contents through the selected agent provider, a tool service, Open WebUI, a scoring API, logs and backups. Tether's outbound connection avoids exposing an inbound port, but it does not make every data path local. Administrators should document which system receives prompts, files, tool arguments, recent context, outputs and telemetry. The public release notes verify that the features exist and describe their intended behavior. They do not certify a particular installation, network policy or provider configuration. They do not prove that an automatic reviewer will approve the right actions. They do not remove the need to test the real system with a disposable repository before connecting it to important work. The model picker has become a power picker. That can be excellent. Just make the power visible. Put the agent, machine, action, reviewer, result and fallback identity on one receipt. Then the person can approve the work, inspect the consequences and know exactly which machine in the room moved first.