Originally created by @silentoplayz on GitHub (Jun 16, 2025).
Check Existing Issues
I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
v0.6.14
Ollama Version (if applicable)
v0.9.0
Operating System
Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0
Browser (if applicable)
LibreWolf v135.0.1-1 (Firefox)
Confirmation
I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.
Expected Behavior
When the Direct Tool Servers permission is disabled for a user's role (e.g., User role), that user should not have access to the "Connections" tab within their personal settings. This tab, and the ability to add direct tool server connections, should only be visible and accessible if the user's has explicitly been granted this permission.
Actual Behavior
Even when the Direct Tool Servers permission is explicitly disabled for a User role (both in default and user group permissions), if Direct Connections is toggled ON in the Super Admin settings, users with the User role still have access to the "Connections" tab in their settings. This allows them to add direct tool server connections, bypassing the intended permission control.
Steps to Reproduce
Part 1: Admin Setup
Log in to Open WebUI as a Super Admin.
Navigate to Admin Panel > Settings > Connections.
Ensure the "Direct Connections" toggle is set to ON.
Navigate to Admin Panel > Users.
Select Groups, then the "Default permissions" tab.
Locate the Direct Tool Servers permission and ensure it is toggled OFF. Save changes.
(Optional but recommended for thorough testing): Create a new user group (e.g., "RestrictedUsers") and add a new user (e.g., testuser) to this group. Ensure the Direct Tool Servers permission is also toggled OFF for this user group.
Part 2: User Reproduction
Log out of the Super Admin account.
Log in as testuser (or any non-admin user with Direct Tool Servers permission disabled).
Navigate to the user's personal settings (usually by clicking their avatar/name in the bottom left corner).
Observe: The "Connections" tab is visible and clickable in the settings menu.
Click on the "Connections" tab.
Observe: The user is able to add and manage direct tool server connections, despite their role not having the Direct Tool Servers permission.
Comparative Test (Expected Behavior with Notes Beta):
To confirm this is specific to Direct Tool Servers and not a general settings UI issue:
As Super Admin, navigate to Admin Panel > Settings > General.
Ensure "Notes (Beta)" is toggled ON.
Navigate to Admin Panel > Users > "Default permissions".
Ensure Notes (Beta) permission is toggled OFF. Save changes.
Log in as testuser.
Navigate to personal settings.
Observe: The "Notes (Beta)" tab is not visible. This demonstrates the expected behavior for feature visibility based on permissions, which is not occurring for Direct Tool Servers.
This issue indicates a potential oversight in how the Direct Tool Servers permission interacts with the global Direct Connections toggle. The global toggle appears to override granular user/role permissions, making it impossible for administrators to selectively grant or deny direct tool server connection capabilities.
This bypass could lead to:
Unauthorized Access: Users could connect to internal tools or services without explicit permission.
Security Risks: Unintended connections or misconfigurations by regular users.
Policy Violation: Inability to enforce organizational policies regarding tool access.
Originally created by @silentoplayz on GitHub (Jun 16, 2025).
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.6.14
### Ollama Version (if applicable)
v0.9.0
### Operating System
Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0
### Browser (if applicable)
LibreWolf v135.0.1-1 (Firefox)
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.**
- [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
- [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps:
- Start with the initial platform/version/OS and dependencies used,
- Specify exact install/launch/configure commands,
- List URLs visited, user input (incl. example values/emails/passwords if needed),
- Describe all options and toggles enabled or changed,
- Include any files or environmental changes,
- Identify the expected and actual result at each stage,
- Ensure any reasonably skilled user can follow and hit the same issue.
### Expected Behavior
When the `Direct Tool Servers` permission is disabled for a user's role (e.g., `User` role), that user should **not** have access to the "Connections" tab within their personal settings. This tab, and the ability to add direct tool server connections, should only be visible and accessible if the user's has explicitly been granted this permission.
### Actual Behavior
Even when the `Direct Tool Servers` permission is explicitly disabled for a `User` role (both in default and user group permissions), if `Direct Connections` is toggled `ON` in the Super Admin settings, users with the `User` role *still* have access to the "Connections" tab in their settings. This allows them to add direct tool server connections, bypassing the intended permission control.
### Steps to Reproduce
**Part 1: Admin Setup**
1. Log in to Open WebUI as a Super Admin.
2. Navigate to `Admin Panel` > `Settings` > `Connections`.
3. Ensure the "Direct Connections" toggle is set to `ON`.
4. Navigate to `Admin Panel` > `Users`.
5. Select `Groups`, then the "Default permissions" tab.
6. Locate the `Direct Tool Servers` permission and ensure it is toggled `OFF`. Save changes.
7. (Optional but recommended for thorough testing): Create a new user group (e.g., "RestrictedUsers") and add a new user (e.g., `testuser`) to this group. Ensure the `Direct Tool Servers` permission is also toggled `OFF` for this user group.
**Part 2: User Reproduction**
9. Log out of the Super Admin account.
10. Log in as `testuser` (or any non-admin user with `Direct Tool Servers` permission disabled).
11. Navigate to the user's personal settings (usually by clicking their avatar/name in the bottom left corner).
12. **Observe:** The "Connections" tab is visible and clickable in the settings menu.
13. Click on the "Connections" tab.
* **Observe:** The user is able to add and manage direct tool server connections, despite their role not having the `Direct Tool Servers` permission.
**Comparative Test (Expected Behavior with Notes Beta):**
To confirm this is specific to `Direct Tool Servers` and not a general settings UI issue:
1. As Super Admin, navigate to `Admin Panel` > `Settings` > `General`.
2. Ensure "Notes (Beta)" is toggled `ON`.
3. Navigate to `Admin Panel` > `Users` > "Default permissions".
4. Ensure `Notes (Beta)` permission is toggled `OFF`. Save changes.
5. Log in as `testuser`.
6. Navigate to personal settings.
* **Observe:** The "Notes (Beta)" tab is **not** visible. This demonstrates the expected behavior for feature visibility based on permissions, which is *not* occurring for `Direct Tool Servers`.
### Logs & Screenshots
https://github.com/user-attachments/assets/be19e206-6a20-4338-807a-79625ed656de
### Additional Information
This issue indicates a potential oversight in how the `Direct Tool Servers` permission interacts with the global `Direct Connections` toggle. The global toggle appears to override granular user/role permissions, making it impossible for administrators to selectively grant or deny direct tool server connection capabilities.
This bypass could lead to:
* **Unauthorized Access:** Users could connect to internal tools or services without explicit permission.
* **Security Risks:** Unintended connections or misconfigurations by regular users.
* **Policy Violation:** Inability to enforce organizational policies regarding tool access.
GiteaMirror
added the bug label 2025-11-11 16:24:17 -06:00
Upon testing the issue again, I still see the Connections tab in the settings menu on a user account, even when the Direct Tool Servers permission is toggled off for both Default permissions and User Group permissions. To be hopefully clearer, this appears to be a permission issue for User accounts when the Direct Tool Servers feature is toggled on by an admin in the admin panel Connections settings.
@silentoplayz commented on GitHub (Jun 16, 2025):
> Good catch, should be addressed with [b748d5e](https://github.com/open-webui/open-webui/commit/b748d5edee80a7afbb50456f9debaf29b38eb6e5)!
Upon testing the issue again, I still see the `Connections` tab in the settings menu on a user account, even when the `Direct Tool Servers` permission is toggled off for both `Default` permissions and `User Group` permissions. To be hopefully clearer, this appears to be a permission issue for `User` accounts when the `Direct Tool Servers` feature is toggled on by an admin in the admin panel `Connections` settings.
@silentoplayz Connections tab is for direct inference connections and not direct tool connections, not sure what you meant here.
@tjbck commented on GitHub (Jun 19, 2025):
@silentoplayz `Connections` tab is for direct inference connections and not direct tool connections, not sure what you meant here.
@thenicekat it seems like I got confused by this issue post, and it was working as intended and this wasn't an issue in the first place.
@tjbck commented on GitHub (Jun 19, 2025):
@thenicekat it seems like I got confused by this issue post, and it was working as intended and this wasn't an issue in the first place.
Yes but the tools tab doesn't come up for non admins. Even though this issue was confusing looks like there's an actual problem?
@thenicekat commented on GitHub (Jun 19, 2025):
Yes but the tools tab doesn't come up for non admins. Even though this issue was confusing looks like there's an actual problem?
@tjbck commented on GitHub (Jun 19, 2025):
Yeah it seems like we retroactively introduced the issue by misunderstanding, and incorrectly addressing the "non-existent" issue.
a196b9dc261606cc9083090cd35a43ba849fb062 should resolve it
@tjbck commented on GitHub (Jun 19, 2025):
`Connections` is for direct model/inference connections and `Tools` is for direct tool connections, so everything **was** working intended but https://github.com/open-webui/open-webui/commit/b748d5edee80a7afbb50456f9debaf29b38eb6e5 introduced a new bug @thenicekat described and https://github.com/open-webui/open-webui/commit/a196b9dc261606cc9083090cd35a43ba849fb062 reverts the issue.
My apologies for the confusion caused due to my bug report. After analyzing comments and what I've reported, I noticed I did get Connections for direct model/inference connections and Direct Tool Servers for Tools mixed up in my mind, believing there was a bug when there in fact wasn't. Again, my apologies.
@silentoplayz commented on GitHub (Jun 19, 2025):
My apologies for the confusion caused due to my bug report. After analyzing comments and what I've reported, I noticed I did get `Connections` for direct model/inference connections and `Direct Tool Servers` for `Tools` mixed up in my mind, believing there was a bug when there in fact wasn't. Again, my apologies.
It's all good and definitely not your fault, I take full responsibility for not reading/examining it properly from my end
@tjbck commented on GitHub (Jun 19, 2025):
It's all good and definitely not your fault, I take full responsibility for not reading/examining it properly from my end
It's all good and definitely not your fault, I take full responsibility for not reading/examining it properly from my end
I’m definitely at fault, and I’m here to take full responsibility for it. I shouldn’t have submitted this false bug report in the first place. I thought I had found a bug and knew how to "reproduce" it, which led to this unnecessary complication of fixing a non-existent bug. I opened this issue around the same time as eight other bug reports on the same day, so I understand if you took this bug report just as serious and gave it a quick glance before jumping in. I truly appreciate your efforts and do apologize for any confusion or wasted time this may have caused.
@silentoplayz commented on GitHub (Jun 19, 2025):
> It's all good and definitely not your fault, I take full responsibility for not reading/examining it properly from my end
I’m definitely at fault, and I’m here to take full responsibility for it. I shouldn’t have submitted this false bug report in the first place. I *thought* I had found a bug and knew how to "reproduce" it, which led to this unnecessary complication of fixing a non-existent bug. I opened this issue around the same time as eight other bug reports on the same day, so I understand if you took this bug report just as serious and gave it a quick glance before jumping in. I truly appreciate your efforts and do apologize for any confusion or wasted time this may have caused.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @silentoplayz on GitHub (Jun 16, 2025).
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.14
Ollama Version (if applicable)
v0.9.0
Operating System
Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0
Browser (if applicable)
LibreWolf v135.0.1-1 (Firefox)
Confirmation
README.md.Expected Behavior
When the
Direct Tool Serverspermission is disabled for a user's role (e.g.,Userrole), that user should not have access to the "Connections" tab within their personal settings. This tab, and the ability to add direct tool server connections, should only be visible and accessible if the user's has explicitly been granted this permission.Actual Behavior
Even when the
Direct Tool Serverspermission is explicitly disabled for aUserrole (both in default and user group permissions), ifDirect Connectionsis toggledONin the Super Admin settings, users with theUserrole still have access to the "Connections" tab in their settings. This allows them to add direct tool server connections, bypassing the intended permission control.Steps to Reproduce
Part 1: Admin Setup
Admin Panel>Settings>Connections.ON.Admin Panel>Users.Groups, then the "Default permissions" tab.Direct Tool Serverspermission and ensure it is toggledOFF. Save changes.testuser) to this group. Ensure theDirect Tool Serverspermission is also toggledOFFfor this user group.Part 2: User Reproduction
testuser(or any non-admin user withDirect Tool Serverspermission disabled).Direct Tool Serverspermission.Comparative Test (Expected Behavior with Notes Beta):
To confirm this is specific to
Direct Tool Serversand not a general settings UI issue:Admin Panel>Settings>General.ON.Admin Panel>Users> "Default permissions".Notes (Beta)permission is toggledOFF. Save changes.testuser.Direct Tool Servers.Logs & Screenshots
https://github.com/user-attachments/assets/be19e206-6a20-4338-807a-79625ed656de
Additional Information
This issue indicates a potential oversight in how the
Direct Tool Serverspermission interacts with the globalDirect Connectionstoggle. The global toggle appears to override granular user/role permissions, making it impossible for administrators to selectively grant or deny direct tool server connection capabilities.This bypass could lead to:
@tjbck commented on GitHub (Jun 16, 2025):
Good catch, should be addressed with b748d5edee80a7afbb50456f9debaf29b38eb6e5!
@silentoplayz commented on GitHub (Jun 16, 2025):
Upon testing the issue again, I still see the
Connectionstab in the settings menu on a user account, even when theDirect Tool Serverspermission is toggled off for bothDefaultpermissions andUser Grouppermissions. To be hopefully clearer, this appears to be a permission issue forUseraccounts when theDirect Tool Serversfeature is toggled on by an admin in the admin panelConnectionssettings.@tjbck commented on GitHub (Jun 19, 2025):
@silentoplayz
Connectionstab is for direct inference connections and not direct tool connections, not sure what you meant here.@thenicekat commented on GitHub (Jun 19, 2025):
@tjbck regardless the bug I pointed out still exists. Non admin users cannot see tools tab
@tjbck commented on GitHub (Jun 19, 2025):
@thenicekat it seems like I got confused by this issue post, and it was working as intended and this wasn't an issue in the first place.
@thenicekat commented on GitHub (Jun 19, 2025):
Yes but the tools tab doesn't come up for non admins. Even though this issue was confusing looks like there's an actual problem?
@tjbck commented on GitHub (Jun 19, 2025):
Yeah it seems like we retroactively introduced the issue by misunderstanding, and incorrectly addressing the "non-existent" issue.
a196b9dc26should resolve it@thenicekat commented on GitHub (Jun 19, 2025):
oh right, understood now, thank you
@tjbck commented on GitHub (Jun 19, 2025):
Connectionsis for direct model/inference connections andToolsis for direct tool connections, so everything was working intended but https://github.com/open-webui/open-webui/commit/b748d5edee80a7afbb50456f9debaf29b38eb6e5 introduced a new bug @thenicekat described and https://github.com/open-webui/open-webui/commit/a196b9dc261606cc9083090cd35a43ba849fb062 reverts the issue.@silentoplayz commented on GitHub (Jun 19, 2025):
My apologies for the confusion caused due to my bug report. After analyzing comments and what I've reported, I noticed I did get
Connectionsfor direct model/inference connections andDirect Tool ServersforToolsmixed up in my mind, believing there was a bug when there in fact wasn't. Again, my apologies.@tjbck commented on GitHub (Jun 19, 2025):
It's all good and definitely not your fault, I take full responsibility for not reading/examining it properly from my end
@silentoplayz commented on GitHub (Jun 19, 2025):
I’m definitely at fault, and I’m here to take full responsibility for it. I shouldn’t have submitted this false bug report in the first place. I thought I had found a bug and knew how to "reproduce" it, which led to this unnecessary complication of fixing a non-existent bug. I opened this issue around the same time as eight other bug reports on the same day, so I understand if you took this bug report just as serious and gave it a quick glance before jumping in. I truly appreciate your efforts and do apologize for any confusion or wasted time this may have caused.
@thenicekat commented on GitHub (Jun 25, 2025):
Hello @tjbck could you create a release with this fix?