@remit/web-client 0.0.18 → 0.0.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/web-client",
-  "version": "0.0.18",
+  "version": "0.0.20",
   "type": "module",
   "description": "Remit web client, published as composable primitives — the app shell, auth shells, and runtime config. A distributor imports what it composes and bundles it.",
   "exports": {

package/src/components/layout/MailTopBar.tsx

@@ -9,6 +9,13 @@
  * The actions here are the ones that belong to the app rather than to whatever
  * is currently listed or open — compose, bug report, account. Reply, delete,
  * move and the rest stay on the reading pane's own toolbar, under this bar.
+ *
+ * The field carries one chip: the scope of the view the user navigated into
+ * (`in:spam` in Spam, nothing on the brief). Removing it goes to the brief and
+ * searches everything. Typed `in:`/`from:` terms are not chipped here — they
+ * are already visible as the text the user typed, and chipping them would show
+ * the same term twice in one field; they render as chips over the result
+ * sections instead, where the text is not repeated.
  */
 import type { RemitImapAccountResponse } from "@remit/api-http-client/types.gen.ts";
 import { AppTopBar, Button, SearchBar } from "@remit/ui";
@@ -16,8 +23,16 @@ import { SquarePen } from "lucide-react";
 import { AccountMenu } from "@/auth/AccountMenu";
 import { BugReportButton } from "@/components/ui/BugReportButton";
 import { useGlobalCompose } from "@/hooks/useComposeTarget";
+import { useSearchScope } from "@/hooks/useSearchScope";
 import { tooltipForAction } from "@/lib/keymap";
 import { useMailContext } from "@/lib/mail-context";
+import type { SearchScopeState } from "@/lib/search-scope";
+
+const SEARCH_PLACEHOLDER: Record<SearchScopeState["kind"], string> = {
+	global: "Search all mail",
+	pending: "Search mail",
+	scoped: "Search this folder",
+};
 
 interface MailTopBarProps {
 	accounts: RemitImapAccountResponse[];
@@ -27,6 +42,15 @@ export function MailTopBar({ accounts }: MailTopBarProps) {
 	const { searchInput, onSearchChange, onSearchClear, onSearchClearQuery } =
 		useMailContext();
 	const compose = useGlobalCompose(accounts);
+	const { scope, clearScope } = useSearchScope(accounts);
+	const chips =
+		scope.kind === "scoped"
+			? [{ id: scope.chip.id, label: scope.chip.label, tone: "scope" as const }]
+			: undefined;
+	// Only the brief may claim to search all mail. A mailbox route whose name has
+	// not loaded yet has no chip to show but is already narrowed, so it gets the
+	// neutral wording rather than a placeholder that asserts the wrong scope.
+	const placeholder = SEARCH_PLACEHOLDER[scope.kind];
 
 	return (
 		<AppTopBar
@@ -41,7 +65,9 @@ export function MailTopBar({ accounts }: MailTopBarProps) {
 					onChange={onSearchChange}
 					onClear={onSearchClear}
 					onClearQuery={onSearchClearQuery}
-					placeholder="Search all mail"
+					chips={chips}
+					onRemoveChip={clearScope}
+					placeholder={placeholder}
 					size="lg"
 				/>
 			}

package/src/components/mail/DailyBrief.tsx

@@ -40,6 +40,7 @@ import { useNavigate } from "@tanstack/react-router";
 import { AlertCircle, RefreshCw, Sparkles } from "lucide-react";
 import { useCallback, useMemo, useState } from "react";
 import { useIsDesktop } from "@/hooks/useMediaQuery";
+import { useSearchTokenContext } from "@/hooks/useSearchTokenContext";
 import { useSemanticSearch } from "@/hooks/useSemanticSearch";
 import { sortAccountsByCreatedAt } from "@/lib/account-order";
 import {
@@ -168,7 +169,8 @@ export function DailyBrief({
 	onSelectMessage,
 	onSelectSearchResult,
 }: DailyBriefProps) {
-	const { searchQuery, mailboxNameIndex, accountNameIndex } = useMailContext();
+	const { searchQuery } = useMailContext();
+	const tokenContext = useSearchTokenContext();
 	const isDesktop = useIsDesktop();
 
 	const nonMuted = useMemo(
@@ -259,7 +261,7 @@ export function DailyBrief({
 
 	const { freeText: sq, tokens: queryTokens } = parseSearchTokens(
 		searchQuery.trim().toLowerCase(),
-		{ mailboxesByName: mailboxNameIndex, accountsByName: accountNameIndex },
+		tokenContext,
 	);
 
 	// Convert API rows to ThreadRowData, narrowing only by the selected account

package/src/components/mail/FlaggedList.tsx

@@ -22,6 +22,7 @@ import {
 import { useCallback, useMemo, useState } from "react";
 import { formatErrorMessage } from "@/components/ui/ErrorState";
 import { useIsDesktop } from "@/hooks/useMediaQuery";
+import { useSearchTokenContext } from "@/hooks/useSearchTokenContext";
 import { useStarredThreads } from "@/hooks/useStarredThreads";
 import {
 	matchesBriefSearch,
@@ -49,7 +50,8 @@ export function FlaggedList({
 	selectedMessageId,
 	onSelectMessage,
 }: FlaggedListProps) {
-	const { searchQuery, mailboxNameIndex, accountNameIndex } = useMailContext();
+	const { searchQuery } = useMailContext();
+	const tokenContext = useSearchTokenContext();
 	const isDesktop = useIsDesktop();
 
 	const [selectedCategory, setSelectedCategory] = useState("all");
@@ -84,7 +86,7 @@ export function FlaggedList({
 
 	const { freeText: sq, tokens: queryTokens } = parseSearchTokens(
 		searchQuery.trim().toLowerCase(),
-		{ mailboxesByName: mailboxNameIndex, accountsByName: accountNameIndex },
+		tokenContext,
 	);
 
 	const rows = useMemo<ThreadRowData[]>(() => {

package/src/components/mail/MailListHeader.tsx

@@ -34,6 +34,7 @@ import {
 } from "@remit/ui";
 import { type ReactNode, useEffect, useRef, useState } from "react";
 import { isSinglePaneTier, useLayoutTier } from "@/hooks/useLayoutTier";
+import { useSearchTokenContext } from "@/hooks/useSearchTokenContext";
 import { useMailContext } from "@/lib/mail-context";
 import { loadRecentSearches, saveRecentSearch } from "@/lib/recent-searches";
 import {
@@ -81,14 +82,9 @@ export function MailListHeader({
 	searchResultsLabel = "Top matches",
 	relatedResultsLabel = "Related",
 }: MailListHeaderProps) {
-	const {
-		searchInput,
-		onSearchChange,
-		onSearchClear,
-		searchViewKey,
-		mailboxNameIndex,
-		accountNameIndex,
-	} = useMailContext();
+	const { searchInput, onSearchChange, onSearchClear, searchViewKey } =
+		useMailContext();
+	const tokenContext = useSearchTokenContext();
 	const layout = useAppShellLayout();
 	const tier = useLayoutTier();
 	const [searchOpen, setSearchOpen] = useState(false);
@@ -105,18 +101,18 @@ export function MailListHeader({
 	}, [searchViewKey]);
 
 	const hasQuery = searchInput.trim().length > 0;
-	// Filter tokens (`from:`, `has:attachment`, `in:`, `account:`, …) parsed live
-	// from the typed query render as removable chips above the sections;
-	// removing one edits the query text directly, which re-parses on the next
-	// render. `in:`/`account:` resolve against the shared name indexes so a
-	// chip only appears for a name that actually matches a mailbox/account.
-	const tokenChips = parseSearchTokens(searchInput, {
-		mailboxesByName: mailboxNameIndex,
-		accountsByName: accountNameIndex,
-	}).tokens.map((token) => ({
-		label: searchTokenLabel(token),
-		onRemove: () => onSearchChange(removeSearchToken(searchInput, token)),
-	}));
+	// Filter tokens (`from:`, `has:attachment`, `account:`, …) parsed live from
+	// the typed query render as removable chips above the sections; removing one
+	// edits the query text directly, which re-parses on the next render. The
+	// parse runs through `useSearchTokenContext`, the same one the engines use,
+	// so a chip appears only for a term that is actually being applied — on a
+	// scoped view `in:` is not resolved and so is never chipped here.
+	const tokenChips = parseSearchTokens(searchInput, tokenContext).tokens.map(
+		(token) => ({
+			label: searchTokenLabel(token),
+			onRemove: () => onSearchChange(removeSearchToken(searchInput, token)),
+		}),
+	);
 	const topMatches = searchResults ?? [];
 	const related = relatedResults ?? [];
 	// Always offer both sections while a query is present; the kit drops the empty

package/src/components/mail/MailSidebarAdapter.tsx

@@ -291,8 +291,17 @@ export function MailSidebarAdapter({
 	};
 
 	const handleSelectNav = () => {
-		// Navigation is handled by the router <Link>; this only runs the
-		// post-selection side effect (drawer auto-close on mobile).
+		// Navigation is handled by the router <Link>; this runs the
+		// post-selection side effects.
+		//
+		// Clearing the field is one of them. Every link above drops `q`, and the
+		// shell re-seeds the field from the destination's `q` when the view
+		// changes — but picking the folder you are already in is the same view,
+		// so the shell leaves the field alone and the previous query would sit in
+		// the bar over a list that no longer has it in the URL. Selecting a nav
+		// entry is an unambiguous "show me this", so it clears here regardless.
+		// It is a user action, not a mirror, so it cannot race in-flight typing.
+		onSearchChange("");
 		onMailboxSelect?.();
 	};
 

package/src/components/mail/MailboxPane.tsx

@@ -88,6 +88,7 @@ import { useMailboxAccount } from "@/hooks/useMailboxAccount";
 import { useToggleReadFor } from "@/hooks/useMarkAsRead";
 import { useMoveMessages } from "@/hooks/useMoveMessages";
 import { useRescueCandidates } from "@/hooks/useRescueCandidates";
+import { useSearchTokenContext } from "@/hooks/useSearchTokenContext";
 import { useSemanticSearch } from "@/hooks/useSemanticSearch";
 import { useToggleStar } from "@/hooks/useToggleStar";
 import { useTriageKeyboard } from "@/hooks/useTriageKeyboard";
@@ -247,28 +248,25 @@ function MailboxPaneProvider({
 	const telemetry = useTelemetry();
 	const {
 		accounts,
-		mailboxNameIndex,
-		accountNameIndex,
 		searchQuery,
 		searchInput,
 		intelligenceOpen,
 		onToggleIntelligence,
 		onSetIntelligenceOpen,
 	} = useMailContext();
+	const tokenContext = useSearchTokenContext();
 
 	const normalizedSearchQuery = normalizeSearchQuery(searchQuery);
 	const hasSearchQuery = normalizedSearchQuery.length > 0;
 	// Filter tokens (`from:`, `has:attachment`, `is:unread`) narrow this literal
 	// search to the params `threadOperationsSearchThreads` supports; `before:`/
 	// `after:`/`account:` have no equivalent on this endpoint and are left for
-	// the semantic section only (see `useSemanticSearch`). `in:` is likewise not
-	// applied here — this view is already scoped to one mailbox by its route —
-	// but still needs the name-index context so a resolved `in:`/`account:`
-	// token is stripped from `freeText` instead of leaking into the literal
-	// query text as a stray word.
+	// the semantic section only (see `useSemanticSearch`). `in:` never reaches
+	// here at all: this view is scoped to one mailbox by its route, so
+	// `useSearchTokenContext` does not resolve the term and it stays free text.
 	const { freeText, tokens: searchTokens } = parseSearchTokens(
 		normalizedSearchQuery,
-		{ mailboxesByName: mailboxNameIndex, accountsByName: accountNameIndex },
+		tokenContext,
 	);
 	const fromToken = searchTokens.find((t) => t.type === "from");
 	const searchThreadsQuery = {
@@ -949,12 +947,13 @@ function MailboxList() {
 		() => threads.map(threadToSearchResult),
 		[threads],
 	);
-	// The field above every pane says "Search all mail", and it means it (#47).
-	// The literal engine only searches one mailbox at a time (there is no
-	// cross-mailbox thread search), so this view names that section after the
-	// mailbox and lets the semantic engine run unscoped — the "Everywhere"
-	// section reaches the rest of the mail. Results are deduped by thread, so a
-	// thread never shows in both.
+	// The route scopes this view, and the top bar's chip says so. Both sections
+	// are named by the ground they cover so that scope is never overstated: the
+	// literal engine searches this mailbox and nothing else (there is no
+	// cross-mailbox thread search), while the semantic engine runs unscoped and
+	// its section says "Everywhere" (#47). Reaching past the folder is a labelled
+	// section, not a silent widening of the chip. Results are deduped by thread,
+	// so a thread never shows in both.
 	const { hits: semanticHits, isLoading: relatedLoading } = useSemanticSearch({
 		filterCategory,
 	});

package/src/components/mail/MessageList.tsx

@@ -232,6 +232,12 @@ export const MessageList = ({
 	// leave this null, so the list never yanks focus out of the reading pane.
 	const pendingDomFocusRef = useRef<string | null>(null);
 
+	// The row the cursor was on when the delete confirmation opened. The dialog
+	// takes DOM focus for as long as it is up, so dismissing it has to give that
+	// focus back or the list is left with no cursor and the next shortcut acts on
+	// nothing (#80).
+	const focusBeforeConfirmRef = useRef<string | null>(null);
+
 	// Whether the list can serve keyboard commands at all. It stays true while
 	// the delete confirmation is open — withdrawing the commands there would let
 	// the route fall through to its own unconfirmed delete on a second Delete
@@ -341,9 +347,10 @@ export const MessageList = ({
 	const requestDelete = useCallback(
 		(ids: string[]) => {
 			if (!onDeleteMessages || ids.length === 0) return;
+			focusBeforeConfirmRef.current = focusedMessageId ?? null;
 			setPendingDeleteIds(ids);
 		},
-		[onDeleteMessages],
+		[onDeleteMessages, focusedMessageId],
 	);
 
 	// Keyboard shift-arrow range extend: move focus one row in `direction` and
@@ -452,9 +459,14 @@ export const MessageList = ({
 
 		onDeleteMessages?.(pendingDeleteIds);
 		clearSelection();
+		focusBeforeConfirmRef.current = null;
 		setPendingDeleteIds(null);
 
 		if (nextFocus !== undefined) {
+			// Same hand-back as cancelling, aimed at the surviving neighbour
+			// instead: confirming also closes a dialog that held DOM focus.
+			pendingDomFocusRef.current = nextFocus;
+			setFocusedMessageId(nextFocus);
 			navigate({
 				to: "/mail/$mailboxId",
 				params: { mailboxId },
@@ -471,8 +483,17 @@ export const MessageList = ({
 		mailboxId,
 	]);
 
+	// Every way out of the confirmation that isn't the delete — Escape, Cancel,
+	// the backdrop — arrives here, so this is the one place the keyboard has to
+	// be handed back. Restoring the cursor also puts DOM focus back on that row,
+	// via the same pending-focus channel j/k use.
 	const handleCancelDelete = useCallback(() => {
+		const restoreTo = focusBeforeConfirmRef.current;
+		focusBeforeConfirmRef.current = null;
 		setPendingDeleteIds(null);
+		if (restoreTo === null) return;
+		pendingDomFocusRef.current = restoreTo;
+		setFocusedMessageId(restoreTo);
 	}, []);
 
 	// Handle mark as read

package/src/components/mail/OutboxPane.tsx

@@ -46,8 +46,16 @@ import { MessageBody } from "@/components/mail/MessageBody";
 import { NavMenuButton } from "@/components/mail/NavMenuButton";
 import { useErrorBanners } from "@/components/ui/ErrorBannerProvider";
 import { buildMutationErrorBanner } from "@/components/ui/error-banners";
+import { useSearchTokenContext } from "@/hooks/useSearchTokenContext";
 import { formatDate as formatLocaleDate, toDate } from "@/lib/format";
+import { useMailContext } from "@/lib/mail-context";
+import {
+	matchesOutboxSearch,
+	outboxQueryIsUnsupported,
+} from "@/lib/outbox-search";
 import { isOutboxListRow, isUnsendableStatus } from "@/lib/outbox-status";
+import { normalizeSearchQuery } from "@/lib/search-query";
+import { parseSearchTokens } from "@/lib/search-tokens";
 import { cn } from "@/lib/utils";
 
 /* ------------------------------------------------------------------ */
@@ -103,12 +111,31 @@ const formatRecipients = (message: RemitImapOutboxMessageResponse): string => {
 	return `${recipients[0]} +${recipients.length - 1}`;
 };
 
+/**
+ * What an empty outbox list says. A query that filtered everything out reads
+ * differently from an empty outbox, and a query the outbox cannot serve at all
+ * has to say so rather than look like a search that found nothing.
+ */
+const outboxEmptyMessage = (
+	hasQuery: boolean,
+	unsupportedQuery: boolean,
+): string => {
+	if (unsupportedQuery) return "The outbox cannot filter on those terms";
+	if (hasQuery) return "No matching outbox messages";
+	return "No outbox messages";
+};
+
 /* ------------------------------------------------------------------ */
 /* Context                                                              */
 /* ------------------------------------------------------------------ */
 
 interface OutboxPaneContextValue {
+	/** Outbox rows, narrowed by the search query when one is active. */
 	messages: RemitImapOutboxMessageResponse[];
+	/** True while a query is narrowing `messages` — the empty state differs. */
+	hasQuery: boolean;
+	/** True when that query asks for a filter the outbox cannot apply. */
+	unsupportedQuery: boolean;
 	isLoading: boolean;
 	selectedMessageId: string | undefined;
 	selectedMessage: RemitImapOutboxMessageResponse | undefined;
@@ -143,6 +170,20 @@ function OutboxPaneProvider({ children }: OutboxPaneProps) {
 		outboxOperationsListOutboxMessagesOptions(),
 	);
 
+	// The top bar's field scopes to this view (`in:outbox`), so a query typed
+	// here narrows these rows. The list is small and already fully loaded, so
+	// the narrowing is a filter over what is in hand — see lib/outbox-search.ts
+	// for which fields it matches and why the filter tokens are not honored.
+	// The query is parsed the same way every other engine parses it, and only
+	// the free text is used: `Q3 from:billing` still matches on "Q3" rather
+	// than searching the rows for the literal string "from:billing".
+	const { searchQuery } = useMailContext();
+	const tokenContext = useSearchTokenContext();
+	const normalizedQuery = normalizeSearchQuery(searchQuery);
+	const parsedQuery = parseSearchTokens(normalizedQuery, tokenContext);
+	const hasQuery = normalizedQuery.length > 0;
+	const unsupportedQuery = outboxQueryIsUnsupported(parsedQuery);
+
 	// Outbox surfaces in-flight + actionable rows only. `draft` lives in the
 	// Drafts view; `sent` rows are deleted by the IMAP append handler once
 	// the message lands in Sent (issue #178), but we filter defensively so a
@@ -150,10 +191,12 @@ function OutboxPaneProvider({ children }: OutboxPaneProps) {
 	// has not completed yet (issue #193).
 	const messages = useMemo(
 		() =>
-			(outboxResponse?.items ?? []).filter((item) =>
-				isOutboxListRow(item.status),
-			),
-		[outboxResponse],
+			unsupportedQuery
+				? []
+				: (outboxResponse?.items ?? [])
+						.filter((item) => isOutboxListRow(item.status))
+						.filter((item) => matchesOutboxSearch(item, parsedQuery.freeText)),
+		[outboxResponse, parsedQuery.freeText, unsupportedQuery],
 	);
 
 	const selectedMessage = useMemo(
@@ -176,6 +219,8 @@ function OutboxPaneProvider({ children }: OutboxPaneProps) {
 
 	const ctx: OutboxPaneContextValue = {
 		messages,
+		hasQuery,
+		unsupportedQuery,
 		isLoading,
 		selectedMessageId,
 		selectedMessage,
@@ -381,8 +426,14 @@ function OutboxMessageDetail({ message, onBack }: OutboxMessageDetailProps) {
  * Outbox list with datum bar header. Mount in the `list` slot of `AppShellSlotted`.
  */
 function OutboxList() {
-	const { messages, isLoading, selectedMessageId, onSelectMessage } =
-		useOutboxPane();
+	const {
+		messages,
+		hasQuery,
+		unsupportedQuery,
+		isLoading,
+		selectedMessageId,
+		onSelectMessage,
+	} = useOutboxPane();
 
 	if (isLoading) {
 		return (
@@ -395,7 +446,10 @@ function OutboxList() {
 	if (messages.length === 0) {
 		return (
 			<div className="flex h-full bg-surface">
-				<ReadingPaneEmpty message="No outbox messages" showHints={false} />
+				<ReadingPaneEmpty
+					message={outboxEmptyMessage(hasQuery, unsupportedQuery)}
+					showHints={false}
+				/>
 			</div>
 		);
 	}
@@ -462,6 +516,8 @@ function OutboxReading() {
 function OutboxPhone() {
 	const {
 		messages,
+		hasQuery,
+		unsupportedQuery,
 		isLoading,
 		selectedMessageId,
 		selectedMessage,
@@ -488,7 +544,10 @@ function OutboxPhone() {
 	if (messages.length === 0) {
 		return (
 			<div className="flex h-full bg-surface">
-				<ReadingPaneEmpty message="No outbox messages" showHints={false} />
+				<ReadingPaneEmpty
+					message={outboxEmptyMessage(hasQuery, unsupportedQuery)}
+					showHints={false}
+				/>
 			</div>
 		);
 	}

package/src/hooks/useSearchScope.ts

@@ -0,0 +1,49 @@
+import type { RemitImapAccountResponse } from "@remit/api-http-client/types.gen.ts";
+import { useNavigate, useRouterState } from "@tanstack/react-router";
+import { useCallback } from "react";
+import { useMailContext } from "@/lib/mail-context";
+import {
+	SEARCH_SCOPE_CHIP_ID,
+	type SearchScopeState,
+	searchScopeForRoute,
+} from "@/lib/search-scope";
+import { useCurrentMailboxName } from "./useCurrentMailboxName";
+
+/**
+ * The scope chip for the active route and the way off it.
+ *
+ * `clearScope` navigates to the daily brief carrying the current query, which
+ * is what "search everything" means here — the brief is the unscoped
+ * cross-account view. It is a navigation rather than a query edit because the
+ * chip mirrors the route (see `lib/search-scope.ts`); editing the text would
+ * leave the chip in place and the list still narrowed.
+ */
+export function useSearchScope(accounts: RemitImapAccountResponse[]): {
+	scope: SearchScopeState;
+	clearScope: (chipId: string) => void;
+} {
+	const navigate = useNavigate();
+	const { searchInput } = useMailContext();
+	const mailboxName = useCurrentMailboxName({ accounts });
+	// Select the matches, not the scope: a select closing over `mailboxName`
+	// only re-runs on router state changes, so the chip would keep reading the
+	// previous folder until the next navigation.
+	const matches = useRouterState({ select: (s) => s.matches });
+	const scope = searchScopeForRoute(matches, mailboxName);
+
+	// Takes the chip id the field removed rather than assuming which chip that
+	// was. The bar owns one chip today; keying on the id means a second one
+	// added later cannot silently drop the user out of their scope.
+	const clearScope = useCallback(
+		(chipId: string) => {
+			if (chipId !== SEARCH_SCOPE_CHIP_ID) return;
+			navigate({
+				to: "/mail",
+				search: { q: searchInput || undefined, selectedMessageId: undefined },
+			});
+		},
+		[navigate, searchInput],
+	);
+
+	return { scope, clearScope };
+}

package/src/hooks/useSearchTokenContext.ts

@@ -0,0 +1,28 @@
+import { useRouterState } from "@tanstack/react-router";
+import { useMailContext } from "@/lib/mail-context";
+import { isScopedRoute } from "@/lib/search-scope";
+import type { SearchTokenContext } from "@/lib/search-tokens";
+
+/**
+ * The one context every search engine parses the query through.
+ *
+ * `in:` is recognized only where the route carries no scope. On a scoped view
+ * the top bar's chip already answers "which mailbox", and a typed `in:` is a
+ * second, competing answer that no engine there acts on — the literal search is
+ * pinned to the route's mailbox and the semantic request takes the caller's
+ * scope. Leaving the term unresolved means it stays ordinary words: it is
+ * matched as text and never chipped, so the field can't advertise a filter that
+ * does nothing. To search another folder, drop the scope chip or go to it.
+ *
+ * Every call site takes this hook rather than building its own context, because
+ * the guarantee is that they agree. Two of them disagreeing is what made the
+ * same query behave one way on `/mail/flagged` and another on a mailbox.
+ */
+export function useSearchTokenContext(): SearchTokenContext {
+	const { mailboxNameIndex, accountNameIndex } = useMailContext();
+	const scoped = useRouterState({ select: (s) => isScopedRoute(s.matches) });
+	return {
+		...(scoped ? {} : { mailboxesByName: mailboxNameIndex }),
+		accountsByName: accountNameIndex,
+	};
+}

package/src/hooks/useSemanticSearch.ts

@@ -5,6 +5,7 @@ import { useQuery } from "@tanstack/react-query";
 import { useMailContext } from "@/lib/mail-context";
 import { normalizeSearchQuery } from "@/lib/search-query";
 import { parseSearchTokens } from "@/lib/search-tokens";
+import { useSearchTokenContext } from "./useSearchTokenContext";
 
 /** Cap the "Related" section; the literal "Top matches" is the primary surface. */
 const SEMANTIC_RESULT_LIMIT = 20;
@@ -44,9 +45,14 @@ interface UseSemanticSearchParams {
  * account filter) — both still render as chips and narrow the literal engine,
  * but never reach the semantic request (`account:` is a documented gap, see
  * doc/design/flows/06-search.md — the semantic index is per account config).
- * `in:` resolves to a mailboxId and, when present, overrides the caller's
- * `mailboxId` — so typing `in:archive` re-scopes the semantic search to that
- * mailbox even from the cross-account daily brief.
+ * `in:` resolves to a mailboxId, so typing `in:archive` re-scopes the search
+ * from the unscoped daily brief. It cannot contradict a scoped view because
+ * `useSearchTokenContext` does not resolve the term there at all — the term
+ * stays free text and no engine, and no chip, treats it as a filter.
+ *
+ * Without a `mailboxId` the request spans every mailbox of every account the
+ * caller owns: the backend partitions the vector index by accountConfigId (one
+ * per signed-in user, not per mail account), so unscoped is genuinely global.
  */
 export function useSemanticSearch({
 	mailboxId,
@@ -55,12 +61,10 @@ export function useSemanticSearch({
 	hits: RemitImapSemanticSearchResult[];
 	isLoading: boolean;
 } {
-	const { searchQuery, mailboxNameIndex, accountNameIndex } = useMailContext();
+	const { searchQuery } = useMailContext();
+	const tokenContext = useSearchTokenContext();
 	const normalizedQuery = normalizeSearchQuery(searchQuery);
-	const { freeText, tokens } = parseSearchTokens(normalizedQuery, {
-		mailboxesByName: mailboxNameIndex,
-		accountsByName: accountNameIndex,
-	});
+	const { freeText, tokens } = parseSearchTokens(normalizedQuery, tokenContext);
 	const enabled = normalizedQuery.length > 0;
 
 	const category = toCategoryParam(filterCategory);
@@ -71,7 +75,7 @@ export function useSemanticSearch({
 	const afterToken = tokens.find((t) => t.type === "after");
 	const beforeToken = tokens.find((t) => t.type === "before");
 	const inToken = tokens.find((t) => t.type === "in");
-	const effectiveMailboxId = inToken?.mailboxId ?? mailboxId;
+	const effectiveMailboxId = mailboxId ?? inToken?.mailboxId;
 
 	const { data, isLoading } = useQuery({
 		...semanticSearchOperationsSemanticSearchOptions({

package/src/lib/outbox-search.test.ts

@@ -0,0 +1,75 @@
+import assert from "node:assert/strict";
+import { describe, it } from "node:test";
+import { matchesOutboxSearch, outboxQueryIsUnsupported } from "./outbox-search";
+import { parseSearchTokens } from "./search-tokens";
+
+const row = {
+	subject: "Q3 Invoice",
+	fromAddress: "me@example.com",
+	fromName: "Me",
+	toAddresses: ["billing@acme.test"],
+	ccAddresses: ["accounts@acme.test"],
+};
+
+describe("matchesOutboxSearch", () => {
+	it("keeps every row when there is no query", () => {
+		assert.equal(matchesOutboxSearch(row, "   "), true);
+	});
+
+	it("matches the subject", () => {
+		assert.equal(matchesOutboxSearch(row, "invoice"), true);
+	});
+
+	it("matches a recipient", () => {
+		assert.equal(matchesOutboxSearch(row, "acme"), true);
+	});
+
+	it("matches the sender", () => {
+		assert.equal(matchesOutboxSearch(row, "me@example"), true);
+	});
+
+	it("requires every word, in any order and any field", () => {
+		assert.equal(matchesOutboxSearch(row, "invoice billing"), true);
+		assert.equal(matchesOutboxSearch(row, "invoice missing"), false);
+	});
+
+	it("drops a row that matches nothing", () => {
+		assert.equal(matchesOutboxSearch(row, "receipt"), false);
+	});
+
+	it("tolerates rows with absent fields", () => {
+		assert.equal(matchesOutboxSearch({}, "anything"), false);
+		assert.equal(matchesOutboxSearch({}, ""), true);
+	});
+
+	it("matches the free text of a query that also carries a token", () => {
+		// The token is dropped, but what the user typed alongside it still
+		// searches — the row is not lost to an operator the outbox can't serve.
+		const { freeText } = parseSearchTokens("Q3 from:billing");
+		assert.equal(matchesOutboxSearch(row, freeText), true);
+	});
+});
+
+describe("outboxQueryIsUnsupported", () => {
+	it("is true for a query that is only tokens", () => {
+		assert.equal(
+			outboxQueryIsUnsupported(parseSearchTokens("from:billing")),
+			true,
+		);
+	});
+
+	it("is false when free text survives the parse", () => {
+		assert.equal(
+			outboxQueryIsUnsupported(parseSearchTokens("Q3 from:billing")),
+			false,
+		);
+	});
+
+	it("is false for plain free text", () => {
+		assert.equal(outboxQueryIsUnsupported(parseSearchTokens("invoice")), false);
+	});
+
+	it("is false for an empty query", () => {
+		assert.equal(outboxQueryIsUnsupported(parseSearchTokens("")), false);
+	});
+});

package/src/lib/outbox-search.ts

@@ -0,0 +1,58 @@
+/**
+ * Query narrowing for the outbox list.
+ *
+ * The outbox is a small, fully-loaded client-side list of mail that has not
+ * left yet, so its search is a filter over the rows already in hand rather
+ * than a request. It matches what an outbox row shows — subject, recipients
+ * and sender — because that is what the user can see to search for.
+ *
+ * Filter tokens (`from:`, `is:unread`, dates) are not honored: an outbox row
+ * has no read state, no mailbox and no received date, so the operators have
+ * nothing to read. Only the free text narrows, so `Q3 from:billing` still
+ * matches on "Q3".
+ *
+ * A query made only of tokens asks for a filter this view cannot apply, and
+ * there is no free text left to fall back on. Rather than return every row as
+ * if the filter had been honored, that case returns nothing and the list says
+ * why — see `outboxQueryIsUnsupported`.
+ */
+import type { ParsedSearchQuery } from "./search-tokens";
+
+/** The outbox row fields a query is matched against. */
+export interface OutboxSearchRow {
+	subject?: string | null;
+	fromAddress?: string | null;
+	fromName?: string | null;
+	toAddresses?: readonly string[] | null;
+	ccAddresses?: readonly string[] | null;
+}
+
+export function matchesOutboxSearch(
+	row: OutboxSearchRow,
+	freeText: string,
+): boolean {
+	const needle = freeText.trim().toLowerCase();
+	if (needle.length === 0) return true;
+	const haystack = [
+		row.subject,
+		row.fromAddress,
+		row.fromName,
+		...(row.toAddresses ?? []),
+		...(row.ccAddresses ?? []),
+	]
+		.filter((value): value is string => typeof value === "string")
+		.join(" ")
+		.toLowerCase();
+	return needle
+		.split(/\s+/)
+		.every((word) => word.length === 0 || haystack.includes(word));
+}
+
+/**
+ * True when the query is nothing but filter tokens. The outbox can serve none
+ * of them, and matching on the empty free text left over would return every
+ * row — indistinguishable from a filter that matched everything.
+ */
+export function outboxQueryIsUnsupported(parsed: ParsedSearchQuery): boolean {
+	return parsed.tokens.length > 0 && parsed.freeText.trim().length === 0;
+}

package/src/lib/search-scope.test.ts

@@ -0,0 +1,104 @@
+import assert from "node:assert/strict";
+import { describe, it } from "node:test";
+import {
+	MAIL_BRIEF_ROUTE_ID,
+	MAIL_FLAGGED_ROUTE_ID,
+	MAIL_MAILBOX_ROUTE_ID,
+	MAIL_OUTBOX_ROUTE_ID,
+} from "./mail-route";
+import {
+	isScopedRoute,
+	SEARCH_SCOPE_CHIP_ID,
+	scopeLabelForMailboxName,
+	searchScopeForRoute,
+} from "./search-scope";
+
+const matches = (routeId: string) => [{ routeId: "/mail" }, { routeId }];
+
+describe("searchScopeForRoute", () => {
+	it("gives the daily brief no scope — it is the global view", () => {
+		assert.deepEqual(searchScopeForRoute(matches(MAIL_BRIEF_ROUTE_ID)), {
+			kind: "global",
+		});
+	});
+
+	it("scopes a mailbox route to its sidebar label", () => {
+		assert.deepEqual(
+			searchScopeForRoute(matches(MAIL_MAILBOX_ROUTE_ID), "Spam"),
+			{
+				kind: "scoped",
+				chip: { id: SEARCH_SCOPE_CHIP_ID, label: "in:spam" },
+			},
+		);
+	});
+
+	it("is pending, not global, while the mailbox name resolves", () => {
+		// The list under the bar is already one mailbox. A chip reading a raw
+		// uuid is worse than no chip, but the field must not claim to search
+		// everything either.
+		assert.deepEqual(
+			searchScopeForRoute(matches(MAIL_MAILBOX_ROUTE_ID), null),
+			{ kind: "pending" },
+		);
+	});
+
+	it("scopes the starred view", () => {
+		const scope = searchScopeForRoute(matches(MAIL_FLAGGED_ROUTE_ID));
+		assert.equal(scope.kind === "scoped" && scope.chip.label, "is:starred");
+	});
+
+	it("scopes the outbox", () => {
+		const scope = searchScopeForRoute(matches(MAIL_OUTBOX_ROUTE_ID));
+		assert.equal(scope.kind === "scoped" && scope.chip.label, "in:outbox");
+	});
+
+	it("prefers the virtual views over a lingering mailbox name", () => {
+		const scope = searchScopeForRoute(matches(MAIL_OUTBOX_ROUTE_ID), "Spam");
+		assert.equal(scope.kind === "scoped" && scope.chip.label, "in:outbox");
+	});
+});
+
+describe("isScopedRoute", () => {
+	// This predicate decides whether a typed `in:` is recognized at all, so
+	// every route has to answer it the same way it answers for its chip: a
+	// route showing a scope chip must not also honour a competing typed term.
+	for (const routeId of [
+		MAIL_MAILBOX_ROUTE_ID,
+		MAIL_FLAGGED_ROUTE_ID,
+		MAIL_OUTBOX_ROUTE_ID,
+	]) {
+		it(`${routeId} carries a scope`, () => {
+			assert.equal(isScopedRoute(matches(routeId)), true);
+		});
+	}
+
+	it("the daily brief carries none", () => {
+		assert.equal(isScopedRoute(matches(MAIL_BRIEF_ROUTE_ID)), false);
+	});
+
+	it("agrees with the chip on every route", () => {
+		for (const routeId of [
+			MAIL_BRIEF_ROUTE_ID,
+			MAIL_MAILBOX_ROUTE_ID,
+			MAIL_FLAGGED_ROUTE_ID,
+			MAIL_OUTBOX_ROUTE_ID,
+		]) {
+			const scope = searchScopeForRoute(matches(routeId), "Spam");
+			assert.equal(
+				isScopedRoute(matches(routeId)),
+				scope.kind === "scoped",
+				`${routeId} disagrees about whether it has a scope`,
+			);
+		}
+	});
+});
+
+describe("scopeLabelForMailboxName", () => {
+	it("lower-cases so the chip reads like the operator it mimics", () => {
+		assert.equal(scopeLabelForMailboxName("Archive"), "in:archive");
+	});
+
+	it("quotes a multi-word folder so the chip stays one term", () => {
+		assert.equal(scopeLabelForMailboxName("Work  Stuff"), 'in:"work stuff"');
+	});
+});

package/src/lib/search-scope.ts

@@ -0,0 +1,114 @@
+/**
+ * The search scope is the route.
+ *
+ * Search is the app's search: one field in the top bar, and by default it
+ * covers everything. Navigating the sidebar narrows it, and the narrowing is
+ * shown as one chip in the field — `in:spam` while viewing Spam. The chip is
+ * derived from the active route, not parsed out of the typed text: the route
+ * decides which pane is mounted and which mail that pane reads, and the chip is
+ * that decision made visible. Navigating elsewhere replaces the chip because the
+ * route changed.
+ *
+ * Removing the chip means "search everything", which is the daily brief — the
+ * cross-account view whose scope is nothing. So removal is a navigation to
+ * `/mail/` carrying the query, not an edit of the query text.
+ *
+ * There is exactly one scope, and it is this one. A typed `in:` term is a
+ * second, competing answer to "which mailbox", so it is recognized only where
+ * there is no route scope to compete with — see `isScopedRoute` and
+ * `useSearchTokenContext`. Every engine parses the query through that one
+ * context, so a scoped view cannot show a chip for a term it is ignoring.
+ *
+ * Pure functions only. `useSearchScope` binds these to the router.
+ */
+import {
+	isBriefRoute,
+	isFlaggedRoute,
+	isMailboxRoute,
+	isOutboxRoute,
+	type MailRouteMatch,
+} from "./mail-route";
+
+/**
+ * Chip id of the scope chip. The top bar owns exactly one, so a fixed id is
+ * enough of a removal handle.
+ */
+export const SEARCH_SCOPE_CHIP_ID = "search-scope";
+
+export interface SearchScope {
+	id: string;
+	/** What the chip reads, e.g. `in:spam`. */
+	label: string;
+}
+
+/**
+ * What the field can say about its own scope.
+ *
+ * `pending` is the mailbox route before its name has loaded: the list under the
+ * bar is already one mailbox, so the field must not claim to search everything,
+ * but there is no name yet to put in a chip. It is a real third state, not a
+ * flavour of `global`.
+ */
+export type SearchScopeState =
+	| { kind: "global" }
+	| { kind: "pending" }
+	| { kind: "scoped"; chip: SearchScope };
+
+/**
+ * Render a mailbox name as an `in:` term. Lower-cased so it reads like the
+ * operator it mimics, and quoted when the name has whitespace so the chip
+ * stays one legible term.
+ */
+export function scopeLabelForMailboxName(name: string): string {
+	const collapsed = name.trim().replace(/\s+/g, " ").toLowerCase();
+	return /\s/.test(collapsed) ? `in:"${collapsed}"` : `in:${collapsed}`;
+}
+
+/**
+ * True on the routes whose pane reads one mailbox or one virtual collection.
+ * These carry a scope; the daily brief (and any route not recognized here) does
+ * not.
+ */
+export function isScopedRoute(matches: readonly MailRouteMatch[]): boolean {
+	return (
+		isFlaggedRoute(matches) || isOutboxRoute(matches) || isMailboxRoute(matches)
+	);
+}
+
+/**
+ * The scope of the active route.
+ *
+ * `mailboxName` is the sidebar's own label for the mailbox route (resolved by
+ * `useCurrentMailboxName`). Until it resolves the scope is `pending`: no chip,
+ * because a chip reading a raw uuid is worse than none, but not `global`
+ * either, because the list underneath is already narrowed.
+ */
+export function searchScopeForRoute(
+	matches: readonly MailRouteMatch[],
+	mailboxName?: string | null,
+): SearchScopeState {
+	if (isBriefRoute(matches)) return { kind: "global" };
+	if (isFlaggedRoute(matches)) {
+		return {
+			kind: "scoped",
+			chip: { id: SEARCH_SCOPE_CHIP_ID, label: "is:starred" },
+		};
+	}
+	if (isOutboxRoute(matches)) {
+		return {
+			kind: "scoped",
+			chip: { id: SEARCH_SCOPE_CHIP_ID, label: "in:outbox" },
+		};
+	}
+	if (isMailboxRoute(matches)) {
+		if (!mailboxName) return { kind: "pending" };
+		return {
+			kind: "scoped",
+			chip: {
+				id: SEARCH_SCOPE_CHIP_ID,
+				label: scopeLabelForMailboxName(mailboxName),
+			},
+		};
+	}
+	return { kind: "global" };
+}

package/src/lib/search-view.test.ts

@@ -109,3 +109,97 @@ describe("shouldMirrorQuery", () => {
 		assert.equal(shouldMirrorQuery("invoi", "inv", ""), false);
 	});
 });
+
+/**
+ * The three rules compose into the shell's behaviour (`routes/mail.tsx`): the
+ * field is re-seeded during render on a view change, and the mirror decides
+ * separately whether to write back. These check the composition, because the
+ * two ways search ends — a view change (#47) and the sidebar's own clear —
+ * both have to end it without ever writing over what the user is typing.
+ */
+interface Shell {
+	viewKey: string;
+	field: string;
+	debounced: string;
+	url: string;
+}
+
+/** One render of the shell for a location, returning the state it settles on. */
+const render = (shell: Shell, viewKey: string, url: string): Shell => {
+	const field =
+		viewKey === shell.viewKey
+			? shell.field
+			: (searchInputForView(shell.viewKey, viewKey, url) ?? shell.field);
+	return { ...shell, viewKey, field, url };
+};
+
+/** What the mirror effect would do after that render. */
+const mirror = (shell: Shell): Shell => {
+	const committed = committedSearchQuery(shell.field, shell.debounced);
+	if (!shouldMirrorQuery(shell.field, committed, shell.url)) return shell;
+	return { ...shell, url: committed };
+};
+
+const typing = (shell: Shell, text: string): Shell => ({
+	...shell,
+	field: text,
+});
+const settle = (shell: Shell): Shell => ({ ...shell, debounced: shell.field });
+
+describe("search across a view change", () => {
+	const searching: Shell = {
+		viewKey: mailViewKey(matches("/mail/$mailboxId", "inbox-1")),
+		field: "invoice",
+		debounced: "invoice",
+		url: "invoice",
+	};
+
+	it("ends the search when the user leaves the view", () => {
+		// The nav link drops `q`, so the destination carries none.
+		const next = mirror(
+			render(searching, mailViewKey(matches("/mail/$mailboxId", "sent-1")), ""),
+		);
+		assert.equal(next.field, "");
+		assert.equal(next.url, "");
+	});
+
+	it("does not put the query it just left onto the view it landed on", () => {
+		// The debounce still holds "invoice" for up to 200ms after the move. The
+		// mirror must not write it back — that is #47 returning by another route.
+		const landed = render(
+			searching,
+			mailViewKey(matches("/mail/$mailboxId", "sent-1")),
+			"",
+		);
+		assert.equal(landed.debounced, "invoice");
+		assert.equal(mirror(landed).url, "");
+	});
+
+	it("keeps a query the destination carries (scope chip removed)", () => {
+		// Dropping the scope chip navigates to the brief carrying the query, so
+		// the same words are searched with a wider scope.
+		const next = mirror(
+			render(searching, mailViewKey(matches("/mail/")), "invoice"),
+		);
+		assert.equal(next.field, "invoice");
+		assert.equal(next.url, "invoice");
+	});
+
+	it("never clobbers characters the user is still typing", () => {
+		// Opening a result and the q-mirror both re-render the same view. Neither
+		// is a view change, so neither may reach into the field.
+		const mailbox = mailViewKey(matches("/mail/$mailboxId", "inbox-1"));
+		let shell = typing(
+			{ ...searching, field: "", debounced: "", url: "" },
+			"i",
+		);
+		shell = mirror(render(shell, mailbox, shell.url));
+		shell = typing(shell, "inv");
+		shell = mirror(render(shell, mailbox, shell.url));
+		shell = typing(shell, "invoice");
+		shell = settle(mirror(render(shell, mailbox, shell.url)));
+		shell = mirror(render(shell, mailbox, shell.url));
+		assert.equal(shell.field, "invoice");
+		assert.equal(shell.url, "invoice");
+	});
+});

package/src/routes/mail.tsx

@@ -98,8 +98,8 @@ function MailLayout() {
 
 	// Within one view, URL `q` seeds the input and is a one-directional write
 	// target: the debounced local value drives the search API and is mirrored
-	// back. Across views the URL wins again — see the view-change effect below
-	// and `lib/search-view.ts` (#47).
+	// back. Across views the URL wins again — see the view-change adjustment
+	// below and `lib/search-view.ts` (#47).
 	const [searchInput, setSearchInput] = useState(searchQuery);
 	const debouncedSearchInput = useDebouncedValue(searchInput, 200);
 	const committedQuery = committedSearchQuery(
@@ -110,11 +110,34 @@ function MailLayout() {
 	const searchQueryRef = useRef(searchQuery);
 	searchQueryRef.current = searchQuery;
 
+	// Search is a mode of the view it was typed in, so leaving that view re-seeds
+	// the field from wherever we land (#47): empty when the sidebar dropped `q`
+	// (a folder switch starts that folder's search fresh), and the carried query
+	// when the top bar's scope chip was removed and sent the user to the brief to
+	// search everything. Views that differ only in search params — opening a
+	// result, mirroring `q` — are the same view, so in-flight typing survives
+	// them (`searchInputForView`).
+	//
+	// Adjusted during render, not in an effect. This is React's documented
+	// "adjusting state when a prop changes" pattern: both updates are to this
+	// component's own state and are guarded by a changed value, so React re-runs
+	// the render before committing and nothing is painted with the stale query.
+	// An effect would commit one frame carrying the previous view's text, which
+	// the mirror below then has to be defended against.
+	const viewKey = useRouterState({ select: (s) => mailViewKey(s.matches) });
+	const [searchViewKey, setSearchViewKey] = useState(viewKey);
+	if (searchViewKey !== viewKey) {
+		const seeded = searchInputForView(searchViewKey, viewKey, searchQuery);
+		setSearchViewKey(viewKey);
+		if (seeded !== undefined) setSearchInput(seeded);
+	}
+
 	// Mirror the settled search into the URL so links are shareable and a
 	// refresh restores the query. Within a view this is one-directional — the
 	// URL is not read back into state, so there is no sync loop — and it writes
 	// only once the debounce agrees with the field, so a query arriving by URL
-	// is never overwritten mid-debounce (`shouldMirrorQuery`).
+	// is never overwritten mid-debounce, and the query the user just left behind
+	// is never written onto the view they landed on (`shouldMirrorQuery`).
 	// When a query *goes* active, also strip selectedMessageId so the reading
 	// pane closes (#539): an open message from the pre-search list is not
 	// meaningful in the search result set. Only strip on that transition though —
@@ -147,24 +170,6 @@ function MailLayout() {
 		});
 	}, [searchInput, committedQuery, navigate]);
 
-	// Search is a mode of the view it was typed in, so leaving that view re-seeds
-	// the field from wherever we land. The nav links already drop `q` when they
-	// switch mailbox, so this clears the query instead of silently re-running it
-	// against the new mailbox (#47), while a deep link or a saved search that
-	// carries `q` still arrives searching.
-	const viewKey = useRouterState({ select: (s) => mailViewKey(s.matches) });
-	const viewKeyRef = useRef(viewKey);
-	useEffect(() => {
-		const next = searchInputForView(
-			viewKeyRef.current,
-			viewKey,
-			searchQueryRef.current,
-		);
-		viewKeyRef.current = viewKey;
-		if (next === undefined) return;
-		setSearchInput(next);
-	}, [viewKey]);
-
 	const {
 		data: config,
 		isLoading,