Fix chat session routing from Sessions page and toast notifications#611
Open
QQSHI13 wants to merge 2 commits into
Open
Fix chat session routing from Sessions page and toast notifications#611QQSHI13 wants to merge 2 commits into
QQSHI13 wants to merge 2 commits into
Conversation
added 2 commits
May 31, 2026 19:42
Add SessionKey property to OpenClawNotification so toast activations can route to the specific session that produced the assistant response. Update EmitChatNotification to accept and populate the session key from the gateway chat event payload.
Previously, clicking a session in the Sessions tab or a chat toast
notification always opened the default/main session instead of the
specific session.
Changes:
- Add App.PendingChatSessionKey as a fallback when HubWindow does not
exist (background notifications, closed HubWindow).
- Thread sessionKey through ToastActivationRouter (Action<string?>).
- Embed sessionKey in chat toast arguments and route it on activation.
- ChatPage (functional): consume pending key from both HubWindow and
App fallbacks; use !string.IsNullOrEmpty guard to treat empty string
as null.
- ChatPage (WebView): consume pending key and append &session={key} to
the navigation URL, or pass it through GatewayChatHelper on initial
WebView init.
- SessionsPage: write key to CurrentApp.PendingChatSessionKey in
addition to hub.PendingChatSessionKey.
- Update tests for the new OpenChat Action<string?> contract.
Fixes session routing for both native FunctionalUI and legacy WebView2
chat surfaces.
|
Codex review: needs real behavior proof before merge. Reviewed May 31, 2026, 7:50 AM ET / 11:50 UTC. Summary Reproducibility: yes. by source inspection: current main drops session context in chat notifications/toast activation and only consumes HubWindow pending state in ChatPage. I did not run the Windows UI flow because this review is read-only and tests/builds would write artifacts. Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land a focused routing fix that preserves the existing pending-session handoff, proves native and WebView session selection from Sessions and toast clicks, and reports full AGENTS validation. Do we have a high-confidence way to reproduce the issue? Yes, by source inspection: current main drops session context in chat notifications/toast activation and only consumes HubWindow pending state in ChatPage. I did not run the Windows UI flow because this review is read-only and tests/builds would write artifacts. Is this the best way to solve the issue? Yes, the PR uses the existing gateway, toast, App, HubWindow, and ChatPage hand-off points rather than adding a competing routing path. It still needs real app proof and complete validation before merge. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against b9313e5c12ee. Label changesLabel changes:
Label justifications:
Evidence reviewedAcceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🦪 silver shellfish
Author
|
@clawsweeper Re-review requested — live behavior proof added below. Live behavior proofTested from Windows build of the tray app (working tree copied from WSL to Sessions tab → specific session
Toast notification → specific session
Full validationReady for re-review. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Author
|
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. Re-review progress:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Clicking a session entry in the Sessions tab, or clicking a chat toast notification, always opened the default/main session instead of the specific session that was selected or that produced the notification.
Root Cause
The session routing path had gaps at every hand-off point:
OpenClawNotificationhad noSessionKeyproperty, so chat toasts couldn't carry the source session.ToastActivationRouter.OpenChatwasAction(no parameters), so the toast'ssessionKeyargument was ignored.ShowWebChatdidn't accept or forward a session key.ChatPageonly checked_hub?.PendingChatSessionKey, which isnullwhen the HubWindow doesn't exist (background notifications, closed window).pendingSessionKey is not nullguard treated""as a valid key, and the provider fallback to_mountedThreadIdcould return a stale default.&session={key}to the chat URL — it always navigated to the bare gateway root.Changes
Commit 1: Thread session key through chat notifications
OpenClawNotification: AddSessionKeyproperty.OpenClawGatewayClient.EmitChatNotification: AcceptsessionKeyparameter (fromHandleChatEventpayload) and set it on the notification.Commit 2: Fix chat session routing from Sessions page and toast notifications
App.PendingChatSessionKey: New fallback property whenHubWindowdoesn't exist. Consumed (cleared) byChatPage.App.ShowWebChat(string? sessionKey): Accepts session key, stashes it on bothAppandHubWindowsoChatPagecan pick it up after navigation.ToastActivationRouter:OpenChatchanged fromAction→Action<string?>. ReadssessionKeyfrom toast arguments and passes it through.App.OnGatewayNotificationReceived: EmbedssessionKeyin chat toast body arguments and the "Open Chat" toast button.ChatPage(FunctionalUI):_hub?.PendingChatSessionKeyand(App.Current as App)?.PendingChatSessionKey!string.IsNullOrEmpty()guard so""is treated as nullforceRemount = !string.IsNullOrEmpty(pendingSessionKey)ensures a remount when a key arrivesChatPage(WebView):_pendingWebViewSessionKeyfieldShowWebViewSurface: consumes pending key fromHubWindoworAppfallbacksNavigateWebViewToCurrentChatUrl: appends&session={key}to the URL (deduping any existingsessionparam)InitializeWebViewAsync: passes_pendingWebViewSessionKeythroughGatewayChatHelper.TryBuildChatUrlSessionsPage.OnOpenChat: Writes key toCurrentApp.PendingChatSessionKey(fallback) in addition tohub.PendingChatSessionKey.ToastActivationRouterTestsandAppRefactorContractTestsfor the newAction<string?>contract. AddedRoute_OpenChat_PassesSessionKeyArgument.Test Results
Verification Steps
?token=...&session={key}.