[GH-ISSUE #19360] issue: Cloned prompt loses access_control settings

GiteaMirror commented

2026-04-20 01:04:55 -05:00

Owner

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

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.

GiteaMirror added the confirmed issue bug labels 2026-04-20 01:04:55 -05:00

GiteaMirror closed this issue

2026-04-20 01:04:55 -05:00

GiteaMirror commented

2026-04-20 01:04:56 -05:00

Author

Owner

@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.

@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.

GiteaMirror commented

2026-04-20 01:04:57 -05:00

Author

Owner

@Classic298 commented on GitHub (Dec 14, 2025):

@silentoplayz freebie?

@Classic298 commented on GitHub (Dec 14, 2025): @silentoplayz freebie?

GiteaMirror commented

2026-04-20 01:04:57 -05:00

Author

Owner

@Classic298 commented on GitHub (Dec 16, 2025):