Skip to content

Add searchable filtering to the settings navigator - #40

Merged
DragonnZhang merged 2 commits into
mainfrom
loop/settings-search
Jul 1, 2026
Merged

Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom
loop/settings-search

Conversation

@DragonnZhang

@DragonnZhangDragonnZhang commented Jun 30, 2026

Copy link
Copy Markdown
Member

Closes#39

What & why

The settings navigator rendered a flat, unfilterable list of 16 sections
(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,
Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).
Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let
you search settings; OpenWork's session list, sources list, model picker and
tools list already have search, so settings was the conspicuous gap.

This adds a search box at the top of SettingsNavigator that filters sections
by title + description (case-insensitive substring), with:

  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.

Frontend-only — the navigator already holds all section metadata in the
renderer, so filtering is pure React state. No backend / qwen-code change.
Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.

Changes

  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    headless: each launch gets its own profile dir (keyed on the unique debug
    port), and on headless Linux the app launches under setsid so teardown
    reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    the single-instance lock and the second assertion's launch could never find a
    renderer target.

Verification (DoD)

  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens
Settings from the sidebar, types the first section's title and asserts the list
narrows to exactly the predicted matches (every visible row contains the query
and the list shrinks), types a no-match query and asserts the empty state with
zero rows, then clears and asserts the full list is restored.

🤖 Generated with Claude Code

Generated by Claude Code

@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang merged commit 36bac52 into mainJul 1, 2026
1 check passed
This was referenced Jul 5, 2026
Closed
Merged
@yiliang114yiliang114 mentioned this pull request Aug 6, 2026
Open
40 tasks
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

loop-bot

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation

2 participants

@DragonnZhang@claude
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Add searchable filtering to the settings navigator by DragonnZhang · Pull Request #40 · modelstudioai/openwork · GitHub
Skip to content
Add searchable filtering to the settings navigator - #40
Merged
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Jul 1, 2026
Merged
Add searchable filtering to the settings navigator#40
DragonnZhang merged 2 commits into
mainfrom 
loop/settings-search
Conversation
@DragonnZhang
@DragonnZhangDragonnZhang
commented
Jun 30, 2026

Copy link


Copy Markdown

Member
Closes#39
What & why
The settings navigator rendered a flat, unfilterable list of 16 sections

(General, Appearance, App, AI, Input, Shortcuts, Memory, MCP Servers, Hooks,

Extensions, Permissions, Labels, Messaging, Server, Workspace, Preferences).

Comparable desktop apps (Claude Code Desktop, VS Code, Codex desktop) all let

you search settings; OpenWork's session list, sources list, model picker and

tools list already have search, so settings was the conspicuous gap.
This adds a search box at the top of SettingsNavigator that filters sections

by title + description (case-insensitive substring), with:
  • the existing session-search styling (search icon, clear button, focus ring),
  • a "No results found" empty state,
  • Esc to clear.
Frontend-only — the navigator already holds all section metadata in the

renderer, so filtering is pure React state. No backend / qwen-code change.

Reuses the existing common.search and common.noResultsFound i18n keys, so
no locale strings are added or reordered.
Changes
  • SettingsNavigator.tsx — search box + client-side filter + empty state.
  • LeftSidebar.tsx — emit data-testid={link.id} on nav buttons so the
    
Settings entry point is addressable from e2e (per the harness README's "add a
    data-testid in the same PR" guidance).
  • e2e/assertions/settings-search.assert.ts — new CDP assertion (below).
  • e2e/app.ts — harness robustness so more than one assertion can run
    
headless: each launch gets its own profile dir (keyed on the unique debug
    
port), and on headless Linux the app launches under setsid so teardown
    
reaps the whole xvfb-run tree. Previously a lingering Electron instance held
    
the single-instance lock and the second assertion's launch could never find a
    
renderer target.
Verification (DoD)
  • bun run typecheck:all — ✅ passes.
  • bun test — no new failures vs. main (the repo has pre-existing, unrelated
    
failures — e.g. BrowserCDP, BrowserPaneManager, i18n locale parity
    sorted checks; this change introduces none and touches none of them).
  • Electron build — ✅ (electron:build).
  • App boots — ✅ (app-boots assertion).
  • Feature CDP assertion — ✅ 2/2 passed:
🧪 Running 2 e2e assertion(s)
• app boots and main window renders ... ✅ (2599ms)
• settings navigator search filters sections ... ✅ (2924ms)
✅ 2/2 passed

The settings-search assertion drives the real built app over CDP: opens

Settings from the sidebar, types the first section's title and asserts the list

narrows to exactly the predicted matches (every visible row contains the query

and the list shrinks), types a no-match query and asserts the empty state with

zero rows, then clears and asserts the full list is restored.
🤖 Generated with Claude Code
Generated by Claude Code
@claude
Add searchable filtering to the settings navigator
adb8522
The settings navigator rendered a flat, unfilterable list of 16 sections.
Add a search box at the top that filters sections by title and description
(case-insensitive substring), mirroring the existing session-list search
styling — search icon, clear button, focus ring, Esc-to-clear, and a
"No results found" empty state. This matches the searchable-settings
affordance in comparable desktop apps.
Implementation is frontend-only and reuses existing i18n keys
(common.search, common.noResultsFound), so no locale strings change.
Also:
- LeftSidebar: emit data-testid={link.id} on nav buttons so the settings
entry point (and other nav items) are addressable from e2e.
- e2e/app.ts: give each launch its own profile dir (keyed on the debug
port) and launch under setsid on headless Linux so teardown reaps the
whole xvfb-run tree. Without this, a lingering Electron instance held
the single-instance lock and the next assertion could never get a
renderer target — which blocked running more than one CDP assertion.
- e2e/assertions/settings-search.assert.ts: drives the real app over CDP
to verify the filter narrows, shows the empty state, and restores.
@DragonnZhang
DragonnZhang
merged commit 36bac52
into
mainJul 1, 2026

1 check passed


This was referenced Jul 5, 2026

Closed

 Merged

@yiliang114yiliang114
mentioned this pull request
Aug 6, 2026

Open

40 tasks
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels

loop-bot

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

Searchable/filterable settings navigation


2 participants

@DragonnZhang@claude