feat(app): add project search to command palette

[mguttmann]

Summary

Extends the Cmd+P / Ctrl+P command palette to include project search alongside the existing commands, files, and sessions.

Closes #11843

What changed

• Projects: Shows all open projects with colored avatar, name, and worktree path. Selecting navigates to the project.
• Results are grouped by category and filtered via fuzzysort.
• i18n key palette.group.projects added to all 15 language files with native translations.
• New setting palette.projects (default: true) to toggle project visibility in the palette.

Note: Session search was originally part of this PR but has since been added upstream. This PR has been rebased and narrowed to only add the project search functionality that is still missing from dev.

Files changed

• packages/app/src/components/dialog-select-file.tsx — Added projectItem, projectList, projectLookup, projects memo, project handling in handleSelect, project Avatar rendering
• packages/app/src/components/settings-general.tsx — Added toggle UI for "Show projects in command palette"
• packages/app/src/context/settings.tsx — Added palette.projects setting (boolean, default true)
• All 15 packages/app/src/i18n/*.ts files — Added palette.group.projects, settings.palette.projects, settings.palette.projects.description

Implementation notes

• Projects sourced from layout.projects.list() (reactive)
• server.projects.touch() is called before project navigation to update last-used tracking
• Fully compatible with the session search that is now in dev

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[mguttmann]

[alexyaroshuk]

seems good, the only concern i would have is the clutterness of the command pallete. with this, it would become less focused as we are now searching for everything, while the original goal of pallette is actions for current project (hence the placeholder 'search for commands and files')

[alexyaroshuk]

seems good, the only concern i would have is the clutterness of the command pallete. with this, it would become less focused as we are now searching for everything, while the original goal of pallette is actions for current project (hence the placeholder 'search for commands and files')

perhaps limiting sessions/projects to say max 5 would address this. i do not see limiting in your description nor in the code. for ex. say you have 10 projects that have 'opencode' in the name or 10 sessions that have 'opencode' in the name, the pallete would only show 5 at most for each type when searching 'opencode'

[mguttmann]

Thanks for the feedback @alexyaroshuk! I appreciate the concern about clutter.

However, I'd push back a bit on a hard limit of 5 per category — the main question would be: which 5? How do we rank them?

• By most recently used? Then you'd never find older projects by name.
• Alphabetically? Then you'd miss the one starting with "z" if 5 others match first.
• By fuzzy match score? That's already what fuzzysort does — the best matches float to the top naturally.

The core problem a limit creates: if what you're looking for is result #7 or #11, you simply can't find it. That defeats the purpose of having search in the first place — especially for users like the one in #9088 who has 200+ projects and needs exactly this kind of unrestricted search to navigate efficiently.

The palette already handles this well IMO — results are grouped by category, so it's visually clear what's what, and if your query is specific enough (2-3 characters), you'll typically see only a handful of matches anyway. The "clutter" only appears with very short/generic queries, where showing more results is actually helpful.

That said, I'm open to discussing this further — what do you think about keeping it unlimited but maybe deprioritizing projects/sessions so they appear below commands and files in the result list? That way the "current project" focus stays intact while still allowing full search.

[alexyaroshuk]

Thanks for the feedback @alexyaroshuk! I appreciate the concern about clutter.

However, I'd push back a bit on a hard limit of 5 per category — the main question would be: which 5? How do we rank them?

• By most recently used? Then you'd never find older projects by name.
• Alphabetically? Then you'd miss the one starting with "z" if 5 others match first.
• By fuzzy match score? That's already what fuzzysort does — the best matches float to the top naturally.

The core problem a limit creates: if what you're looking for is result #7 or #11, you simply can't find it. That defeats the purpose of having search in the first place — especially for users like the one in #9088 who has 200+ projects and needs exactly this kind of unrestricted search to navigate efficiently.

The palette already handles this well IMO — results are grouped by category, so it's visually clear what's what, and if your query is specific enough (2-3 characters), you'll typically see only a handful of matches anyway. The "clutter" only appears with very short/generic queries, where showing more results is actually helpful.

That said, I'm open to discussing this further — what do you think about keeping it unlimited but maybe deprioritizing projects/sessions so they appear below commands and files in the result list? That way the "current project" focus stays intact while still allowing full search.

good points, maybe one way is to have an option for this in the settings. show/hide prohjects / settings in cmd pallete. That way, user can customize.

[mguttmann]

Hey, I really like the settings toggle idea — it's a great compromise that gives users full control without forcing a one-size-fits-all approach.

I've implemented it: there are now two toggles in Settings → General → Desktop:

• Show projects in command palette — toggles whether projects appear in Cmd+P results
• Show sessions in command palette — toggles whether sessions appear in Cmd+P results

Both default to enabled, so the feature works out of the box for users who want it. But anyone who prefers a more focused palette can simply disable one or both — no clutter, no forced limit.

I also fixed the group ordering so that Projects always appear above Sessions in the results (before, fuzzysort could reorder groups based on match quality, which was confusing). The fixed order is now: Projects → Sessions → Commands → Files.

This way everyone gets exactly the palette experience they want. Let me know what you think!

[mguttmann]

[stenci]

I don’t like the hard limit of 5. Either a category is visible or it isn’t.

Projects names are short, most users have only a handful, and they won’t hit any limit anyway. The users who do have many projects are exactly the ones who want to see all of them.

Sessions are different. They tend to be more numerous, have longer names, and could generate clutter more easily.

The Ctrl+P palette in OpenCode reminds me of PyCharm’s Search Everywhere feature (invoked with Double Shift). In PyCharm this is a single unified palette that:

• Uses fuzzy matching and relevance sorting so the best results surface first.
• Groups results by category.
• Provides category filters at the top (All, Files, Classes, Symbols, Actions) so the user explicitly controls what is shown.

PyCharm also exposes the same palette through dedicated shortcuts that open it with a specific category already selected:

• Double Shift -> Search Everywhere (All)
• Ctrl+Shift+N -> Files
• Ctrl+N -> Classes
• Ctrl+Alt+Shift+N -> Symbols
• Ctrl+Shift+A -> Actions

OpenCode could follow the same principle: show everything by default, let users filter by category, and optionally allow shortcuts that open the same palette with a category pre-selected.

[mguttmann]

Thanks for the thoughtful comparison with PyCharm's Search Everywhere, @stenci — really good points.

Fully agree on the no-hard-limit approach. That's exactly what we went with: two settings toggles (show projects / show sessions in the palette), both enabled by default. Either a category is visible or it isn't, no arbitrary cutoff.

The category filter tabs and dedicated shortcuts per category are interesting ideas. Technically not hard to add, but I'd want to be careful about overloading the palette — right now it's clean and fast, and I'd hate to clutter it with extra UI chrome that most users won't need. The settings toggles already cover the "I don't want to see X" use case without adding visual noise.

That said, if more people feel strongly about inline category filters or per-category shortcuts, I'm open to revisiting it. For now I'd rather keep it focused and iterate based on feedback.

[stenci]

Just to make sure I understand the current behavior correctly:

• This PR adds results to the existing palette.
• Today the palette shows results grouped by category, with headers (Commands first, then Files).
• This PR adds two more categories: Projects and Sessions, each with their own matches.
• There are settings to enable/disable the two new categories.

If any of the above is incorrect, feel free to ignore the rest. If it’s correct, here’s my opinion.

Since results are already grouped by category and always shown in a fixed order (Commands, Files, Projects, Sessions), I don’t think users will complain about having two additional categories below. Because of that, keeping the new categories enabled by default seems reasonable.

Adding filters à la PyCharm on top of the current grouped layout doesn’t add much value by itself: it mostly just scrolls you to the relevant section.

My ideal solution would be closer to PyCharm’s Search Everywhere: no category headers, results fully intermixed, and icons used to distinguish commands, files, projects, sessions, etc. That way the best match is always at the top, regardless of category, and users never need to scroll just to reach “their” section.

In that intermixed-results scenario, category filters would make sense, because matches from other categories could dominate the top results and push down relevant matches from the category the user is actually looking for.

That said, I understand this PR isn’t about redesigning the palette behavior, only about adding two new result types. Given that constraint, the current approach is probably as good as it can be.

This is how the OpenCode palette looks now:

And this is how it could look like with intermixed categories:

For reference, this the Search Everywhere in PyCharm, showing intermixed results:

[mguttmann]

Thanks for the detailed writeup and the mockups, @stenci — really appreciate the effort!

I think you nailed it with your summary: this PR is about adding two new result types to the existing palette, not redesigning it. The current grouped approach with optional settings toggles works well for that scope.

The PyCharm-style intermixed results with category filters is an interesting direction for the future. I personally don't use PyCharm, so I can't speak to how it feels in practice, but I can see the appeal of "best match always on top regardless of category." That said, I'm honestly pretty happy with how the current solution works — the fixed group ordering (Projects → Sessions → Commands → Files) keeps things predictable, and the settings toggles give users full control.

If there's demand for a more advanced palette in the future, that would make a great standalone PR. For now I think we're in a good place here.

[stenci]

I have noticed that last release does include sessions in the palette.
I hope it doesn't mean that this PR will be disregarded as duplicated ☹️

[mguttmann]

Good eye! Yes, session search was added upstream in the latest release — this PR originally included both project and session search.

I've rebased and narrowed the scope: this PR now only adds project search, which is still missing from dev. The session parts have been removed since they'd be a duplicate. Updated the title and description accordingly.

So no duplication — this PR is complementary to what's already in dev. 🙂

Regarding your intermixed-results idea — I agree that would be the ideal long-term UX. For now this follows the existing grouped pattern to keep the diff minimal, but that's a great evolution path for the palette overall.