I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
v0.6.26
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
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 cloning a prompt in the workspace, the access_control property is always set to null. Instead, the cloned prompt should inherit access_control from the original prompt, so all permissions and restrictions remain intact unless intentionally changed.
Actual Behavior
Cloned prompt receives access_control:null regardless of the original prompt value. This resets any custom sharing and permission settings, which can result in unintended access or sharing issues for users who expect those permissions to carry over with clones.
Steps to Reproduce
Install and run the latest Open WebUI
Create a new prompt with custom access_control settings
Use the Clone feature in the workspace prompts UI
Observe that the cloned prompt arrives at the create screen with access_control set to null rather than being copied from the original
Confirm that saving the cloned prompt requires re-specifying access_control, or it will default to none
Check for permission/sharing differences between original and clone.
Logs & Screenshots
See browser console or backend logs for prompt creation and cloning events. No error is thrown, but the resulting prompt data confirms that access_control is dropped during cloning.
Additional Information
Cloned prompts are visible to other users.
Originally created by @evgeni-semenov on GitHub (Nov 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19360
### Check Existing Issues
- [x] I have searched for any existing and/or related issues.
- [x] I have searched for any existing and/or related discussions.
- [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.6.26
### Ollama Version (if applicable)
_No response_
### Operating System
Debian 12
### Browser (if applicable)
_No response_
### 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 cloning a prompt in the workspace, the access_control property is always set to null. Instead, the cloned prompt should inherit access_control from the original prompt, so all permissions and restrictions remain intact unless intentionally changed.
### Actual Behavior
Cloned prompt receives access_control:null regardless of the original prompt value. This resets any custom sharing and permission settings, which can result in unintended access or sharing issues for users who expect those permissions to carry over with clones.
### Steps to Reproduce
1. Install and run the latest Open WebUI
2. Create a new prompt with custom access_control settings
3. Use the Clone feature in the workspace prompts UI
4. Observe that the cloned prompt arrives at the create screen with access_control set to null rather than being copied from the original
5. Confirm that saving the cloned prompt requires re-specifying access_control, or it will default to none
6. Check for permission/sharing differences between original and clone.
### Logs & Screenshots
See browser console or backend logs for prompt creation and cloning events. No error is thrown, but the resulting prompt data confirms that access_control is dropped during cloning.
### Additional Information
Cloned prompts are visible to other users.
Good point. It also doesn't make sense for the access control to be set to Public by default when a prompt is cloned. It should be set to whatever the access control level was of the prompt being cloned or set to Private by default. A prompt is private by default upon creation, so why is it public by default for cloned prompts?
Edit: This same issue occurs with cloned tools (clone loses access control level), but cloned tools are made Private by default as expected.
<!-- gh-comment-id:3579882430 -->
@silentoplayz commented on GitHub (Nov 26, 2025):
Good point. It also doesn't make sense for the access control to be set to `Public` by default when a prompt is cloned. It should be set to whatever the access control level was of the prompt being cloned or set to `Private` by default. A prompt is private by default upon creation, so why is it public by default for cloned prompts?
Edit: This same issue occurs with cloned tools (clone loses access control level), but cloned tools are made `Private` by default as expected.
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 @evgeni-semenov on GitHub (Nov 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19360
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.26
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When cloning a prompt in the workspace, the access_control property is always set to null. Instead, the cloned prompt should inherit access_control from the original prompt, so all permissions and restrictions remain intact unless intentionally changed.
Actual Behavior
Cloned prompt receives access_control:null regardless of the original prompt value. This resets any custom sharing and permission settings, which can result in unintended access or sharing issues for users who expect those permissions to carry over with clones.
Steps to Reproduce
Logs & Screenshots
See browser console or backend logs for prompt creation and cloning events. No error is thrown, but the resulting prompt data confirms that access_control is dropped during cloning.
Additional Information
Cloned prompts are visible to other users.
@silentoplayz commented on GitHub (Nov 26, 2025):
Good point. It also doesn't make sense for the access control to be set to
Publicby default when a prompt is cloned. It should be set to whatever the access control level was of the prompt being cloned or set toPrivateby default. A prompt is private by default upon creation, so why is it public by default for cloned prompts?Edit: This same issue occurs with cloned tools (clone loses access control level), but cloned tools are made
Privateby default as expected.@Classic298 commented on GitHub (Dec 14, 2025):
@silentoplayz freebie?
@Classic298 commented on GitHub (Dec 16, 2025):
fixed in dev