fix(web): move the new thread button under the project selector - #13
Merged
Merged
Conversation
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
There was a problem hiding this comment.
Pull request overview
Moves the web sidebar’s new-thread action below the project selector and makes it respect the selected project scope.
Changes:
- Adds a full-width, scope-aware New thread button.
- Introduces and tests pure click-target resolution logic.
- Documents the behavior and fork-specific change.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
FORK.md |
Records the fork-specific sidebar change. |
docs/user/thread-sidebar.md |
Documents scoped thread creation. |
apps/web/src/components/Sidebar.tsx |
Moves the button and wires scoped behavior. |
apps/web/src/components/Sidebar.logic.ts |
Adds click-target resolution. |
apps/web/src/components/Sidebar.logic.test.ts |
Tests scoped and unscoped outcomes. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The sidebar header put the new thread button on the search row, above the project selector that gives it its context, while the new project button sat beside that selector. The two create affordances read as unrelated and the new thread one was a bare glyph next to a text field. It now renders below the project row as a full-width button with the icon and a "New thread" label centered, so the header reads search, then scope, then act. It also follows the scope: with a project selected it creates there immediately instead of asking again, and "All projects" keeps the old behavior (create in the current project when there is nothing to pick or shift is held, otherwise open the picker). Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013e7h5QSeFxpr6YSgXrynn7
…by surface The comment above the click-target resolution still claimed shift+click always creates in the current project; a selected scope now wins over it. The new "Starting a thread" doc section also described the layout as universal, but mobile and the original sidebar are unchanged. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013e7h5QSeFxpr6YSgXrynn7
jmclaren7
force-pushed
the
claude/thread-button-positioning-bt4gba
branch
from
August 22, 2026 06:58
7c0dd16 to
0a73055
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What Changed
The sidebar header's new thread button moves out of the search row and down below the project row, where it renders as a full-width button — the pencil icon plus a New thread label, content centered. The search row keeps only the search box; the new project button stays where it was, beside the project selector.
The button is now scope-aware, following the selector directly above it:
The branch lives in a pure helper,
resolveNewThreadClickTarget, which delegates the unscoped case to the existingshouldCreateNewThreadInCurrentProject, so the old rule is untouched. The scoped target resolves throughbuildSidebarProjectPickerEntries— the same entry builder the palette picker uses — so a grouped project (several checkouts of one repo) lands on the same member either way.Two smaller consequences: the scoped tooltip names the project ("New thread in Foo") and drops the shortcut, because
chat.newis not scope-aware and would promise the wrong target; and the button no longer rendersdisabledwhen there are no projects, since it now renders with the project row, which is already hidden in that state (the list's "No projects yet → Add project" empty state remains the way in).FORK.mdgains entry 18 recording the intent (17 ismain's configurable worktree branch prefix), anddocs/user/thread-sidebar.mdgains a short "Starting a thread" section.Why
The header stacked its controls against the reading order. Row one was the thread search box with an icon-only new thread button pinned to its right; row two was the project scope menu with the new project button pinned to its right. The two "create" affordances sat on different rows, the new thread one above the project selector that gives it its context, and it was a bare glyph next to a text field it has nothing to do with. Reading order is now search → scope → act.
Behaviorally, the button also ignored the scope menu directly beneath it: with several projects a plain click always opened the picker, even when the sidebar was already scoped to one project and the answer was on screen.
UI Changes
No before/after screenshots — this was implemented in a headless remote session with no browser. The change is a header re-stack plus one label; it wants a look in a real client before merge.
Checklist
Verification
vp test run apps/web/src/components/Sidebar.logic.test.ts— 110 passed, 5 of them new (scoped target wins at any project count and on shift+click; picker from "All projects" with several projects; both unscoped direct-create cases)tsgo --noEmitclean inapps/webvp fmt --checkclean repo-wide;vp lintclean on the touched filesNot touched:
LegacySidebar.tsx(opt-in legacy layout, different header), the mobile home header, and thechat.new/chat.newLocalkeybindings.History note
This branch briefly carried a merge of
main, whoseFORK.mdconflict resolution left two entries numbered 17. The branch has since been rebased ontomainand is linear again: the merge commit and the follow-up that repaired it are both gone, and the entry-18 renumbering is folded into the first commit. The rebased tree is byte-identical to the pre-rebase one (same tree hash), so nothing was lost — only the shape of the history changed.