fix(cli): detect available editors lazily to avoid slow startup

[abhay-codes07]

Summary

On startup, EditorSettingsManager is instantiated at module scope and its constructor probes every known editor through hasValidEditorCommand, which runs a synchronous execSync (e.g. where.exe <editor>) per editor. On systems where process creation is expensive — notably Windows with enterprise endpoint/antivirus software intercepting each spawn — this blocks the interactive UI from drawing its first frame for tens of seconds (reporter measured 50s–90s).

The probed list is only ever consumed by the Editor Settings dialog (EditorSettingsDialog.tsx), so doing this work eagerly at import time is pure startup cost for everyone who never opens that dialog.

Fix

Defer the probing: compute the available editors on the first call to getAvailableEditorDisplays() and cache the result. The constructor now does no work, so importing the module (and constructing the module-scope singleton) no longer spawns any processes. The produced list is identical to before — only the timing changes (import time → first dialog open).

private availableEditors: EditorDisplay[] | null = null;

getAvailableEditorDisplays(): EditorDisplay[] {
  if (this.availableEditors === null) {
    this.availableEditors = this.computeAvailableEditors();
  }
  return this.availableEditors;
}

Testing

Added editorSettingsManager.test.ts (the class is now exported for testability) covering:

• construction performs no editor probing (the regression that caused the slow startup)
• editors are computed on first access and the result is cached (no repeat probing)
• "None" is always listed first; uninstalled editors are labeled (Not installed) and disabled
• editors disallowed in the sandbox are labeled (Not available in sandbox) and disabled

All editor tests pass (4 new + the existing EditorSettingsDialog suite); eslint and tsc --noEmit are clean for the package.

Fixes #28106

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a performance regression where the application startup was blocked by synchronous editor probing. By refactoring the EditorSettingsManager to use lazy initialization, the expensive process-spawning logic is now only executed when the editor settings are actually requested, significantly improving the responsiveness of the CLI on affected platforms.

Highlights

• Lazy Initialization: Deferred the probing of available editors from the class constructor to the first call of getAvailableEditorDisplays, preventing synchronous process spawning during module startup.
• Performance Optimization: Eliminated significant startup latency on Windows systems by avoiding expensive execSync calls during initial application load.
• Test Coverage: Added a new test suite to verify that editor probing does not occur during construction and that results are correctly cached after the first access.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

📊 PR Size: size/M

• Lines changed: 101
• Additions: +97
• Deletions: -4
• Files changed: 2

[gemini-code-assist]

Code Review

This pull request refactors EditorSettingsManager to lazily compute the list of available editors on first access rather than during construction, preventing synchronous shell commands from blocking CLI startup. A new test file editorSettingsManager.test.ts has been added to verify this lazy loading, caching, and editor status behavior. No review comments were provided, and the implementation is clean and well-tested.