fix(patch): cherry-pick cfdc4cf to release/v0.24.0-pr-16759 to patch version v0.24.0 and create version 0.24.1 by gemini-cli-robot · Pull Request #16865 · google-gemini/gemini-cli

gemini-cli-robot · 2026-01-16T18:36:32Z

This PR automatically cherry-picks commit cfdc4cf to patch version v0.24.0 in the stable release to create version 0.24.1.

Co-authored-by: Tommaso Sciortino <sciortino@gmail.com>

google-cla · 2026-01-16T18:36:38Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

gemini-code-assist · 2026-01-16T18:36:50Z

Summary of Changes

Hello @gemini-cli-robot, 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 introduces a critical fix by converting the scheduleToolCalls mechanism to an asynchronous pattern. This ensures that tool executions are properly awaited, preventing potential race conditions or unexpected behavior in the CLI's UI components. The change also includes necessary updates to type definitions and test suites to align with the new asynchronous flow, ultimately enhancing the stability and predictability of tool interactions within the application.

Highlights

Asynchronous Tool Scheduling: The scheduleToolCalls function is now explicitly awaited in useGeminiStream.ts, ensuring that tool execution completes before subsequent operations.
Updated Schedule Function Signature: The ScheduleFn type in useReactToolScheduler.ts has been modified to return a Promise<void>, formally declaring the asynchronous nature of the scheduling operation.
Enhanced Test Reliability: Corresponding test cases in useToolScheduler.test.ts have been updated to correctly await asynchronous scheduling operations within act blocks, improving the accuracy and reliability of tests for tool scheduling.

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.

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 · 2026-01-16T18:38:48Z

Size Change: +12 B (0%)

Total Size: 22.2 MB

ℹ️ View Unchanged

Filename	Size	Change
`./bundle/gemini.js`	22.2 MB	+12 B (0%)
`./bundle/sandbox-macos-permissive-closed.sb`	1.03 kB	0 B
`./bundle/sandbox-macos-permissive-open.sb`	890 B	0 B
`./bundle/sandbox-macos-permissive-proxied.sb`	1.31 kB	0 B
`./bundle/sandbox-macos-restrictive-closed.sb`	3.29 kB	0 B
`./bundle/sandbox-macos-restrictive-open.sb`	3.36 kB	0 B
`./bundle/sandbox-macos-restrictive-proxied.sb`	3.56 kB	0 B

_{compressed-size-action}

gemini-code-assist

Code Review

This pull request correctly updates the scheduleToolCalls function to be awaited, ensuring proper asynchronous flow and test reliability across the codebase. However, a critical prompt injection vulnerability has been identified. User input is not sanitized before being sent to the LLM, and the application blindly executes tool calls generated by the LLM. This could allow an attacker to execute arbitrary tools, potentially leading to remote code execution. While the PR improves asynchronous handling, it does not address this underlying security issue. Specific comments have been added with details and remediation steps.

gemini-code-assist · 2026-01-16T18:43:50Z

                  prompt_id,
                };
-                scheduleToolCalls([toolCallRequest], abortSignal);
+                await scheduleToolCalls([toolCallRequest], abortSignal);


A critical prompt injection vulnerability exists here. User input is passed to the Gemini model without sanitization, allowing an attacker to manipulate the LLM's behavior and execute arbitrary tool calls, potentially leading to remote code execution. This line executes a tool call originating from a slash command, which is derived from user input. Beyond the security concern, the scheduleToolCalls function is asynchronous and must be awaited to prevent race conditions and ensure proper application flow. Remediation for the vulnerability includes strict input validation and sanitization, implementing an allow-list for tools with schema validation, and requiring user confirmation for sensitive tool calls. The suggested code addresses the asynchronous call.

Suggested change

await scheduleToolCalls([toolCallRequest], abortSignal);

await scheduleToolCalls([toolCallRequest], abortSignal);

