# Shared chat page refreshes on load, which strips out URL fragment identifiers > Source: > Published: 2026-11-11 09:34:22+00:00 I have a bug to report in Kagi Assistant, which make it very difficult to usefully share LLM transcripts. When using the public share link, the page seems to reload or redirect itself on load, but it doesn't preserve any URL fragments when doing so (e.g. [https://assistant.kagi.com/share/f70a3701-edc3-49f4-8cbb-2ef65c497488#:~:text=The%20differences%20run%20deeper%20than,feedback%20loops%2C%20employer%2Dled%20delivery%29%2E](https://assistant.kagi.com/share/f70a3701-edc3-49f4-8cbb-2ef65c497488#:~:text=The%20differences%20run%20deeper%20than,feedback%20loops%2C%20employer%2Dled%20delivery%29%2E)). This means that it's not possible to use [text fragment identifiers](https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments) to jump the user to a specific part of the transcript (see attached video for a demonstration — it works the second time because the text fragment applies to the already-loaded page). [This issue](https://kagifeedback.org/d/8979-allow-links-to-individual-messages-in-ai-chat/3) is related, as it asks for unique `id` attributes for the different chat messages to allow them to be identified with element fragments. My use case requires the more specific *text* fragments, but I think resolving this issue would also unblock a solution there (because currently, even if the elements did all have unique `id` s, they would also be stripped on page load). [This issue](https://kagifeedback.org/d/4029-research-assistant-references-are-difficult-to-check-implement-text-fragments) also talks about text fragments, but is not related—it is asking for the *agent* to use them when referencing other sources (which, as far as I can tell, is currently the case but [with limitations](https://kagifeedback.org/d/4029-research-assistant-references-are-difficult-to-check-implement-text-fragments/)