You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(web): opening a project from the command palette skips settled and snoozed threads - #31894
Picking a project in the command palette opens that project's latest thread, even when that thread is settled or snoozed. Settle or snooze a project's newest thread, press Cmd/Ctrl+K, type the project name and pick the project row: you land back on the thread you just parked, not the newest thread still in play.
Expected: the palette opens the newest thread in that project that is not settled or snoozed, and starts a new thread when there isn't one, as it does for an empty project.
Change
openProjectFromSearch in CommandPalette.tsx chooses the thread to open with getLatestThreadForProject (single project) or sortThreads (a project group). Its candidates already leave out archived threads, subagents and side chats (#29891). They still counted settled and snoozed threads. The handler now filters its candidates first, with the same test the delete fallback uses: settledOverride !== "settled" and !effectiveSnoozed(thread, { now }). Both the single-project and grouped branches read the filtered list. The palette's thread search results are untouched, so you can still search for and open a settled or snoozed thread by name. The Add project path for a folder that is already a project (CommandPalette.tsx, the existing-folder branch) is also left as it is: #11804 already decided how it treats a settled latest thread, and open #30353 edits it.
Scope and approval
This is the same defect #29643 fixed for deleting the open thread ("deleting the open thread no longer opens a snoozed or settled thread"). There, getFallbackThreadIdAfterDelete picks the project's next thread and now skips settled and snoozed ones. Opening a project from the palette picks the project's latest thread in the same way and still lands on one. The filter is copied from that fix, so it adds no new rule about which threads count as parked. Merged #11804 ("avoid reopening settled threads when adding projects") made the same call in this file for the Add project path. It is a small, focused fix for an obvious bug, with no new behaviour, setting or contract, so it falls under CONTRIBUTING's "very small, focused fix for an obvious bug" exception.
#30428 (this account's) extends the same test case to skip delegated tasks. The source changes merge cleanly; the test case needs a trivial rebase for whichever lands second.
Verification
I extended the existing case in apps/web/src/components/CommandPalette.browser.test.tsx ("opens a searched project's latest listed thread, not a newer subagent or parked thread"). On top of its parent thread and newer subagent, it now adds a newer settled thread and a newest thread snoozed until 2999. It opens the palette, searches "Acme", clicks the project and checks the route.
On main (test commit only), from apps/web:
vp test run src/components/CommandPalette.browser.test.tsx
× opens a searched project's latest listed thread, not a newer subagent or parked thread
AssertionError: expected '/local/snoozed' to be '/local/parent' // Object.is equality
Tests 1 failed | 2 passed (3)
With the fix:
vp test run src/components/CommandPalette.browser.test.tsx
Test Files 1 passed (1)
Tests 3 passed (3)
The one case covers both filters, because the snoozed thread is the newest and the settled thread comes next. A fix that dropped only one of them would open the other, so the test would still fail.
vp run check:changed: format, lint, knip, typecheck (2 packages), tests (4 files) and react compiler all pass.
To trigger it in the real app: in a project with at least two threads, settle the newest one (thread menu, Settle) or snooze it. Press Cmd/Ctrl+K, type the project's name and pick the project row (not a thread row). Before the fix you land on the settled or snoozed thread. With the fix you land on the newest thread that is still active, or on a new thread if every thread is parked.
In a running dev build (web, Windows), I added a git repository with two threads, "Alpha (active)" and the newer "Bravo (settled)", and settled Bravo from the sidebar. Then I pressed Ctrl+K, typed the project's name and picked the project row. The before run uses main's CommandPalette.tsx, and the after run uses this branch.
The palette, project row on top
Before (main): lands on the settled thread
After (this branch): lands on the active thread
Not checked in the running app: a snoozed thread and a project whose threads are all parked. The browser test covers the snoozed thread.
Bug: opening a project from the command palette lands on a settled or snoozed thread
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.
…d snoozed threads
Picking a project in the command palette opens that project's latest
thread. The candidates dropped archived threads, subagents and side
chats, but still counted threads the user had settled or snoozed, so a
project whose newest thread was parked opened straight back onto it.
Deleting the open thread already skips settled and snoozed threads when
it picks the next one (pingdotgg#29643). The palette now filters its candidates
the same way, settledOverride and effectiveSnoozed at the current time,
for single and grouped projects alike. When every thread is parked it
starts a new thread, as it does for an empty project.
Bug: opening a project from the command palette lands on a settled or snoozed thread
Macroscope's review found this PR requires human approval — Project opening now skips settled and snoozed threads, using the existing new-thread fallback when none remain. The changed default navigation and new react/purity lint suppression require human review.
You can add or adjust custom eligibility rules. Learn more.
Reviewing files that changed from the base of the PR and between e5edca9 and c3ed39f.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
No actionable comments were generated in the recent review.
Walkthrough
Project search now excludes settled and effectively snoozed threads before choosing the latest thread to open. Browser tests add later-message fixtures for both thread states.
Changes: Project Search Thread Selection
Layer / File(s)
Summary
Filter eligible threads and validate selection apps/web/src/components/CommandPalette.tsx, apps/web/src/components/CommandPalette.browser.test.tsx
openProjectFromSearch filters settled and effectively snoozed threads for grouped-project and individual-project searches. Browser test fixtures cover settled and snoozed threads with later message dates.
Opening a project from the command palette now skips settled and snoozed threads and starts a new thread when none are eligible. The change is small, localized and covered by a browser test, so merge risk is low.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the primary change: the command palette's project-open action now skips settled and snoozed threads. It uses the repository's conventional commit form (fix(web): ...) and matches the c…
Description check
The description follows the template well. It has Problem, Change, Scope and approval, and Verification sections. The problem is stated with expected behavior and reproduction steps. The change explai…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Title check
Explanation
The title names the primary change: the command palette's project-open action now skips settled and snoozed threads. It uses the repository's conventional commit form (fix(web): ...) and matches the code change in openProjectFromSearch and the browser test.
Full details: Description check
Explanation
The description follows the template well. It has Problem, Change, Scope and approval, and Verification sections. The problem is stated with expected behavior and reproduction steps. The change explains the filter and why the Add project path is untouched. The scope links the related issues and PRs and explains the small-fix rationale. Verification gives concrete test commands, before and after results, and manual repro with screenshots. The template's closing request to name the model and harness is answered by the 'written with Claude Opus 5.5 in Claude Code' line. One gap: the Scope section cites a bug issue (#29643 and #11804 are referenced as precedents), but no issue is linked as the bug report. The author says the change needs no issue, which the template allows for small obvious fixes. The Verification section also says the snoozed and all-parked cases were not checked in the running app, which is disclosed.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.
Environment: Linux web client, Chromium, 1280×800, light theme, fresh synthetic data and replay provider on each commit.
Create Alpha, then Bravo in acme-demo. Settle Bravo; press Ctrl+K, search acme-demo, and select its Projects row. Un-settle Bravo, open Alpha, snooze Bravo until Tomorrow 9:00 AM, then select the same project result again.
Proven: the scenario fails on base and passes on head. Base opens Bravo in both cases; head opens Alpha.
Real Chromium web client, 1280×800, light theme, fresh synthetic data and replay-agent threads on both commits. Created Alpha then Bravo in acme-demo. Selected the project result through Ctrl+K after settling Bravo, after un-settling and snoozing Bravo until Tomorrow, and after also settling Alpha.
Scenario source. Final scenarios:prove run exited 0: failed on base, passed on head.
Not shown:
Alternate configured thread sort orders, grouped projects, and expired or turn-based snoozes were not exercised; this reproduction used the default order and Tomorrow snooze.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:S10-29 changed lines (additions + deletions).vouch:unvouchedAuthor is not yet trusted in the VOUCHED list.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:unvouched
juliusmarminge
added
the
takeover:in-progress
Problem
Picking a project in the command palette opens that project's latest thread, even when that thread is settled or snoozed. Settle or snooze a project's newest thread, press Cmd/Ctrl+K, type the project name and pick the project row: you land back on the thread you just parked, not the newest thread still in play.
Expected: the palette opens the newest thread in that project that is not settled or snoozed, and starts a new thread when there isn't one, as it does for an empty project.
Change
openProjectFromSearchinCommandPalette.tsxchooses the thread to open withgetLatestThreadForProject(single project) orsortThreads(a project group). Its candidates already leave out archived threads, subagents and side chats (#29891). They still counted settled and snoozed threads. The handler now filters its candidates first, with the same test the delete fallback uses:settledOverride !== "settled"and!effectiveSnoozed(thread, { now }). Both the single-project and grouped branches read the filtered list. The palette's thread search results are untouched, so you can still search for and open a settled or snoozed thread by name. The Add project path for a folder that is already a project (CommandPalette.tsx, the existing-folder branch) is also left as it is: #11804 already decided how it treats a settled latest thread, and open #30353 edits it.Scope and approval
This is the same defect #29643 fixed for deleting the open thread ("deleting the open thread no longer opens a snoozed or settled thread"). There,
getFallbackThreadIdAfterDeletepicks the project's next thread and now skips settled and snoozed ones. Opening a project from the palette picks the project's latest thread in the same way and still lands on one. The filter is copied from that fix, so it adds no new rule about which threads count as parked. Merged #11804 ("avoid reopening settled threads when adding projects") made the same call in this file for the Add project path. It is a small, focused fix for an obvious bug, with no new behaviour, setting or contract, so it falls under CONTRIBUTING's "very small, focused fix for an obvious bug" exception.#30428 (this account's) extends the same test case to skip delegated tasks. The source changes merge cleanly; the test case needs a trivial rebase for whichever lands second.
Verification
I extended the existing case in
apps/web/src/components/CommandPalette.browser.test.tsx("opens a searched project's latest listed thread, not a newer subagent or parked thread"). On top of its parent thread and newer subagent, it now adds a newer settled thread and a newest thread snoozed until 2999. It opens the palette, searches "Acme", clicks the project and checks the route.On
main(test commit only), fromapps/web:With the fix:
The one case covers both filters, because the snoozed thread is the newest and the settled thread comes next. A fix that dropped only one of them would open the other, so the test would still fail.
vp run check:changed: format, lint, knip, typecheck (2 packages), tests (4 files) and react compiler all pass.To trigger it in the real app: in a project with at least two threads, settle the newest one (thread menu, Settle) or snooze it. Press Cmd/Ctrl+K, type the project's name and pick the project row (not a thread row). Before the fix you land on the settled or snoozed thread. With the fix you land on the newest thread that is still active, or on a new thread if every thread is parked.
In a running dev build (web, Windows), I added a git repository with two threads, "Alpha (active)" and the newer "Bravo (settled)", and settled Bravo from the sidebar. Then I pressed Ctrl+K, typed the project's name and picked the project row. The before run uses
main'sCommandPalette.tsx, and the after run uses this branch.main): lands on the settled threadNot checked in the running app: a snoozed thread and a project whose threads are all parked. The browser test covers the snoozed thread.
Bug: opening a project from the command palette lands on a settled or snoozed thread
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.