feat(settings): make auto-inferred task names toggleable

[singhvibhanshu]

Summary

This PR introduces a user setting to toggle the auto-inferred task naming feature (originally from #1033) on and off.

By default, the setting is OFF (autoInferTaskNames: false), meaning task names will instantly generate using the standard random name generator, providing a zero-latency experience. When toggled ON, the application will use the conversation context to auto-infer the task name after the initial prompt.

The new toggle is located in the General Settings tab (AutoInferTaskNamesRow), and the logic gates the existing generateTaskNameFromContext and post-creation auto-rename triggers behind this new JSON preference.

Fixes

Fixes #1214

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (refactoring code, technical debt, workflow improvements)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (does not change functionality, e.g. code style improvements, linting)
• This change requires a documentation update

Mandatory Tasks

• I have self-reviewed the code
• A decent size PR without self-review might be rejected

Checklist

• I have read the contributing guide
• My code follows the style guidelines of this project (pnpm run format)
• I have commented my code, particularly in hard-to-understand areas
• I have checked if my PR needs changes to the documentation
• I have checked if my changes generate no new warnings (pnpm run lint)
• I have added tests that prove my fix is effective or that my feature works
• I have checked if new and existing unit tests pass locally with my changes

[vercel]

@singhvibhanshu is attempting to deploy a commit to the General Action Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR adds a user-toggleable setting (autoInferTaskNames) that controls whether task names are inferred from conversation context (previously always-on behaviour from #1033). The feature defaults to off, restoring zero-latency random name generation as the default, with LLM-based inference available as an opt-in. Changes span the settings model, the task-creation modal, the chat interface's post-creation rename hook, and a new settings row — all following existing patterns consistently.

Key changes:

• New autoInferTaskNames: boolean setting (default false) added to AppSettings, DEFAULT_SETTINGS, and normalizeSettings
• TaskModal gates both context-based name generation and the isNameGenerated flag behind the setting
• ChatInterface gates handleFirstMessage and shouldCaptureFirstMessage behind the setting via useAppSettings
• AutoInferTaskNamesRow added to General Settings, positioned after AutoGenerateTaskNamesRow
• Good unit-test coverage for normalization and toggle logic

Issues found:

• In TaskModal.handleSubmit, isNameGenerated is only gated on autoInferTaskNames, not also on autoGenerateName. With autoGenerateName: false and autoInferTaskNames: true, an empty-name task submission will set isNameGenerated: true and trigger the post-creation rename — contradicting the user's intent when disabling auto-generate.
• AutoInferTaskNamesRow renders as fully enabled even when autoGenerateName is false, where the setting has no effect on context-based naming in the modal. A disabled state with an explanatory note would improve clarity.

Confidence Score: 3/5

• Safe to merge with low risk, but has a logic gap when autoGenerateName is false and autoInferTaskNames is true.
• The feature is well-structured and follows established patterns. One genuine logic bug exists (isNameGenerated not being co-gated on autoGenerateName), which could cause unexpected post-creation renames for users with autoGenerateName disabled. The UX gap in the settings row is a lesser concern. Tests cover the happy path well but don't exercise the autoGenerateName: false + autoInferTaskNames: true combination.
• Pay close attention to src/renderer/components/TaskModal.tsx (the isNameGenerated logic) and src/renderer/components/TaskSettingsRows.tsx (the disabled-state handling).

Important Files Changed

Filename	Overview
src/main/settings.ts	Cleanly adds autoInferTaskNames: boolean to the AppSettings type, default settings, and normalizeSettings. Change is minimal and well-structured.
src/renderer/components/TaskModal.tsx	Adds autoInferTaskNames state and gates both context-based naming and the isNameGenerated flag behind it. Has a logic gap: isNameGenerated is not also gated by autoGenerateName, so with autoGenerateName: false + autoInferTaskNames: true an empty-name task can still be marked for post-creation rename.
src/renderer/components/ChatInterface.tsx	Reads autoInferTaskNames from useAppSettings context and correctly gates both handleFirstMessage and shouldCaptureFirstMessage behind it. Logic is sound.
src/renderer/components/TaskSettingsRows.tsx	Adds AutoInferTaskNamesRow following the existing pattern. The toggle lacks a visual dependency on autoGenerateName, which can be misleading when that setting is disabled.
src/renderer/hooks/useTaskSettings.ts	Straightforward addition of autoInferTaskNames to the model and a corresponding updateAutoInferTaskNames action. Follows existing patterns.
src/renderer/components/SettingsPage.tsx	Inserts AutoInferTaskNamesRow in the General Settings tab, positioned logically after AutoGenerateTaskNamesRow. No issues.
src/test/main/settings.test.ts	Good coverage of normalizeSettings for autoInferTaskNames: tests default, explicit true/false, and boolean coercion cases.
src/test/renderer/autoInferTaskNames.test.ts	Thorough tests for the toggle logic, name generation functions, and shouldCaptureFirstMessage gating. Tests inline logic directly rather than the component, which is fine for unit coverage.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User opens Task Modal] --> B{autoGenerateName?}
    B -- No --> C[Empty name field shown]
    B -- Yes --> D[Random name pre-filled]

    C --> E[User types prompt / links issue]
    D --> E

    E --> F{autoGenerateName\nAND autoInferTaskNames?}
    F -- Yes --> G[generateTaskNameFromContext runs\nname updated from context]
    F -- No --> H[Name stays random / empty]

    G --> I[User submits]
    H --> I

    I --> J{finalName empty\nOR not user-typed\nAND not from context?}
    J -- Yes --> K[isNameGenerated = autoInferTaskNames\n⚠️ should also check autoGenerateName]
    J -- No --> L[isNameGenerated = false]

    K --> M[Task created with nameGenerated flag]
    L --> M

    M --> N[ChatInterface mounts]
    N --> O{autoInferTaskNames\nAND nameGenerated?}
    O -- Yes --> P[shouldCaptureFirstMessage = true\nFirst terminal msg triggers rename]
    O -- No --> Q[No post-creation rename]

Loading

_{Last reviewed commit: 943daa1}

[greptile-apps]

AutoInferTaskNamesRow has no visual dependency on autoGenerateName

The AutoInferTaskNamesRow toggle is shown as fully interactive even when autoGenerateName is false. In that state the two places where autoInferTaskNames matters — the context-based name generation in TaskModal (if (!autoGenerateName || !autoInferTaskNames …)) and the isNameGenerated logic — are both gated on autoGenerateName as well. A user who enables this toggle while "Auto-generate task names" is off will see no effect at all.

Consider disabling the toggle (and adding an explanatory note) when taskSettings.autoGenerateName is false, e.g.:

const isDisabled = taskSettings.loading || taskSettings.saving || !taskSettings.autoGenerateName;
// …
<Switch
  checked={taskSettings.autoInferTaskNames}
  disabled={isDisabled}
  onCheckedChange={taskSettings.updateAutoInferTaskNames}
/>
{!taskSettings.autoGenerateName && (
  <p className="text-xs text-muted-foreground">
    Requires "Auto-generate task names" to be enabled.
  </p>
)}

[arnestrickmann]

Thanks for taking this on!

[arnestrickmann]

Small follow-up from my review: I think this setting should stay opt-out rather than opt-in. The existing auto-inferred naming behavior should be preserved for both new installs and upgrading users, with the new toggle serving as the explicit opt-out. Concretely, \ should default to , and the normalization fallback should also resolve missing values to . I made that adjustment locally while testing; the rest of the toggle wiring looks good.