feat(autoresearch): improve new-task composer controls (GROW-124)#3205
Conversation
Move the Autoresearch toggle into the agent-mode dropdown as its last
item; arming it defaults the mode to bypassPermissions (or acceptEdits)
so the unattended loop isn't blocked on permission prompts.
Move the target/iterations controls out of the composer InputGroup —
whose click handler refocused the editor on every click, stealing focus
from the inputs — into a bar between the dropdown row and the input.
Rewrite that bar to read as a sentence ("Optimize to maximize until it
reaches N or after K iterations using <model>") with per-label tooltips,
replacing the unlabeled Maximize / Target / <= controls.
Feature-flag gating (autoresearchEnabled) is preserved on both the
dropdown toggle and the controls bar.
Generated-By: PostHog Code
Task-Id: 14b7baf0-7253-47ec-96a5-110520071729
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
|
Reviews (1): Last reviewed commit: "feat(autoresearch): improve new-task com..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // The loop iterates unattended, so a permission prompt would stall it. | ||
| // Default to the most hands-off mode available: bypass when the user has | ||
| // enabled it, otherwise accept-edits. | ||
| const autonomousMode = allowBypassPermissions | ||
| ? "bypassPermissions" | ||
| : "acceptEdits"; | ||
| if (modeOption && isValidConfigValue(modeOption, autonomousMode)) { | ||
| setConfigOption(modeOption.id, autonomousMode); | ||
| } |
There was a problem hiding this comment.
When arming autoresearch, setConfigOption overrides the user's selected mode with bypassPermissions or acceptEdits. The early-return branch on disarm (store.clearDraft → return) never calls setConfigOption to restore the original mode. A user who was in "Plan" mode will be left in "Accept Edits" after the autoresearch cycle ends without any automatic restore — they have to notice the mode button changed and fix it manually.
| {autoresearch && ( | ||
| <> | ||
| <DropdownMenuSeparator /> | ||
| <DropdownMenuCheckboxItem | ||
| checked={autoresearch.active} | ||
| onCheckedChange={() => { | ||
| pendingAutoresearchRef.current = true; | ||
| setOpen(false); | ||
| }} | ||
| > | ||
| <span className="text-violet-11"> | ||
| <ChartLineUp size={12} /> | ||
| </span> | ||
| <span className="whitespace-nowrap">Autoresearch</span> | ||
| </DropdownMenuCheckboxItem> | ||
| </> | ||
| )} |
There was a problem hiding this comment.
checked visual state can lag behind onCheckedChange resolution
onCheckedChange sets pendingAutoresearchRef.current = true and calls setOpen(false), but the actual store update (and thus the new value of autoresearch.active) only fires during onOpenChangeComplete after the menu's close animation ends. If Radix UI optimistically flips the checkbox's visual checked state inside onCheckedChange, it will momentarily disagree with the checked={autoresearch.active} prop until the animation completes. In practice the menu closes immediately so the user may never see the inconsistency, but it's worth verifying Radix's DropdownMenuCheckboxItem doesn't eagerly render the toggled state before the controlled prop catches up.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
…124) Add two product-analytics events for autoresearch mode usage: - "Autoresearch armed" — fired when the mode is turned on from the agent-mode dropdown (default_mode, workspace_mode). - "Autoresearch run started" — fired when an armed task is submitted (direction, has_target, max_iterations, stages_split, per-stage model/effort, workspace_mode). Both fire only through the feature-flag-gated arm/submit paths, so no events emit when autoresearch is disabled. Generated-By: PostHog Code Task-Id: 14b7baf0-7253-47ec-96a5-110520071729
|
Added product-analytics instrumentation for autoresearch usage (commit 4319801). Two events (defined in
Together they give an arm → run funnel. Properties are compile-time-checked via Both fire only through the feature-flag-gated arm/submit paths, so nothing emits when autoresearch is disabled. |
2 participants
What
Polish pass on the autoresearch mode in the new-task composer (follow-up to the autoresearch feature, GROW-103).
1. Autoresearch moved into the agent-mode dropdown
bypassPermissionswhen the user has it enabled, otherwiseacceptEdits— since an unattended iteration loop would stall on permission prompts.2. Fixed the target/iterations inputs stealing focus on click
InputGroup, whose click handler refocuses the editor on any non-button click, so clicking an input bounced focus straight to the prompt.3. Controls moved outside the input box
4. Controls rewritten to be self-explanatory
Maximize, an unlabeledTargetbox, a stray≤ 10 iterations, and aClaude Opus 4.8 · Maxline that didn't look clickable.maximizeuntil it reaches[optional]or after[10]iterations using[model]— with a tooltip on each label and an explainer on the Autoresearch chip. Tooltips wrap only plain label spans (never the inputs) to avoid reintroducing focus flicker.Feature-flag gating
Both new surfaces stay behind
useAutoresearchEnabled()(staff-gated flag; always on in dev):PromptInput/ModeSelectoronly whenautoresearchService && autoresearchEnabled.autoresearchDraftis set, which is forcednullwhile the flag is off.ModeSelectorandPromptInputstay flag-agnostic; the gate lives solely inTaskInput.Files
packages/ui/src/features/message-editor/components/ModeSelector.tsxpackages/ui/src/features/message-editor/components/PromptInput.tsxpackages/ui/src/features/task-detail/components/TaskInput.tsxpackages/ui/src/features/autoresearch/AutoresearchComposerControls.tsxTesting
pnpm typecheck(full monorepo, 22/22) and Biome lint pass on all changed files.Fixes GROW-124
Created with PostHog Code