Problem or Motivation
The settings navigator (SettingsNavigator) renders a flat, ever-growing list
of settings sections (General, Appearance, App, AI, Input, Shortcuts, Memory,
MCP Servers, Hooks, Extensions, Permissions, Labels, Messaging, Server,
Workspace, Preferences — 16 sections today). There is no way to filter it.
Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all ship a
search box at the top of their settings so users can jump to a setting by
typing part of its name instead of scanning the whole list. OpenWork's session
list, sources list, model picker, and tools list already have search affordances
— settings is the conspicuous exception.
Proposed Solution
Add a search box at the top of SettingsNavigator that filters the section list
by title and description (case-insensitive, substring). It mirrors the
existing SessionSearchHeader styling (search icon, clear button, focus ring)
for visual consistency, shows a "No results found" empty state when nothing
matches, and supports Esc to clear.
This is a frontend-only change:
SettingsNavigator already has all section metadata (SETTINGS_ITEMS,
resolved labels/descriptions) in the renderer. Filtering is pure client-side
React state — no backend, no qwen-code change.
- Reuses existing i18n keys (
common.search, common.noResultsFound), so no
new locale strings are introduced.
Alternatives Considered
- Command-palette navigation already exists, but it is a separate global
surface; users in the settings panel expect to filter the list they are
looking at, the way every comparable app does.
Additional Context
Feasibility: frontend-only / doable. Verified against apps/electron and
packages/ui — the navigator is a pure renderer component and the data it
needs is already in memory.
Acceptance criteria (CDP e2e assertion)
A new e2e/assertions/settings-search.assert.ts drives the real built app over
CDP and asserts the full path:
- Open Settings from the sidebar; the search box renders and the section
list shows more than one row.
- Typing the first section's title narrows the list to exactly the predicted
matches, every visible row actually contains the query, and the list shrinks.
- A no-match query (
zzqqxxnomatchzzqqxx) shows the empty state and hides every
row.
- Clearing the query restores the full list.
Part of the autonomous desktop-feature loop (loop-bot).
Problem or Motivation
The settings navigator (
SettingsNavigator) renders a flat, ever-growing listof settings sections (General, Appearance, App, AI, Input, Shortcuts, Memory,
MCP Servers, Hooks, Extensions, Permissions, Labels, Messaging, Server,
Workspace, Preferences — 16 sections today). There is no way to filter it.
Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all ship a
search box at the top of their settings so users can jump to a setting by
typing part of its name instead of scanning the whole list. OpenWork's session
list, sources list, model picker, and tools list already have search affordances
— settings is the conspicuous exception.
Proposed Solution
Add a search box at the top of
SettingsNavigatorthat filters the section listby title and description (case-insensitive, substring). It mirrors the
existing
SessionSearchHeaderstyling (search icon, clear button, focus ring)for visual consistency, shows a "No results found" empty state when nothing
matches, and supports
Escto clear.This is a frontend-only change:
SettingsNavigatoralready has all section metadata (SETTINGS_ITEMS,resolved labels/descriptions) in the renderer. Filtering is pure client-side
React state — no backend, no qwen-code change.
common.search,common.noResultsFound), so nonew locale strings are introduced.
Alternatives Considered
surface; users in the settings panel expect to filter the list they are
looking at, the way every comparable app does.
Additional Context
Feasibility: frontend-only / doable. Verified against
apps/electronandpackages/ui— the navigator is a pure renderer component and the data itneeds is already in memory.
Acceptance criteria (CDP e2e assertion)
A new
e2e/assertions/settings-search.assert.tsdrives the real built app overCDP and asserts the full path:
list shows more than one row.
matches, every visible row actually contains the query, and the list shrinks.
zzqqxxnomatchzzqqxx) shows the empty state and hides everyrow.
Part of the autonomous desktop-feature loop (
loop-bot).