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
Start a new thread from a pull request's menu, including a local review
#20826
From inside a thread, the pull request detail menu's agent actions can only reach that thread. Ask a question, Explain this PR and Fix findings in this thread all write into the current thread's composer. There is no way to send one of them to a new thread instead.
That rules out a common maintainer task: pulling a pull request down and reviewing it locally in its own thread. Check out › In a separate worktree does open a new thread on the PR branch, but with an empty composer. The user then writes the review prompt by hand each time. The menu has no review action at all.
Proposal
Hold a key to send an action to a new thread. While the menu is open inside a thread, holding Option on macOS changes the agent actions' labels live: "Ask in a new thread", "Explain in a new thread", "Review in a new worktree", "Fix findings in a new worktree". Choosing one with the key held starts a new thread instead of writing into the current one. On Windows and Linux the key is Ctrl, the "open in a new tab" habit. Alt would collide with the window menu bar. A muted line in the menu says "Hold ⌥ to start a new thread instead", so the behaviour can be found.
Add Review this PR. A preset next to Explain: read the diff, run the tests that cover the changed code, and report findings by severity with file and line. It does not push, comment or approve. Like the other hand-offs, the prompt goes into the composer for the user to read before sending.
Each action decides whether it needs a checkout. In a new thread, Review and Fix findings open in a worktree, while Ask and Explain don't check anything out. The key only picks the destination, so the menu never asks a third question.
Outside a thread, these actions already open a new thread. The labels stay as they are and the hint is hidden.
The app already uses this pattern: holding ⌘/Ctrl changes the composer's send button mode and label, and holding Shift turns on the PR list's quick actions. Both read the shared useShortcutModifierState hook.
Surfaces
Web and desktop share the menu.
Mobile and touch have no held key, so they need a visible entry, such as a "Start a new thread" option in the mobile PR menu.
Providers are unaffected. These are composer hand-offs, not provider features.
Alternatives considered
A "Start a new thread ›" submenu with Review, Explain and Ask presets. It is visible, but it shows each action twice.
A "Send to" radio group in the menu (this thread / new thread / new worktree). It reuses the menu's environment-picker pattern, but a sticky radio choice in an action menu is surprising.
A "▾" on each item for "in a new thread". It is visible on every surface, but it adds a second control to each row, and Base UI menus don't handle a button inside a menu item cleanly.
Related
#15721 (open bug): threads created from a PR checkout aren't linked to the PR. The new-thread path should record the link, or the review thread won't appear as the PR's thread.
#16824 proposes an agent review with grouped files started from the PR view. This is the simpler, prompt-only version.
#17224 (open PR) adds a watch item to the same menu.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem
From inside a thread, the pull request detail menu's agent actions can only reach that thread. Ask a question, Explain this PR and Fix findings in this thread all write into the current thread's composer. There is no way to send one of them to a new thread instead.
That rules out a common maintainer task: pulling a pull request down and reviewing it locally in its own thread. Check out › In a separate worktree does open a new thread on the PR branch, but with an empty composer. The user then writes the review prompt by hand each time. The menu has no review action at all.
Proposal
Outside a thread, these actions already open a new thread. The labels stay as they are and the hint is hidden.
The app already uses this pattern: holding ⌘/Ctrl changes the composer's send button mode and label, and holding Shift turns on the PR list's quick actions. Both read the shared
useShortcutModifierStatehook.Surfaces
Alternatives considered
Related
Happy to implement this if the direction works.
🤖 Claude Opus 5.5
All reactions