Commands Menu disappears after unmount and remounting the plugin

[maoguy]

Describe the bug
After calling window.mountChainlitWidget, window.unmountChainlitWidget, and window.mountChainlitWidget in sequence, the menu is lost.

To Reproduce
Steps to reproduce the behavior:

1. use window.mountChainlitWidget to mount a chainlit plugin;
2. use window.unmountChainlitWidget to unmount the chainlit plugin of step 1;
3. use window.mountChainlitWidget to mount a chainlit plugin again;
4. See error

Expected behavior

Commands Menu disappears after unmount and remounting the plugin

Screenshots

When we use window.mountChainlitWidget success,we can see the commands menu is showing corrected.👇

However,if we use window.unmountChainlitWidget to unmount.After that we use window.mountChainlitWidget again,we will can not see the commands menu.👇

I believe the root cause is that after the plug-in was uninstalled and remounted, no new session was initiated.Therefore the websocket of backend don`t know when should push the new config again.👇

[dosubot]

Your analysis is on the right track: the Commands Menu depends on session and WebSocket state, and remounting the widget doesn't always trigger a new session or re-initialize the backend config. This is a known challenge in Chainlit, as sessions are tightly coupled to WebSocket connections, and missing session affinity (like headers or cookies) can prevent UI elements from being restored after remounting—especially in multi-pod or load-balanced setups. Proper cleanup and re-initialization of the WebSocket and session state are necessary to restore the Commands Menu after remounting, but there isn't a documented workaround or direct fix for this specific scenario yet. For more on session and WebSocket lifecycle issues, see this discussion and this session affinity issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[maoguy]

I believe the plugin should expose configurable lifecycle hooks—such as a "afterMounted" that fires once the plugin is successfully mounted,or a "beforeUnmounted" hook that is invoked right before the plugin is torn down.

With either of these two lifecycle hooks available, we could call window.clearChainlitCopilotThreadId inside mountedCallback (to start a fresh session after remount) or inside beforeUnmounted (to clean up the current session before the plugin is torn down), ensuring the thread ID is properly reset.

If needed, I’m happy to submit a PR that adds support for both mountedCallback and beforeUnmounted.☺

[dosubot]

Chainlit doesn't currently expose official frontend lifecycle hooks like "afterMounted" or "beforeUnmounted" for its widget/plugin system. Session and thread management is tightly coupled to the WebSocket lifecycle, so remounting the widget doesn't always trigger a new session or re-initialize backend state, which can cause issues like the Commands Menu disappearing. There is also no official documentation for window.clearChainlitCopilotThreadId—it appears to be a custom or userland method.

The most reliable workaround is to manually manage session or thread cleanup and initialization at each mount/unmount transition. Since there are no built-in lifecycle events, teams often poll for DOM readiness (e.g., checking for a specific widget element) and then run custom logic to reset state or reconnect as needed. For now, robust session management during remounts requires custom integration at these transition points, as Chainlit doesn't provide out-of-the-box hooks for these events. See related discussions for more context: widget readiness and frontend lifecycle, session lifecycle and cleanup.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[maoguy]

Chainlit doesn't currently expose official frontend lifecycle hooks like "afterMounted" or "beforeUnmounted" for its widget/plugin system. Session and thread management is tightly coupled to the WebSocket lifecycle, so remounting the widget doesn't always trigger a new session or re-initialize backend state, which can cause issues like the Commands Menu disappearing. There is also no official documentation for window.clearChainlitCopilotThreadId—it appears to be a custom or userland method.

The most reliable workaround is to manually manage session or thread cleanup and initialization at each mount/unmount transition. Since there are no built-in lifecycle events, teams often poll for DOM readiness (e.g., checking for a specific widget element) and then run custom logic to reset state or reconnect as needed. For now, robust session management during remounts requires custom integration at these transition points, as Chainlit doesn't provide out-of-the-box hooks for these events. See related discussions for more context: widget readiness and frontend lifecycle, session lifecycle and cleanup.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other    

The method of clearChainlitCopilotThreadId has already been implemented in this PR. 👉 #2299

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.