feat(tracker): return TodoList display for tracker tools

[anj-s]

Summary

This PR integrates the experimental task tracker more deeply with the CLI and UI by modifying the returnDisplay of all tracker tools to return a structured TodoList object. This allows the CLI UI to natively render the current state of tasks (todos) seamlessly after each tracker operation.

Details

• Implemented buildTodosReturnDisplay in trackerTools.ts to map tasks to a structured TodoList format.
• Replaced the string-based returnDisplay with the structured TodoList return for all tracker tool invocations.
• Improved performance of task cycle detection by reusing a single visited Set instead of allocating new ones recursively.
• Exported TASK_TYPE_LABELS from trackerTypes.ts for reuse in displaying task types.

Related Issues

Fixes #21734

How to Validate

1. Enable the experimental task tracker in settings ("experimental": { "taskTracker": true }).
2. Run the CLI and try to create or update a task (e.g., create a task to write tests).
3. Verify that the task list UI renders correctly in the terminal after the tool executes.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
  • Windows
  • Linux

[gemini-cli]

Hi @anj-s, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.

We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines.

Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.

Thank you for your understanding and for being a part of our community!

[github-actions]

Size Change: +1.67 kB (+0.01%)

Total Size: 26.1 MB

Filename	Size	Change
./bundle/chunk-HD26CB2N.js	0 B	-13.4 MB (removed)	🏆
./bundle/chunk-Z6SWWESI.js	0 B	-3.62 MB (removed)	🏆
./bundle/core-ZHRT2KF2.js	0 B	-40.1 kB (removed)	🏆
./bundle/devtoolsService-TZVSZVZU.js	0 B	-27.7 kB (removed)	🏆
./bundle/interactiveCli-2NOF4NCU.js	0 B	-1.59 MB (removed)	🏆
./bundle/oauth2-provider-YDXJJYEV.js	0 B	-9.19 kB (removed)	🏆
./bundle/chunk-IDVFOYPG.js	3.62 MB	+3.62 MB (new file)	🆕
./bundle/chunk-VLTM6C66.js	13.4 MB	+13.4 MB (new file)	🆕
./bundle/core-NNMHMUFK.js	40.2 kB	+40.2 kB (new file)	🆕
./bundle/devtoolsService-Q6YDR7HW.js	27.7 kB	+27.7 kB (new file)	🆕
./bundle/interactiveCli-YZ52UGLC.js	1.59 MB	+1.59 MB (new file)	🆕
./bundle/oauth2-provider-GLU5IWEX.js	9.19 kB	+9.19 kB (new file)	🆕

ℹ️ View Unchanged

Filename	Size	Change
./bundle/chunk-34MYV7JD.js	2.45 kB	0 B
./bundle/chunk-37ZTTFQF.js	966 kB	0 B
./bundle/chunk-5AUYMPVF.js	858 B	0 B
./bundle/chunk-664ZODQF.js	124 kB	0 B
./bundle/chunk-DAHVX5MI.js	206 kB	0 B
./bundle/chunk-FXR7IA3Q.js	1.95 MB	0 B
./bundle/chunk-IUUIT4SU.js	56.5 kB	0 B
./bundle/chunk-RJTRUG2J.js	39.8 kB	0 B
./bundle/devtools-36NN55EP.js	696 kB	0 B
./bundle/dist-T73EYRDX.js	356 B	0 B
./bundle/gemini.js	689 kB	0 B
./bundle/getMachineId-bsd-TXG52NKR.js	1.55 kB	0 B
./bundle/getMachineId-darwin-7OE4DDZ6.js	1.55 kB	0 B
./bundle/getMachineId-linux-SHIFKOOX.js	1.34 kB	0 B
./bundle/getMachineId-unsupported-5U5DOEYY.js	1.06 kB	0 B
./bundle/getMachineId-win-6KLLGOI4.js	1.72 kB	0 B
./bundle/keychain-token-storage-LF5BRABV.js	0 B	-518 B (removed)	🏆
./bundle/memoryDiscovery-URXPIMBI.js	922 B	0 B
./bundle/multipart-parser-KPBZEGQU.js	11.7 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/client/main.js	221 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/_client-assets.js	227 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/index.js	11.5 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/types.js	132 B	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-open.sb	3.36 kB	0 B
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB	0 B
./bundle/sandbox-macos-strict-open.sb	4.82 kB	0 B
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB	0 B
./bundle/src-QVCVGIUX.js	47 kB	0 B
./bundle/tree-sitter-7U6MW5PS.js	274 kB	0 B
./bundle/tree-sitter-bash-34ZGLXVX.js	1.84 MB	0 B
./bundle/undici-4X2YZID5.js	360 B	0 B
./bundle/keychain-token-storage-X6SCU2F2.js	518 B	+518 B (new file)	🆕

