From e70a7a51154bad5676bd02acf6bccc0e4507d89a Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 12 May 2026 19:11:32 +0100 Subject: [PATCH] fix(notifications): treat /c/new as no current conversation useMatch('/c/:conversationId') treats the literal URL /c/new as a real conversation id, so the toast suppression check confused 'user is on /c/new' with 'user is on the conversation needing approval'. Explicit guard: when the matched id is 'new', fall through to the no-match case so approval toasts still surface. --- frontend/src/notifications/ToolApprovalToast.tsx | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/frontend/src/notifications/ToolApprovalToast.tsx b/frontend/src/notifications/ToolApprovalToast.tsx index e4357923..60653682 100644 --- a/frontend/src/notifications/ToolApprovalToast.tsx +++ b/frontend/src/notifications/ToolApprovalToast.tsx @@ -32,12 +32,20 @@ export default function ToolApprovalToast() { // place a conversation in view: the bare ``/c/:conversationId`` and // the agent-scoped ``/agents/:agentId/c/:conversationId``. Hooks // are unconditional; the toast just respects whichever matches. + // + // ``/c/new`` is the conversation route's literal-string placeholder + // for "unknown / not-yet-loaded conversation" (see the rewrite in + // the conversation route). Treat it the same as no match — the + // user isn't viewing any specific conversation yet, so an approval + // toast for any conversation should still surface. const plainMatch = useMatch('/c/:conversationId'); const agentMatch = useMatch('/agents/:agentId/c/:conversationId'); - const currentConversationId = + const matchedConversationId = plainMatch?.params.conversationId ?? agentMatch?.params.conversationId ?? null; + const currentConversationId = + matchedConversationId === 'new' ? null : matchedConversationId; // Conversation name lookup — best-effort. The slice's // ``preference.conversations.data`` is populated by