gemini-code-assist · 2026-01-16T18:43:50Z

      }
      if (toolCallRequests.length > 0) {
-        scheduleToolCalls(toolCallRequests, signal);
+        await scheduleToolCalls(toolCallRequests, signal);


A critical prompt injection vulnerability exists here. User input is passed to the Gemini model without sanitization, allowing an attacker to manipulate the LLM's behavior and execute arbitrary tool calls, potentially leading to remote code execution. This line executes tool calls requested by the LLM in its response to a user's prompt. Beyond the security concern, scheduleToolCalls is an asynchronous operation and must be awaited to prevent incorrect state management (e.g., StreamProcessingStatus.Completed returning prematurely). Remediation for the vulnerability includes strict input validation and sanitization, implementing an allow-list for tools with schema validation, and requiring user confirmation for sensitive tool calls. The suggested code addresses the asynchronous call.

Suggested change

await scheduleToolCalls(toolCallRequests, signal);

await scheduleToolCalls(toolCallRequests, signal);

gemini-code-assist · 2026-01-16T18:43:50Z

    ) => {
      setToolCallsForDisplay([]);
-      void scheduler.schedule(request, signal);
+      return scheduler.schedule(request, signal);


Previously, void scheduler.schedule explicitly ignored the returned Promise. Since scheduler.schedule is now asynchronous and returns a Promise, it's important to return this Promise. This allows the caller to await the scheduling operation, ensuring proper asynchronous flow and error handling.

Suggested change

return scheduler.schedule(request, signal);

return scheduler.schedule(request, signal);

gemini-code-assist · 2026-01-16T18:43:51Z

+    await act(async () => {
+      await schedule(request, new AbortController().signal);


When testing asynchronous operations in React components, it's crucial to wrap act calls that involve Promises with await act(async () => { await ... }). This ensures that all state updates and side effects triggered by the asynchronous operation are fully processed before the test continues, preventing flaky tests or incorrect assertions.

Suggested change

await act(async () => {

await schedule(request, new AbortController().signal);

await act(async () => {

await schedule(request, new AbortController().signal);

});

gemini-code-assist · 2026-01-16T18:43:51Z

      req: ToolCallRequestInfo | ToolCallRequestInfo[],
      signal: AbortSignal,
-    ) => void,
+    ) => Promise<void>,


The type definition for schedule in the test utility function scheduleAndWaitForExecution must correctly reflect its asynchronous nature, returning Promise<void>. This aligns with the updated ScheduleFn type and ensures type safety within the test.

Suggested change

) => Promise<void>,

) => Promise<void>,

gemini-code-assist · 2026-01-16T18:43:52Z

+    let schedulePromise1: Promise<void>;
+    let schedulePromise2: Promise<void>;


Capturing the promises for each schedule call is essential when testing sequential asynchronous operations. This allows the test to explicitly await each operation's completion at the appropriate time.

let schedulePromise1: Promise<void>; let schedulePromise2: Promise<void>;

gemini-code-assist · 2026-01-16T18:43:52Z

+    await act(async () => {
+      schedulePromise1 = schedule(request1, new AbortController().signal);
    });


Each schedule call must be awaited within an async act block to ensure that the scheduling operation is properly initiated and its immediate effects are processed before the test proceeds.

await act(async () => { schedulePromise1 = schedule(request1, new AbortController().signal); });

gemini-code-assist · 2026-01-16T18:43:52Z

+    await act(async () => {
+      schedulePromise2 = schedule(request2, new AbortController().signal);
    });


Similarly, the second schedule call needs to be awaited within an async act block to ensure its initiation is handled correctly.

await act(async () => { schedulePromise2 = schedule(request2, new AbortController().signal); });

gemini-code-assist · 2026-01-16T18:43:52Z

+    // Wait for first to complete
+    await act(async () => {
+      await schedulePromise1;
+    });


Explicitly awaiting schedulePromise1 ensures that the first scheduled operation has fully completed, including its execution and any subsequent callbacks, before the test asserts its outcome. This is critical for testing sequential asynchronous flows.

await act(async () => { await schedulePromise1; });

gemini-code-assist · 2026-01-16T18:43:52Z

+    await act(async () => {
+      await schedulePromise2;
+    });


Explicitly awaiting schedulePromise2 ensures that the second scheduled operation has fully completed before the test asserts its outcome, maintaining the correctness of the sequential test flow.

await act(async () => { await schedulePromise2; });

Fix race condition by awaiting scheduleToolCalls (#16759)

929a8b1

Co-authored-by: Tommaso Sciortino <sciortino@gmail.com>

gemini-cli-robot requested a review from a team as a code owner January 16, 2026 18:36

github-actions Bot mentioned this pull request Jan 16, 2026

Fix race condition by awaiting scheduleToolCalls #16759

Merged

18 tasks

gemini-code-assist Bot reviewed Jan 16, 2026

View reviewed changes

chrstnb approved these changes Jan 16, 2026

View reviewed changes

scidomino merged commit 33f2b3a into release/v0.24.0-pr-16759 Jan 16, 2026
17 of 18 checks passed

scidomino deleted the hotfix/v0.24.0/0.24.1/stable/cherry-pick-cfdc4cf/pr-16759 branch January 16, 2026 19:19

scidomino temporarily deployed to prod January 16, 2026 19:19 — with GitHub Actions Inactive

sripasg added the size/m A medium sized PR label Jun 2, 2026

	await scheduleToolCalls([toolCallRequest], abortSignal);
	await scheduleToolCalls([toolCallRequest], abortSignal);

	await scheduleToolCalls(toolCallRequests, signal);
	await scheduleToolCalls(toolCallRequests, signal);

	return scheduler.schedule(request, signal);
	return scheduler.schedule(request, signal);

		await act(async () => {
		await schedule(request, new AbortController().signal);

		let schedulePromise1: Promise<void>;
		let schedulePromise2: Promise<void>;

Uh oh!

Conversation

gemini-cli-robot commented Jan 16, 2026

Uh oh!

google-cla Bot commented Jan 16, 2026

Uh oh!

gemini-code-assist Bot commented Jan 16, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

github-actions Bot commented Jan 16, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants