fix(cli): include all Executing subagent tool calls in useToolScheduler state

[TravisHaa]

Summary

• Pass through all Executing subagent tool calls in the useToolScheduler non-root filter, not just AwaitingApproval or previously-seen ones
• Add an explanatory comment distinguishing this from PR Fix subagent interactive shell tool-call visibility #21268's narrower pid-based fix

Why

Subagent tool calls that go directly to Executing without hitting AwaitingApproval (reads, globs, searches, MCP calls — the majority of subagent work) are silently dropped from toolCallsMap on their first update. Two concrete consequences:

1. Task-tree hierarchy is always flat. The tree visualization builds its call graph from parentCallId on each tool call. Filtered-out calls never enter pendingHistoryItems, so useTaskTree never sees them and can't build the parent-child relationship regardless of actual nesting depth.
2. Step-through mode is blind to subagent work. Any feature that needs to observe live subagent execution (progress, step-through, error traces) gets an incomplete picture.

Relationship to PR #21268 / #21052

PR #21268 addresses a narrower slice of the same root cause: it adds tc.pid !== undefined so PTY-backed interactive shell calls surface when they hang on user input. This PR is complementary — it extends the pass-through to all Executing calls. Calls still in Scheduled/Validating remain filtered to prevent transient flicker in the flat-list UI.

Test plan

• Verify subagent reads/globs/searches appear in useToolScheduler state during execution
• Verify task-tree hierarchy renders correctly for nested subagent calls
• Verify existing approval flow for AwaitingApproval subagent calls is unaffected
• Run npm run test --workspace @google/gemini-cli -- src/ui/hooks/useToolScheduler.test.ts

Fixes #22589
Related: #21052, #21268

[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 critical issue where subagent tool calls that directly entered an Executing state were being inadvertently filtered out from the useToolScheduler state. This omission led to an incomplete task-tree hierarchy and obscured subagent activity from debugging tools. The changes ensure that all Executing calls are now properly included, thereby providing a comprehensive view of subagent operations and enabling correct visualization of nested call structures.

Highlights

• Subagent Tool Call Visibility: Modified the useToolScheduler hook to include all Executing subagent tool calls, not just those AwaitingApproval or previously seen. This ensures that reads, globs, searches, and MCP calls are no longer silently dropped.
• Task-Tree Hierarchy Improvement: Enabled the task-tree visualization to correctly build parent-child relationships for nested subagent calls by ensuring all Executing calls are present in the state, addressing previous issues where the hierarchy was always flat.
• Enhanced Debugging and Progress Tracking: Improved the accuracy of features like step-through mode and progress indicators by providing a complete picture of live subagent execution, which was previously incomplete due to filtered-out calls.
• Clarifying Comment Added: Included an explanatory comment in the code to distinguish this broader fix from a narrower, pid-based fix implemented in a related pull request (Fix subagent interactive shell tool-call visibility #21268).

Changelog

• packages/cli/src/ui/hooks/useToolScheduler.ts
  • Updated the filtering logic for non-root schedulers to explicitly include tool calls with CoreToolCallStatus.Executing.
  • Added detailed comments explaining the rationale for including Executing calls, differentiating between interactive shell calls and other subagent work, and clarifying the relationship to previous fixes.

Activity

• The pull request was generated with Claude Code.

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 fixes an issue where subagent tool calls in the Executing state were not being displayed, which caused problems for the task-tree visualization and step-through debugging. The change correctly modifies the filter in useToolScheduler to include these tool calls. While the implementation is correct, it appears to break existing unit tests that were written for the old behavior. My review includes a comment to update the affected tests.

[gemini-cli]

Hi there! Thank you for your interest in contributing to Gemini CLI.

To ensure we maintain high code quality and focus on our prioritized roadmap, we have updated our contribution policy (see Discussion #17383).

We only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. All other community pull requests are subject to closure after 14 days if they do not align with our current focus areas. For this reason, we strongly recommend that contributors only submit pull requests against issues explicitly labeled as 'help-wanted'.

This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding and for being part of our community!

[cocosheng-g]

@TravisHaa, apologies for the bot closing this PR! We have reopened it. Please sync your branch to the latest main and we will have someone review it shortly.

[spencer426]

LGTM

[spencer426]

Ready to merge once all the E2E CI tests pass.

[TravisHaa]

@spencer426 can my PR get added to the merge queue again? It seems like it got evicted ona flaky failure, not a real one. The merge_group run failed on a single Windows nondeterministic test timeout that's unrelated to this PR's diff.

[spencer426]

Looks like there are still failing CI tests. Please address these.

[TravisHaa]

@spencer426 Thanks for the heads up. The failure is in the E2E (Chained) suite, specifically context-compress-interactive.test.ts (/compress command) on Slow E2E - Win - which is unrelated to this PR's diff (this PR only touches useToolScheduler). The job log shows the failure is LLM/infra flakiness, not a code issue.