Terminal connection shows as saved/connected in UI, but webui.db never actually stores it — and once you fix that by hand, chat tool-calls and the sidebar terminal disagree on what "the ID" even is

[cinnamaldehyd3]

Environment: Open WebUI Desktop v0.20 on Windows,
Open Terminal running in its own Docker container (not the bundled bare-metal one, which I turned off).
Reproduced this on a fresh install (fully uninstalled, deleted %APPDATA%\open-webui, rebooted, reinstalled from scratch) — same behavior, so this isn't specific to my setup or some leftover state from earlier testing.

Here's the situation, roughly in the order I found things out:

I added an Open Terminal connection through Admin Panel → Settings → Integrations, under Terminal, clicking the plus next to Open Terminal. URL, API key, Bearer auth, all correct. I confirmed the server itself was healthy the whole time (curl http://localhost:2806/health → {"status":"ok"}). The UI showed it as connected, and it stayed showing that way across app restarts, so as far as I could tell everything was fine.

But every chat message sent with the terminal attached failed instantly with:

Terminal server 'http://localhost:2806' not found

I dug through the backend log and found this:

File "...\open_webui\utils\middleware.py", line 2814, in process_chat_payload
terminal_result = await get_terminal_tools(
File "...\open_webui\utils\tools.py", line 1327, in get_terminal_tools
raise RuntimeError(f"Terminal server '{terminal_id}' not found")
RuntimeError: Terminal server 'http://localhost:2806/' not found

So I went and checked webui.db directly to see what was actually stored. Table is config, key is terminal_server.connections. It was just []. Empty. Even though the UI had been showing my connection as configured this whole time, nothing had ever actually landed in the database. So whatever the Save button in Admin Settings is doing, it's not writing to this key, or it's writing somewhere else that the chat backend doesn't read from.

I manually inserted a connection into that key by hand to test further:

[{"id":"open-terminal","name":"Open Terminal","enabled":true,"url":"http://localhost:2806","key":"secret-key-2806","auth_type":"bearer"}]

Chat tool-calls still failed the same way, still complaining about the URL specifically as terminal_id. So then I tried setting id to literally be the URL itself instead of a normal slug. That actually worked; the model could use the terminal fine after that.

Except now the sidebar's terminal/file browser panel broke, with:

[Error: Error: Failed to create session: 404]

My guess (haven't looked at the frontend/session code myself) is that whatever creates that interactive session sticks the ID directly into a URL path somewhere, and an ID that's itself a full URL (with :// and colons in it) breaks that path.

So near as I can tell there are two separate bugs stacked here:

1. Saving a terminal connection through Admin Settings → Integrations doesn't actually persist anything to terminal_server.connections in webui.db, despite the UI displaying it as saved/connected.
2. Even once you get something into that config key by hand, the chat tool-calling path (get_terminal_tools) looks up connections by matching the connection's url field against terminal_id, while the sidebar session-creation endpoint apparently expects a plain slug-style ID instead. There doesn't seem to be a single ID value that satisfies both at once.

Steps to reproduce #1 at least should be straightforward: add any terminal connection through Admin Settings, restart the app, then check terminal_server.connections in webui.db directly — I'd guess it comes up empty for most people, they just never have a reason to look.

Happy to grab more logs or test something if it'd help track this down further, just let me know what'd be useful.