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
0.9.2
Ollama Version (if applicable)
No response
Operating System
Linux
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 you click a chat share link for eg. https://<URL>/s/<share id>, it should lead to the shared Chat.
Actual Behavior
Clicking on a shared chat link takes you to the homepage of OpenWebUI.
Steps to Reproduce
Create a Chat.
Share the Chat.
Copy the chat share link.
Paste the link in your browser.
This leads to the homepage of OpenWebUI.
Logs & Screenshots
Nothing wrong in the logs.
Additional Information
No response
Originally created by @seamon67 on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24096
### 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
0.9.2
### Ollama Version (if applicable)
_No response_
### Operating System
Linux
### 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 you click a chat share link for eg. https://\<URL\>/s/\<share id\>, it should lead to the shared Chat.
### Actual Behavior
Clicking on a shared chat link takes you to the homepage of OpenWebUI.
### Steps to Reproduce
1. Create a Chat.
2. Share the Chat.
3. Copy the chat share link.
4. Paste the link in your browser.
5. This leads to the homepage of OpenWebUI.
### Logs & Screenshots
Nothing wrong in the logs.
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-04-25 09:53:31 -05:00
I also found the same issue in the dev environment
<!-- gh-comment-id:4318365856 -->
@sleepyddl commented on GitHub (Apr 25, 2026):
> can confirm and reproduce in current dev
I also found the same issue in the dev environment
<!-- gh-comment-id:4318629437 -->
@sleepyddl commented on GitHub (Apr 25, 2026):
If you run under http://localhost:5173, this issue will not occur, but if you run under http://ip:5173, this issue can be reproduced
I believe the root cause lies in an issue with the copy functionality. After debugging, I found that the share link is generated correctly, but something goes wrong when calling copyToClipboard.
This issue only occurs under HTTP (non-localhost environments). Since the system cannot access navigator.clipboard over HTTP, it falls back to simulating the copy operation by creating a DOM element. The relevant code is as follows: textArea.style.position = 'fixed'; document.body.appendChild(textArea); textArea.focus({ preventScroll: true }); textArea.select();
Theoretically, this process should work without issues. Unfortunately, textArea.focus() does not execute as expected (I suspect the animation effect is causing the focus to be lost, but I haven’t figured out how to verify this). As a result, the text fails to be copied from the textarea.
I tested the session copy feature, which runs the exact same code and works perfectly. I noticed that the MENU does not disappear when copying the session, whereas clicking the "Copy Link" button triggers the MENU to hide. I think the MENU’s hide animation is causing the textarea to lose focus.
Is there any frontend expert who can explain this?
I’ve switched from using textarea.focus to the Selection Range method, which resolves the issue properly. I will submit a PR shortly.
<!-- gh-comment-id:4319615210 -->
@sleepyddl commented on GitHub (Apr 25, 2026):
I believe the root cause lies in an issue with the copy functionality. After debugging, I found that the share link is generated correctly, but something goes wrong when calling copyToClipboard.
This issue only occurs under HTTP (non-[localhost](https://localhost/) environments). Since the system cannot access navigator.clipboard over HTTP, it falls back to simulating the copy operation by creating a DOM element. The relevant code is as follows:
`
textArea.style.position = 'fixed';
document.body.appendChild(textArea);
textArea.focus({ preventScroll: true });
textArea.select();
`
Theoretically, this process should work without issues. Unfortunately, textArea.focus() does not execute as expected (I suspect the animation effect is causing the focus to be lost, but I haven’t figured out how to verify this). As a result, the text fails to be copied from the textarea.
I tested the session copy feature, which runs the exact same code and works perfectly. I noticed that the MENU does not disappear when copying the session, whereas clicking the "Copy Link" button triggers the MENU to hide. I think the MENU’s hide animation is causing the textarea to lose focus.
Is there any frontend expert who can explain this?
I’ve switched from using textarea.focus to the Selection Range method, which resolves the issue properly. I will submit a PR shortly.
@sleepyddl Does this fix previously shared links as well - ones created before 0.9?
<!-- gh-comment-id:4319764503 -->
@seamon67 commented on GitHub (Apr 25, 2026):
@sleepyddl Does this fix previously shared links as well - ones created before 0.9?
@sleepyddl Does this fix previously shared links as well - ones created before 0.9?
Sorry, I didn't read your problem description carefully.This fix can't resolve the link reading issue. It fixes the link creation issue instead.
<!-- gh-comment-id:4319798630 -->
@sleepyddl commented on GitHub (Apr 25, 2026):
> [@sleepyddl](https://github.com/sleepyddl) Does this fix previously shared links as well - ones created before 0.9?
Sorry, I didn't read your problem description carefully.This fix can't resolve the link reading issue. It fixes the link creation issue instead.
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 @seamon67 on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24096
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.9.2
Ollama Version (if applicable)
No response
Operating System
Linux
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When you click a chat share link for eg. https://<URL>/s/<share id>, it should lead to the shared Chat.
Actual Behavior
Clicking on a shared chat link takes you to the homepage of OpenWebUI.
Steps to Reproduce
Logs & Screenshots
Nothing wrong in the logs.
Additional Information
No response
@TomTheWise commented on GitHub (Apr 24, 2026):
can confirm and reproduce in current dev
@sleepyddl commented on GitHub (Apr 25, 2026):
I also found the same issue in the dev environment
@sleepyddl commented on GitHub (Apr 25, 2026):
If you run under http://localhost:5173, this issue will not occur, but if you run under http://ip:5173, this issue can be reproduced
@seamon67 commented on GitHub (Apr 25, 2026):
I am using a reverse proxy
@sleepyddl commented on GitHub (Apr 25, 2026):
I believe the root cause lies in an issue with the copy functionality. After debugging, I found that the share link is generated correctly, but something goes wrong when calling copyToClipboard.
This issue only occurs under HTTP (non-localhost environments). Since the system cannot access navigator.clipboard over HTTP, it falls back to simulating the copy operation by creating a DOM element. The relevant code is as follows:
textArea.style.position = 'fixed'; document.body.appendChild(textArea); textArea.focus({ preventScroll: true }); textArea.select();Theoretically, this process should work without issues. Unfortunately, textArea.focus() does not execute as expected (I suspect the animation effect is causing the focus to be lost, but I haven’t figured out how to verify this). As a result, the text fails to be copied from the textarea.
I tested the session copy feature, which runs the exact same code and works perfectly. I noticed that the MENU does not disappear when copying the session, whereas clicking the "Copy Link" button triggers the MENU to hide. I think the MENU’s hide animation is causing the textarea to lose focus.
Is there any frontend expert who can explain this?
I’ve switched from using textarea.focus to the Selection Range method, which resolves the issue properly. I will submit a PR shortly.
@seamon67 commented on GitHub (Apr 25, 2026):
I can't access old share links created before the update
@seamon67 commented on GitHub (Apr 25, 2026):
@sleepyddl Does this fix previously shared links as well - ones created before 0.9?
@sleepyddl commented on GitHub (Apr 25, 2026):
Sorry, I didn't read your problem description carefully.This fix can't resolve the link reading issue. It fixes the link creation issue instead.