_{compressed-size-action}

[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 significantly enhances the integration of the experimental task tracker within the CLI. It streamlines the user experience by automatically approving tracker-related tools when the feature is active, eliminating repetitive policy prompts. Furthermore, it standardizes the output of tracker tools to a structured TodoList format, allowing for a consistent and native display of task statuses directly within the CLI's user interface.

Highlights

• Policy Engine Auto-allow: Automatically allows all experimental task tracker tools when the taskTracker setting is enabled, removing the need for manual approval.
• Structured UI Return: Modifies tracker tools to return a structured TodoList object, enabling the CLI UI to natively render task states after operations.

Changelog

• packages/cli/src/config/policy.ts
  • The trackerEnabled setting was added to the policySettings object passed to the core policy engine.
• packages/cli/src/ui/components/messages/Todo.tsx
  • A comment was updated to clarify that the TodoList can now originate from various tools, including tracker tools, not just WriteTodosTool.
• packages/core/src/policy/config.test.ts
  • A new test case was added to verify that tracker tools are automatically allowed when trackerEnabled is true in policy settings.
• packages/core/src/policy/config.ts
  • New tracker tool names (e.g., TRACKER_CREATE_TASK_TOOL_NAME) were imported.
  • Logic was added to automatically push PolicyDecision.ALLOW rules for all defined tracker tools if settings.trackerEnabled is true.
• packages/core/src/policy/types.ts
  • The PolicySettings interface was extended to include an optional trackerEnabled boolean property.
• packages/core/src/tools/trackerTools.ts
  • A new asynchronous function buildTodosReturnDisplay was implemented to transform TrackerTask objects into a TodoList structure, handling task hierarchies and cycle detection.
  • The returnDisplay property for all TrackerCreateTaskInvocation, TrackerUpdateTaskInvocation, TrackerGetTaskInvocation, TrackerListTasksInvocation, TrackerAddDependencyInvocation, and TrackerVisualizeInvocation classes was updated to call buildTodosReturnDisplay instead of returning simple strings.

Activity

• No human activity (comments, reviews, etc.) has been recorded on this pull request yet.

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 effectively integrates the experimental task tracker by auto-allowing its tools and providing a structured TodoList display for the UI. I have two suggestions for improvement. First, in packages/core/src/policy/config.ts, the logic for auto-allowing tracker tools can be simplified and made more robust by using a wildcard rule. Second, in packages/core/src/tools/trackerTools.ts, the addTask function has a performance issue due to creating new Set objects inside a recursive loop; I've suggested a more efficient implementation.

[scidomino]

From Gemini:

In packages/cli/src/ui/components/messages/ToolResultDisplay.tsx, there is logic that explicitly returns null if the resultDisplay is a TodoList object. It does this because the TodoTray component renders those lists persistently at the bottom of the screen instead of in the chat feed.
By changing TrackerVisualizeInvocation to use buildTodosReturnDisplay(), when the user runs the tracker_visualize tool, nothing will be printed to the main chat feed. They will only see the TodoTray update. Is that intended?

[anj-s]

From Gemini:

In packages/cli/src/ui/components/messages/ToolResultDisplay.tsx, there is logic that explicitly returns null if the resultDisplay is a TodoList object. It does this because the TodoTray component renders those lists persistently at the bottom of the screen instead of in the chat feed. By changing TrackerVisualizeInvocation to use buildTodosReturnDisplay(), when the user runs the tracker_visualize tool, nothing will be printed to the main chat feed. They will only see the TodoTray update. Is that intended?

Yes, this is intended for now. I am in discussion with UI/UX about the best way to use the visualize tool. If I return the ascii output as is there is some concern about it being confusing for the user. However we still need a way for the LLM to visualize the current progress. I had #19942 to figure this out.