fix(cli): register extension lifecycle events in DebugProfiler

[fayerman-source]

Summary

Registers extension lifecycle events (extensionsStarting, extensionsStopping) in DebugProfiler to prevent false-positive idle frame warnings during extension loading.

These events are emitted on coreEvents but are not part of the CoreEvent enum, so the profiler was incorrectly treating them as unexpected renders.

Related

Extracted from #18499 as requested by @jacob314.

Testing

No new tests needed — this is a one-line event registration fix. Verified locally that the startup warnings no longer appear.

[gemini-code-assist]

Summary of Changes

Hello @fayerman-source, 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 resolves an issue in the DebugProfiler that led to incorrect idle frame warnings. By explicitly registering specific extension lifecycle events, the profiler now accurately accounts for these operations, preventing misleading diagnostic output and improving the reliability of performance monitoring during application startup.

Highlights

• False-positive idle frame warnings: Addressed an issue where DebugProfiler was generating false-positive idle frame warnings during extension loading.
• Extension lifecycle event registration: Registered extensionsStarting and extensionsStopping events with the DebugProfiler to correctly track their activity.
• Event handling: Ensured that these specific extension lifecycle events, which are emitted on coreEvents but not part of the CoreEvent enum, are properly handled by the profiler.

Changelog

• packages/cli/src/ui/components/DebugProfiler.tsx
  • Registered extensionsStarting and extensionsStopping events with coreEvents to prevent false-positive idle warnings.
  • Added corresponding cleanup for the newly registered event handlers.

Activity

• This change was extracted from a larger pull request (feat: Add voice input with pluggable backend (Gemini zero-install + Whisper) #18499) as requested by @jacob314.
• The author verified locally that the startup warnings no longer appear after applying this fix.

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 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 counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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. ↩

[gemini-code-assist]

Code Review

This pull request correctly registers extension lifecycle events in the DebugProfiler to prevent false-positive idle frame warnings. The change is straightforward and effective. I've added a couple of suggestions to refactor the event registration and cleanup logic to use a loop. This aligns with the existing coding patterns in the file, improves maintainability by reducing code duplication, and adheres to the repository's style guide.

[fayerman-source]

Hi @Adib234 — the failing E2E (Chained) check appears to be unrelated to this PR. The failure is in hooks-agent-flow.test.ts on Windows (a BeforeTool hook returning "File writing blocked by security policy") alongside repeated AttachConsole failed errors. Neither is connected to the two coreEvents.on() registrations added here in DebugProfiler.tsx.

Could you re-run the E2E workflow or confirm whether this is a known flaky test? Happy to rebase if there's an upstream fix needed, but the code change itself should be clear.

[mrpmohiburrahman]

One minor structural suggestion for DebugProfiler.tsx to consider for future
maintainability:

To make it easier to add new lifecycle events in the future without having to
update DebugProfiler, you might consider exporting a runtime constant array
alongside the ExtensionEvents interface definition (around line 247 in
packages/core/src/utils/extensionLoader.ts).

For example:

export const ExtensionLifecycleEvents = [
  'extensionsStarting',
  'extensionsStopping',
] as const;

export interface ExtensionEvents {
  // ...
}

If the profiler just imports and iterates over that core array instead, it will
automatically pick up any new extension events added to that list by future
developers. Just a thought for keeping the event strings centralized!