MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-05-15 06:12:50 -07:00
Code Issues Packages Projects Releases Wiki Activity
Files
c76ea08eb582943a61e3627b0ab01b2c71e00858
gemini-cli/scripts/backlog-analysis/data/issues.json
T

1572 lines
378 KiB
JSON
Raw Normal View History

feat: consolidate backlog analysis tools into scripts/backlog-analysis
2026-05-06 15:50:06 -04:00
[
{
"body": "![high](https://www.gstatic.com/codereviewagent/high-priority.svg)\n\nThe machine hostname is a static value that does not change during the application's execution. To avoid unnecessary system calls on every render of the `Footer` component, the hostname should be retrieved once and stored in a constant at the module level. This improves efficiency, especially during high-frequency UI updates.\n\n```suggestion\nimport os from 'node:os';\n\nconst HOSTNAME = os.hostname();\n```\n\n_Originally posted by @gemini-code-assist[bot] in https://github.com/google-gemini/gemini-cli/pull/25637#discussion_r3105835632_",
"number": 25638,
"title": "![high](https://www.gstatic.com/codereviewagent/high-priority.svg)",
"url": "https://github.com/google-gemini/gemini-cli/issues/25638",
"analysis": "Optimize retrieval of machine hostname by moving `os.hostname()` from the `Footer` component render cycle to a module-level constant.",
"effort_level": "small",
"reasoning": "This is a highly localized static refactoring task that involves moving a single system call to a module-level constant in one file. It fits the criteria for a small effort level as it is a trivial optimization with no complex logic or state management involved.",
"recommended_implementation": "In `Footer.tsx`, import `os` from `node:os`. Move `os.hostname()` to a `const HOSTNAME = os.hostname();` declaration outside the component function.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nHi,\nAbout this feature:\nhttps://geminicli.com/docs/reference/configuration/#environment-variables-and-env-files\n\nCould you make it support casting the strings \"true\" and \"false\" to booleans?\n\nRight now it says:\n\n> Error in: ui.autoThemeSwitching\n> Expected boolean, received string\n\nWhen I set this value:\n~~~\n\"autoThemeSwitching\": \"${GEMINI_AUTO_THEME:-true}\"\n~~~\n\n### Why is this needed?\n\nI want to set the `autoThemeSwitching` flag via environment variables.\nThis is because Gemini CLI wrongly identifies my shell as light when it is actually dark.\nAnd I can't rely on a static value, such as setting `autoThemeSwitching` to false, because I have multiple VTEs, some dark and some light.\n\n### Additional context\n\n_No response_",
"number": 25573,
"title": "Support boolean types when configuring `settings.json` via environment variables",
"url": "https://github.com/google-gemini/gemini-cli/issues/25573",
"analysis": "Allow environment variables like `${GEMINI_AUTO_THEME:-true}` to be correctly cast to boolean types during settings validation.",
"effort_level": "small",
"reasoning": "The fix is highly localized to the settings-validation.ts file. It requires a simple modification to the buildZodSchemaFromJsonSchema function to add a Zod preprocessor for boolean types, casting the strings 'true' and 'false' to actual booleans. This falls under the criteria of casting/formatting simple data types and localized fixes with a clear root cause.",
"recommended_implementation": "In `packages/cli/src/config/settings-validation.ts`, update the boolean schema definitions to use `z.preprocess()` which converts strings `'true'` or `'false'` into actual boolean values.",
"validated": true
},
{
"body": "### Description\nWhen running multiple Gemini CLI instances over SSH on different hosts, it is very easy to get lost or confused about which host you are currently interacting with.\n\n### Proposed Solution\nInclude the machine's hostname in the CLI interface (e.g., in the header, prompt, or a dedicated status line). This will provide immediate visual confirmation of the current environment.\n\n### Expected Behavior\nThe CLI should display the hostname (e.g., `Gemini CLI (lapcat)` or similar) so users can distinguish between different sessions.",
"number": 25571,
"title": "feat: add machine hostname to CLI interface",
"url": "https://github.com/google-gemini/gemini-cli/issues/25571",
"analysis": "Retrieve and display the machine's hostname in the CLI interface (header or footer).",
"effort_level": "small",
"reasoning": "Retrieving the machine hostname via Node.js 'os.hostname()' and displaying it within an existing Ink component like AppHeader or Footer is a localized UI adjustment with trivial logic, requiring minimal changes to 1-2 files.",
"recommended_implementation": "Import `os` in `packages/cli/src/ui/components/AppHeader.tsx`. In `renderMetadata`, add a new `<Text>` component that displays the hostname retrieved via `os.hostname()`.",
"validated": true
},
{
"body": "## Description\nCurrently, new voice transcriptions are appended to the very end of the input buffer. To make it easier to edit and build long prompts, the transcribed text should be inserted exactly where the user's cursor is currently located.\n\n## Requirements\n- Update the `InputPrompt` or related components to splice the transcribed text at the cursor index instead of appending.\n\nEpic: #24175",
"number": 25494,
"title": "[Voice] Cursor-Aware Insertion",
"url": "https://github.com/google-gemini/gemini-cli/issues/25494",
"analysis": "Splice transcribed voice text at the current cursor position in the input buffer instead of appending it.",
"effort_level": "large",
"reasoning": "While the logic to splice a string at a specific index is simple, the previous analysis indicates that the entire Voice Mode transcription pipeline and WhisperModelManager are currently missing from the codebase. Implementing this feature requires the foundational voice infrastructure, which falls under the 'Major Subsystems' category for Large effort.",
"validated": true
},
{
"body": "## Description\nCurrently, the Whisper models are being pulled directly from Hugging Face. For improved security, reliability, and bandwidth control, we should mirror these models to our own storage infrastructure.\n\n## Requirements\n- Evaluate hosting Whisper weights securely (e.g., in a GCS bucket or similar infrastructure).\n- Update the `WhisperModelManager` download URLs to point to the mirrored locations.\n\nEpic: #24175",
"number": 25496,
"title": "[Voice] Whisper Model Mirroring",
"url": "https://github.com/google-gemini/gemini-cli/issues/25496",
"analysis": "Mirror Whisper model weights to internal storage (GCS) and update the manager to download from the new locations.",
"effort_level": "medium",
"reasoning": "The task requires infrastructure setup (GCS bucket) and security evaluation for hosting model weights, which falls under service integration. While the code change to update URLs is simple, the requirement to evaluate and implement secure hosting for large binary assets, combined with the fact that the target subsystem (Voice) is currently being integrated, places this in the 1-3 day range.",
"validated": true
},
{
"body": "## Description\nCurrently, the UI displays a static \"Listening...\" text when recording audio. Replacing this with a small, dynamic audio wave-type animation would provide better visual feedback and make the interface feel more compact and polished.\n\n## Requirements\n- Implement an animated CLI indicator (e.g., using ASCII/Unicode bars or existing ink animation libraries) that triggers while audio is being recorded.\n\nEpic: #24175",
"number": 25493,
"title": "[Voice] Dynamic Visual Feedback (Audio Wave)",
"url": "https://github.com/google-gemini/gemini-cli/issues/25493",
"analysis": "Implement a dynamic ASCII/Unicode audio wave animation to replace the static 'Listening...' text during voice recording.",
"effort_level": "medium",
"reasoning": "Implementing a dynamic ASCII animation in Ink requires managing React state and effects to handle the animation loop, as well as synchronizing the UI state with the underlying audio recording lifecycle. This involves logic tracing and integration within the CLI's UI components, fitting the Medium effort criteria for React/Ink state management and UI synchronization.",
"validated": true
},
{
"body": "## Description\nThe persistent `> Voice mode: Hold Space to record (Esc to exit)` banner takes up screen real estate. We should evaluate removing it or making it transient, to make it more palatable for users to leave voice mode enabled permanently.\n\n## Requirements\n- Review and potentially remove the persistent banner from the UI.\n- Ensure users still have an intuitive way to discover the push-to-talk keybinding without the permanent banner.\n\nEpic: #24175",
"number": 25490,
"title": "[Voice] Optimize Screen Real Estate (Banner)",
"url": "https://github.com/google-gemini/gemini-cli/issues/25490",
"analysis": "Modify the Voice mode banner ('> Voice mode: Hold Space to record (Esc to exit)') to be transient or removable to save screen real estate.",
"effort_level": "small",
"reasoning": "The task is a localized UI/Aesthetic adjustment focused on modifying or removing a specific Ink component (the Voice banner). It involves minor changes to the UI layout and potentially simple state management for transience (e.g., a timer or visibility toggle), which falls under the criteria for a small effort level (<= 1 day).",
"validated": true,
"recommended_implementation": "In the Voice mode UI component, introduce a 'visible' state initialized to true and use a useEffect hook with a setTimeout to set it to false after 5 seconds. Conditionally render the banner text based on this state to make the instructions transient rather than persistent."
},
{
"body": "## Description\nWhen using the Cloud/Gemini Live backend, voice recordings are sent to the Gemini API endpoint. This might create a mixed compliance scenario for enterprise users. We should add a UX warning to clarify data privacy and handling when cloud transcription is enabled.\n\n## Requirements\n- Add a warning/notice in the settings or upon first enabling the Gemini Live backend detailing the data flow.\n\nEpic: #24175",
"number": 25491,
"title": "[Voice] Privacy & Compliance UX Warning",
"url": "https://github.com/google-gemini/gemini-cli/issues/25491",
"analysis": "Add a privacy and compliance UX warning detailing data flow when the Gemini Live backend is enabled for voice.",
"effort_level": "medium",
"reasoning": "Implementing a privacy and compliance warning requires defining new configuration keys in the settings schema and adding logic to the CLI's UI (Ink components) to trigger a notice. Since the requirement includes showing the warning 'upon first enabling,' it involves state management to track user acknowledgement or the initial toggle event, which fits the criteria for logic tracing and UI state synchronization.",
"validated": true
},
{
"body": "## Description\nIn the `/voice-model` menu, pressing `Return` should select the model and close the menu. Currently, users have to press `Return` and then `Esc` to exit, which feels unconfirmed and adds friction.\n\n## Requirements\n- Modifying the VoiceModelDialog or related UI components so that selection via `Return` automatically dismisses the dialog.\n\nEpic: #24175",
"number": 25492,
"title": "[Voice] Enhance `/voice-model` Menu Navigation",
"url": "https://github.com/google-gemini/gemini-cli/issues/25492",
"analysis": "Update the `/voice-model` selection menu so that pressing `Return` selects the model and automatically closes the dialog.",
"effort_level": "small",
"reasoning": "The task involves a localized UI/UX refinement within a single Ink component (VoiceModelDialog). It requires updating the 'Return' key event handler to trigger the dialog's dismissal logic immediately after selection. This is a trivial logic adjustment that does not involve complex state synchronization or architectural changes, fitting the criteria for a Small effort level.",
"validated": true,
"recommended_implementation": "In `VoiceModelDialog.tsx`, update the `handleSelect` callback to invoke the `onClose` function immediately after the model selection logic is executed."
},
{
"body": "### What would you like to be added?\n\nI am proposing the implementation of a comprehensive RTL and BiDi (Bidirectional) text rendering engine tailored for the CLI. I have already developed a complete solution with the following key improvements:\n\n- **Universal RTL Logic:** Refactored utilities to support all RTL languages (Arabic, Hebrew, Persian, Urdu, etc.).\n- **ANSI-Safe Rendering:** Preserves escape codes for styling during text reordering.\n- **Precise Line Wrapping:** Implemented a \"Wrap-First, Reorder-Second\" strategy to prevent vertical line displacement.\n- **Performance:** Implemented a Singleton pattern for the BiDi engine to optimize memory usage.\n- **Resiliency:** Added a `GEMINI_NATIVE_RTL` environment variable as a kill switch for native terminal support.\n- **Testing:** Added comprehensive unit tests using Vitest to ensure stability across languages and environments.\n\n### Why is this needed?\n\nCurrently, the Gemini CLI does not correctly render Right-to-Left (RTL) languages in the terminal. The text often appears disconnected, in reverse order, or suffers from severe formatting corruption when mixed with ANSI escape codes (colors, bold text, etc.). \n\nWhile there have been previous requests for specific language support like Arabic (e.g., #1791, #2954), they were closed due to inactivity. The CLI currently lacks a universal bidirectional text shaping solution that safely handles terminal styling across all OS environments for all RTL languages.\n\n### Additional context\n\nI have already submitted a Pull Request that fully implements this architecture and solves the issue. \n\n**Related PR:** #25243 \nBefore:\n\n<img width=\"1463\" height=\"390\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/c69dd2fc-f582-48ed-a501-6d254022d90e\" />\n\n<img width=\"952\" height=\"745\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/28925ede-fa20-4ca5-a7ed-5689a23b0717\" />",
"number": 25478,
"title": "Feature Request: Universal RTL and BiDi Support for Terminal Rendering",
"url": "https://github.com/google-gemini/gemini-cli/issues/25478",
"analysis": "Implement a bidirectional (BiDi) and RTL text rendering engine for the CLI that preserves ANSI escape codes and ensures precise line wrapping.",
"effort_level": "large",
"reasoning": "Implementing a comprehensive BiDi and RTL engine for a terminal environment is a major subsystem task. It requires complex algorithmic logic to handle the Unicode Bidirectional Algorithm (UBA) while preserving ANSI escape sequences for styling. Integrating this into the existing Ink-based rendering pipeline, ensuring correct line-wrapping without vertical displacement, and managing cross-platform terminal inconsistencies constitutes significant architectural complexity.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA large number of logs leads to inefficiency in troubleshooting and affects scrolling performance\n\n### Why is this needed?\n\nProvide log classification search function\n\n### Additional context\n\n_No response_",
"number": 25439,
"title": "A large number of logs leads to inefficiency in troubleshooting and affects scrolling performance",
"url": "https://github.com/google-gemini/gemini-cli/issues/25439",
"analysis": "Improve the debug log display by adding classification (filtering) and search functionality to handle large volumes of logs without affecting TUI performance.",
"effort_level": "medium",
"reasoning": "Implementing log classification and search functionality within the Ink-based TUI requires managing React state for search queries and filtered results, handling input focus transitions, and ensuring UI synchronization. This aligns with the Medium criteria for state management and UI interaction logic.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nAdd support for a local-only configuration file (e.g., `.gemini/settings.local.json`) that merges with the project-level `.gemini/settings.json`.\n\n**Example solution:**\nThe CLI should check for `.gemini/settings.local.json` and prioritize its configuration over `.gemini/settings.json`. This allows users to add the `.local.json` file to their `.gitignore`/global ignore while keeping shared settings in the standard config file.\n\n\n### Why is this needed?\n\nUsers need a way to define local-specific hooks and other machine-specific overrides that should not be committed to the shared repository.\n\n### Additional context\n\n_No response_",
"number": 25380,
"title": "Support per-project local settings",
"url": "https://github.com/google-gemini/gemini-cli/issues/25380",
"analysis": "Add support for a local-only configuration file (`.gemini/settings.local.json`) that is merged into the settings chain but not committed to git.",
"effort_level": "small",
"reasoning": "Adding support for a local configuration file involves updating the existing tiered settings loading logic to include an additional file path and merging it into the priority chain. This is a localized change within the configuration subsystem and fits the criteria for a small effort task.",
"recommended_implementation": "In `loadSettings` in `packages/cli/src/config/settings.ts`, add a check for the existence of `.gemini/settings.local.json`. If it exists, load and merge it after the standard workspace settings but before returning the final merged object.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n\"WSL-aware\" mode similar to how the 'code' command works in WSL and how WSL Connect command works in VS Code. Specifically:\n\nPath Normalization: The CLI should recognize when it is being run inside WSL and normalize the Project ID hash so that a project in WSL and the same project in Windows share the same session/memory bucket.\n\nSession / Credential Bridge: When the Windows binary is called from WSL2 it should automatically default to the Windows User Profile for session data and authentication tokens without requiring manual environment variable overrides.\n\nUnified Trust: Permission/Trust settings applied in Windows should automatically apply to the WSL environment for the same directory.\n\n### Why is this needed?\n\nCurrently, using the Gemini CLI within a WSL2 instance while maintaining the configuration, authentication, and session memory of the host Windows environment is cumbersome.\nUnlike VS Code, which seamlessly bridges the gap between Windows and WSL, the Gemini CLI treats the same physical folder as two different projects because of path differences, lack of shared session memory and lack of credentials sharing.\n\nWindows Path: e:\\src\\name\\project\nWSL2 Path: \\\\wsl.localhost\\Ubuntu\\mnt\\e\\name\\project (as seen by Windows binaries running in interop mode from WSL) or /{mount point for e:}/name/project (as seen by native Linux).\n\nThis causes the CLI to:\n\nLose session history when switching between Windows and WSL terminals.\nMark folders as \"Untrusted\" in WSL even if they are trusted in Windows.\nRequire manual creation of symlinks or complex aliases (passing USERPROFILE and node.exe) to share session / project history.\n\n### Describe alternatives you've considered\n\nUsing alias gemini='node.exe ...' with manual USERPROFILE path. This is brittle and fails to solve the Project ID hash mismatch.\nMoving all projects to /mnt/c/, which results in slower filesystem performance for Linux-native tools.\nManual symlinking of ~/.gemini, which is risky and can lead to file lock contention.\n\n### Additional context\n\n\nMy primary workflow involves switching between Windows and WSL2 due to necessity of using tools specific to supported OS family - I need seamless working session continuation across WSL2 OS boundary. Due to deep integration between Windows and WSL2 the CLI should support WSL2 as a integrated subsystem of Windows rather than treating it as a completely isolated Linux OS.",
"number": 25184,
"title": "Feature Request: Seamless WSL2 Support on Windows (Path Translation, Unified Session Memory & Windows based Credentials)",
"url": "https://github.com/google-gemini/gemini-cli/issues/25184",
"analysis": "Implement WSL-aware mode to normalize paths, project IDs, and credential storage between Windows and WSL environments.",
"effort_level": "medium",
"reasoning": "Implementing WSL-aware path normalization and credential bridging requires detecting the WSL environment, translating paths between Linux and Windows formats (e.g., /mnt/c/ vs C:\\), and ensuring consistent project hashing. This involves logic tracing across path resolution and session management modules to ensure unified session memory and credential access across OS boundaries, which requires robust testing on both environments.",
"recommended_implementation": "Update `listSessions` in `packages/cli/src/utils/sessions.ts` to accept an optional `filter` string. Use this string to filter the `sessions` array before the `.forEach` display loop.",
"validated": true
},
{
"body": "Hello team!\n\nI've noticed a change in behavior since version 0.36.0 regarding how file paths are resolved for @ mentions when running gemini-cli inside the VSCode integrated terminal.\n\nBefore v0.36.0: When I launched gemini-cli (in VSCode) from a specific folder, for example my_project/src/component1/, any file I referenced with @ would use a path relative to that components directory. For instance, a file at my_project/src/component1/button.js could be referenced simply as @button.js. I found this quite logical, and easy to use.\n\nFrom v0.36.0 onwards: The context for @ mentions seems to be the entire path. Using the same example, if my workspace root is my_project, the reference to the same file becomes @c:/Users/User/path_to_project/src/component1/button.js. In addition, it also shows files outside of the cwd, that are in the project. This becomes very inconventient if your project contains many folders that are called similarly, for example, if I also have a button in another component (e.g. c:/Users/User/path_to_project/src/component2/button.js)\n\nInterestingly, if I run gemini-cli v0.36.0 in a standalone terminal, it still operates with the old, desired behavior. This leads me to believe the change is specific to the VSCode integration.\n\nAfter looking through the changelog, I believe this change might have been introduced by the following pull request:\n[#21380](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgoogle-gemini%2Fgemini-cli%2Fpull%2F21380): fix(cli): automatically add all VSCode workspace folders to Gemini context\n\nWhile I understand the idea of making the context the entire workspace, it would be great to have control over this behavior. Would it be possible to introduce a setting (perhaps in settings.json) that allows users to choose the desired context for @ file mentions?\n\nAlternatively, if there's an existing workflow to achieve the old behavior within VSCode that I'm not aware of, I would also be helped to get to know more about that instead!\n\nThanks in advance!",
"number": 25012,
"title": "Add a setting to control @ file path context in VSCode terminal",
"url": "https://github.com/google-gemini/gemini-cli/issues/25012",
"analysis": "Introduce a setting to control whether `@` file path mentions in the VSCode terminal are relative to the current folder or the entire workspace.",
"effort_level": "medium",
"reasoning": "Implementing this requires adding a new configuration property to the settings schema, updating the AtFileProcessor to check this setting, and potentially modifying the path resolution logic in the core library's readPathFromWorkspace function. While the logic change is localized, ensuring consistent path resolution behavior across different terminal environments and operating systems requires careful validation and testing.",
"recommended_implementation": "Add `ui.fileAtMentionScope` (enum: 'cwd' | 'workspace') to `settingsSchema.ts`. Update `atFileProcessor.ts` to filter the files retrieved from `readPathFromWorkspace` based on this setting.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like to be able to quickly jump to the file or code references.\n\n### Why is this needed?\n\nIt definitely eases the navigation in any project.\n\n### Additional context\n\n_No response_",
"number": 24812,
"title": "File and code references shall be hyperlinks",
"url": "https://github.com/google-gemini/gemini-cli/issues/24812",
"analysis": "Convert file and code references in the CLI output to clickable hyperlinks using the OSC 8 terminal escape sequence.",
"effort_level": "medium",
"reasoning": "Implementing OSC 8 hyperlinks requires creating a utility for escape sequences, detecting terminal support, and modifying multiple UI components (Markdown renderer and Tool output handlers) to identify and wrap file paths. This involves logic tracing across the UI layer and adjustments to the Markdown parsing/rendering logic, which aligns with the Medium effort criteria for integration across components and parser modifications.",
"recommended_implementation": "In `packages/cli/src/ui/components/AskUserDialog.tsx`, wrap the `prompt` text in a `<Text bold color={theme.status.warning}>` component to make it stand out from standard chat messages.",
"validated": true
},
{
"body": "### What happened?\n\nusing `--output-format json` does not have any effect on the output of --list-sessions\n\n\n### What did you expect to happen?\n\nI was expecting to see sessions information in json format\n\nI would like to use it as input to another command (related to https://github.com/google-gemini/gemini-cli/issues/24687)\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n\u2502 CLI Version 0.36.0 \u2502\n\u2502 Model Auto (Gemini 3) \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS linux \u2502\n\u2502 Auth Method Signed in with Google (agierakowski@gmail.com) \u2502\n\u2502 Tier Gemini Code Assist in Google One AI Ultra \n```\n\n</details>\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 24690,
"title": "--list-sessions does not support --output-format json",
"url": "https://github.com/google-gemini/gemini-cli/issues/24690",
"analysis": "Enable raw JSON output for the `--list-sessions` command when the global `--output-format json` flag is used.",
"effort_level": "small",
"reasoning": "The fix is highly localized to the `listSessions` function in `packages/cli/src/utils/sessions.ts`. It requires a simple conditional check on the `config` object to determine if JSON output is requested and then serializing the existing `sessions` array. This falls under trivial logic and formatting adjustments, fitting the criteria for a small effort task.",
"recommended_implementation": "In `listSessions` (packages/cli/src/utils/sessions.ts), check `config.getOutputFormat()`. If it equals `'json'`, use `writeToStdout(JSON.stringify(sessions))` and return early.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI'd like to be able to list all sessions, and have the directory of the sessions displayed in the output\n\n \n\n### Why is this needed?\n\nThis is useful when working with git worktrees, since a single project would have sessions scattered across multiple directories. I would like to use --json output to feed it to another tool, which would allow me to select a sessions and automatically cd into sessions dir and run `gemini --resume <session-id>`\n\n### Additional context\n\n_No response_",
"number": 24687,
"title": "allow listing all sessions, not only ones for current directory",
"url": "https://github.com/google-gemini/gemini-cli/issues/24687",
"analysis": "Allow the `--list-sessions` command to discover and display sessions from all projects/directories, not just the current one, and include the directory path in the output.",
"effort_level": "medium",
"reasoning": "Implementing a global session list requires modifying the session manager to traverse all subdirectories within the ~/.gemini/sessions storage path, rather than just the current project's hash-based directory. This involves asynchronous filesystem operations, potential updates to the session metadata schema to ensure the original directory path is consistently stored/retrieved, and updating the CLI output logic to handle the aggregated data and the --json flag requirements.",
"recommended_implementation": "Update `listSessions` to scan the entire global session storage directory. Pass a flag to `sessionSelector.listSessions()` to skip filtering by current project hash, then display the `workspaceDir` property for each session found.",
"validated": true
},
{
"body": "ACP needs a host-answerable input request for `ask_user` and `exit_plan_mode`.\n\nRight now ACP can start sessions, resume them, send prompts, cancel turns, and handle permission flows. But if Gemini CLI needs structured user input, ACP does not give the host a way to answer it. That forces the flow back into the terminal UI.\n\nThat is the gap I need closed.\n\nI want Gemini CLI in ACP mode to work like the other controller boundaries I already use:\n- Codex app-server\n- Claude Agent SDK\n\nThe host should be able to:\n- receive the input request\n- show it in its own UI\n- send the answer back\n- continue the same turn\n\nRelevant ACP work I checked first:\n- #23045\n- #21783\n- #17952\n- #23818\n- #23961\n- #12042\n\nThis PR is the narrow fix for that gap: #24664\n\nWhat it adds:\n- an opt-in ACP extension: `gemini/requestUserInput`\n- host-answerable handling for `ask_user`\n- host-answerable handling for `exit_plan_mode`\n- `ask_user` stays disabled in ACP unless the host explicitly opts in\n- per-kind support so a host can enable only `exit_plan_mode` if it wants\n\nWhat it does not do:\n- add MCP\n- add a second app-server\n- turn `ask_user` back on globally in ACP\n",
"number": 24663,
"title": "ACP: let hosts answer ask_user and exit_plan_mode",
"url": "https://github.com/google-gemini/gemini-cli/issues/24663",
"analysis": "Extend the Agent-to-Agent (ACP) server to allow host editors to programmatically respond to `ask_user` and `exit_plan_mode` prompts.",
"effort_level": "large",
"reasoning": "This task involves architectural and protocol changes to the Agent-to-Agent (ACP) server and the core Scheduler's routing logic. According to the criteria, modifications to the A2A protocol, task Scheduler, and implementing host-answerable input flows across the controller boundary are classified as Large effort due to their complexity and impact on the core execution pipeline.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like to have the ability to select the extensions that are used in one command rather than run numerous commands to enable / disable multiple extensions at once. This is because I frequently have subsets of commands in my user setup that differ (changing as many as 2-3 per time).\n\nI propose the following new command:\n```\ngemini extensions select [names..] [--all] [--none] Select which extensions to enable. Without arguments, shows an interactive picker.\n```\n\n### Why is this needed?\n\nThis makes it far easier to instantly swap between sets of extensions in the same environment.\n\n### Additional context\n\nFor larger code bases, such as large operating system projects (think something like Android), it's easier to have specialized extension packs per area or large subsystem such that you do not context flood the system. While plenty of tools exist to create these extensions, they're a bit of a pain to turn on and off. This command accelerates that process significantly.",
"number": 24658,
"title": "gemini extensions select command - interactive and one-shot ability to quickly manage extensions",
"url": "https://github.com/google-gemini/gemini-cli/issues/24658",
"analysis": "Implement a new `/extensions select` command that allows users to enable or disable multiple extensions at once, including an interactive multi-select picker.",
"effort_level": "medium",
"reasoning": "Implementing the `/extensions select` command requires creating a new interactive multi-select UI component using Ink, managing its internal state, and integrating it with the existing extension enablement services. This involves logic tracing across the CLI's command structure and state synchronization to batch-apply changes to the extension configuration, which aligns with the Medium effort criteria for React/Ink state management and service integration.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nRelocate the `TopicStickyHeader` from the chat history to a persistent position at the top of the application layout (immediately below the header metadata). This ensures the current topic remains visible at all times during scrolling.\n\n### Why is this needed?\n\nCurrently, the topic header scrolls away with the chat history. In long conversations or during heavy tool execution, users lose the context of what the AI is currently doing (e.g., \"Researching...\", \"Planning...\"). A persistent \"sticky\" header provides constant context without cluttering the scrollback or duplicating headers in the history.\n\n### Additional context\n\nThe implementation includes:\n- Global placement in `DefaultAppLayout` and `ScreenReaderAppLayout`.\n- Visual styling with background and separator.\n- Cleanup of dynamic injection logic in `MainContent`.\n- Restored natural topic updates in history.",
"number": 24553,
"title": "feat(ui): implement persistent sticky topic header",
"url": "https://github.com/google-gemini/gemini-cli/issues/24553",
"analysis": "Relocate the `TopicStickyHeader` from the scrolling chat history to a persistent, fixed position at the top of the application layout.",
"effort_level": "medium",
"reasoning": "Relocating the TopicStickyHeader requires synchronizing state between the message history and the global application layout. This involves modifying multiple layout files (DefaultAppLayout, ScreenReaderAppLayout) and implementing or leveraging React state/context to track the 'current' topic as it changes during execution, which fits the criteria for state management and component integration.",
"validated": true
},
{
"body": "### URL of the page with the issue\n\nhttps://geminicli.com/extensions/\n\n### What is the problem?\n\nFlag paid services and services with additional contracts and Terms of services for the Gemini-cli users to clearly see before they install the service to be used by Gemini CLI.\n\nOne such service is **conversiontoolsgemini-extension**\n\nhttps://geminicli.com/extensions/?name=conversiontoolsgemini-extension\n\n\n### What did you expect to happen?\n\nI expected to see next to **conversiontoolsgemini-extension** two flags. One flag for being a paid service, and second flag means that using it you have agreed to their TOS.\nThese flags will prevent Gemini users from unintentional expenses as well as from unintentional contractual obligations.\n\n\n### Additional context\n\n_No response_",
"number": 24427,
"title": "GeminiCLI.com Feedback: [ISSUE]",
"url": "https://github.com/google-gemini/gemini-cli/issues/24427",
"analysis": "Flag paid extensions and services with additional Terms of Service (TOS) on the GeminiCLI.com extensions gallery.",
"effort_level": "medium",
"reasoning": "This task requires modifying the Zod schema for extension metadata in the core package, updating the extension registry data, and implementing UI changes in the website's gallery components to render the new flags. It involves state/data synchronization across the core types and the frontend, which aligns with the Medium effort criteria for schema validation and multi-component integration.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like an option to suppress or collapse the verbose file-content output in the terminal during file-write operations. Specifically, the CLI should provide a configuration setting or flag (e.g., --quiet or verbosity: summary) that replaces the full code stream with a single-line confirmation.\n\n**Proposed UI Change:**\nInstead of streaming the entire file, the output should be condensed to a simple status block:\n\u256d\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256e\n\u2502 \u2713 Successfully wrote 452 lines to next-web/.../ToolClient.tsx \u2502\n\u2570\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256f\n\n### Why is this needed?\n\nCurrently, when the CLI updates a file, it prints the entire source code to the terminal. For large components or long-running sessions, this creates significant \"terminal noise.\" This makes it extremely difficult to\n\n1. Scroll back to see previous command history or AI reasoning.\n2. Identify specific messages or logs buried in the code stream.\n3. Maintain a clean development workflow when multiple files are being modified in sequence.\n\n### Additional context\n\nLarge file writes currently dominate the terminal buffer as shown below:\n\n\u256d\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256e\n\u2502 \u2713 WriteFile Writing to next-web\\...\\tool\\ToolClient.tsx \u2502\n\u2502 \u2502\n\u2502 1 - 'use client'; \u2502\n\u2502 ... [hundreds of lines of code] ... \u2502\n\u2570\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256f\n\nReducing this to a summary-only view would greatly improve the clarity and usability of the CLI for professional development tasks.",
"number": 24407,
"title": "Hide the generated output code from CLI",
"url": "https://github.com/google-gemini/gemini-cli/issues/24407",
"analysis": "Add an option to suppress the verbose code streaming output during file-write operations, showing only a concise summary instead.",
"effort_level": "small",
"reasoning": "The task involves adding a new configuration field to the settings schema and implementing a conditional rendering check in the ToolResultDisplay component. This is a highly localized change (2 files) that falls under trivial logic/config and UI adjustments as per the criteria.",
"recommended_implementation": "Add `ui.verbosity` to `settingsSchema.ts`. In `ToolResultDisplay.tsx`, if the tool is `edit` or `write_file` and verbosity is `'summary'`, render only the status line and the line count instead of the `DiffRenderer`.",
"validated": true
},
{
"body": "### What happened?\n\nI'm writing an agent skill that uses `ask_user`. A user in test mentioned that the `ask_user` UI in the footer was difficult to read:\n\n> I originally didn't realize it was waiting for me on the last step of the process, likely because the footer on the UI didn't change. Maybe bold the instructions on the last step?\n\n<img width=\"1452\" height=\"492\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/1d592401-63a2-44b2-ad3c-14fd1d6dbf7c\" />\n\n### What did you expect to happen?\n\nIt should be easy to read the user interface controls.\n\n### Client information\n\n* CLI version: 0.36.0-nightly.20260317.2f90b4653-git.9cf4104 * Git Commit: 9cf4104\n* Model: gemini-3-flash-preview \n* Sandbox: no sandbox \n* OS: linux\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 24395,
"title": "ask_user interface can be difficult to notice",
"url": "https://github.com/google-gemini/gemini-cli/issues/24395",
"analysis": "Make the `ask_user` tool prompt more prominent in the TUI to prevent users from missing it.",
"effort_level": "small",
"reasoning": "This is a localized UI/aesthetic adjustment within a single Ink component (AskUserDialog.tsx). It involves simple styling changes such as adding bold text or adjusting colors to improve visibility, which aligns with the criteria for small effort tasks.",
"recommended_implementation": "In `AskUserDialog.tsx`, wrap the prompt text in a `<Text bold color={theme.status.warning}>` component and add a top margin to separate it from the history.",
"validated": true
},
{
"body": "## Problem\n\nWhen running Gemini CLI as an ACP server (`gemini --acp`), token usage and cost data are reported differently from other ACP implementations (Claude Agent ACP, Codex ACP), making it harder for ACP clients to track usage consistently.\n\n### Current behavior\n\n**Token usage** is returned in `PromptResponse._meta.quota.token_count`:\n```json\n{\n \"stopReason\": \"end_turn\",\n \"_meta\": {\n \"quota\": {\n \"token_count\": { \"input_tokens\": 1234, \"output_tokens\": 567 },\n \"model_usage\": [...]\n }\n }\n}\n```\n\n**Cost** is not reported anywhere.\n\n### Expected behavior (per ACP protocol)\n\n**Token usage** in `PromptResponse.usage` (standard ACP field):\n```json\n{\n \"stopReason\": \"end_turn\",\n \"usage\": {\n \"input_tokens\": 1234,\n \"output_tokens\": 567,\n \"total_tokens\": 1801\n }\n}\n```\n\n**Cost** via `UsageUpdate` session notification:\n```json\n{\n \"sessionUpdate\": \"usage_update\",\n \"cost\": { \"amount\": 0.0023, \"currency\": \"USD\" },\n \"size\": 1048576,\n \"used\": 1801\n}\n```\n\n### Why this matters\n\nACP clients (Zed, OpenHands, etc.) use `PromptResponse.usage` and `UsageUpdate.cost` to track token consumption and spending. Without these standard fields, each client needs Gemini-specific fallback logic to parse `_meta.quota`.\n\nClaude Agent ACP and Codex ACP both populate these standard fields. Aligning Gemini CLI would make it a drop-in replacement in any ACP client.\n\n### Reference\n\n- ACP protocol schema: `PromptResponse.usage` ([Usage type](https://agentclientprotocol.com/protocol/overview))\n- ACP protocol schema: `UsageUpdate.cost` ([Cost type](https://agentclientprotocol.com/protocol/overview))\n- Claude Agent ACP implementation: sends both `usage` in PromptResponse and `cost` in UsageUpdate ([source](https://github.com/zed-industries/claude-agent-acp/blob/main/src/acp-agent.ts))",
"number": 24280,
"title": "ACP: populate PromptResponse.usage and send UsageUpdate with cost",
"url": "https://github.com/google-gemini/gemini-cli/issues/24280",
"analysis": "Enhance the ACP server to populate `PromptResponse.usage` and broadcast `UsageUpdate` events that include calculated session costs.",
"effort_level": "medium",
"reasoning": "This task involves logic tracing and integration across the ACP server implementation and the model response handling. It requires mapping existing token data to a new protocol-compliant structure and implementing a cost calculation utility based on model-specific rates. Since it involves modifying the asynchronous flow to broadcast session notifications (UsageUpdate) and ensuring protocol consistency across components, it fits the Medium effort criteria.",
"validated": true
},
{
"body": "## Problem\nOn Alpine, startup/auth path does extra work that slows time-to-prompt:\n- auth refresh work runs twice during startup\n- first config load performs heavier work than needed before interactive readiness\n\n## Why this matters\nThis increases startup latency and can make CLI responsiveness feel unstable on Alpine VPS hosts.\n\n## Proposed scope\nTargeted startup/auth cleanup in `packages/cli`:\n- avoid duplicate auth refresh\n- carry successful initial auth into the UI auth hook to avoid rework\n- keep first startup config pass minimal\n\n## Prior implementation\nI already implemented and smoke-validated this as PR #22498 (now auto-closed by bot policy after 14 days):\n- https://github.com/google-gemini/gemini-cli/pull/22498\n\n## Request\nIf this is in scope for community contribution, please mark this issue as `help wanted` and I will submit/re-submit the PR in the exact format you prefer.\n",
"number": 24199,
"title": "Alpine startup/auth: remove duplicate refresh and reduce first-pass startup work",
"url": "https://github.com/google-gemini/gemini-cli/issues/24199",
"analysis": "Optimize the auth and startup flow for non-interactive environments (like Alpine Linux CI/CD) by reducing redundant work and credential refreshes.",
"effort_level": "medium",
"reasoning": "The task involves logic tracing and state synchronization between the initial CLI startup sequence and the React/Ink UI hooks. Optimizing the authentication lifecycle to prevent redundant refreshes and ensuring state is correctly passed through the asynchronous flow requires careful validation of the auth provider and startup logic, fitting the criteria for Medium effort.",
"validated": true
},
{
"body": "### URL of the page with the issue\n\nhttps://geminicli.com/docs/cli/tutorials/skills-getting-started/\n\n### What is the problem?\n\nHey team, I noticed that the tutorial currently says Gemini \u201cautomatically discovers skills,\u201d but it doesn\u2019t explain what a user should do if a skill doesn\u2019t appear in /skills list.\n\nCommon problems that beginners might run into include:\n\nMis-typed skill directory or filename\nIncorrect folder structure\nWrong case in filenames\n\nIt would be really helpful to add a short troubleshooting section that covers these scenarios, e.g.:\n\u274c \u201cSkill not found\u201d \u2192 Verify .gemini/skills/<name>/SKILL.md exists\n\u274c Wrong name \u2192 Ensure skill directory name matches `name` field in SKILL.md\n\nThis would make onboarding smoother and reduce confusion for new users.\n\n### What did you expect to happen?\n\nThis would make onboarding smoother and reduce confusion for new users.\ngemini skills list\nmy skill doesn\u2019t show up. There\u2019s no error message or guidance in the tutorial, so it\u2019s unclear why the skill wasn\u2019t discovered.\n\nWhat I expected:\n\nThe tutorial should either explain common causes for skill discovery failure or show how to verify/validate a skill.\nA new skill should appear in /skills list if the folder structure and SKILL.md are correct.\nClear troubleshooting tips, e.g.:\n\n### Additional context\n\n_No response_",
"number": 24169,
"title": "GeminiCLI.com Feedback: skill doesn\u2019t appear in /skills list.",
"url": "https://github.com/google-gemini/gemini-cli/issues/24169",
"analysis": "Investigate and fix why certain skills do not appear in the `/skills` list despite being successfully loaded.",
"effort_level": "medium",
"reasoning": "The issue involves investigating and fixing logic within the CLI's skill discovery and UI rendering pipeline. Based on the previous analysis, this requires tracing state synchronization between the skill manager and the Ink-based UI components (SkillsList.tsx), ensuring that filtering logic correctly handles various skill types. This aligns with the Medium criteria for logic tracing and state management in React/Ink components.",
"recommended_implementation": "Update the filtering logic in `packages/cli/src/ui/commands/skillsCommand.ts` to include all skills from the `agentRegistry` without excluding based on metadata flags like `isHidden` unless explicitly requested.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nLet users queue a message while compression is running\n\n### Why is this needed?\n\nWhen we run compress, there's a wait time, and we currently have to send a message manually after it finishes. If we could queue a message during compression, we wouldn't need to stay at our desks.\n\n### Additional context\n\n_No response_",
"number": 24071,
"title": "Let users queue a message while compression is running",
"url": "https://github.com/google-gemini/gemini-cli/issues/24071",
"analysis": "Enable users to type and queue a new message while the conversation history is being compressed, rather than blocking the UI.",
"effort_level": "medium",
"reasoning": "This task requires modifying the React/Ink state management within the CLI's UI components to handle asynchronous state transitions between compression and message processing. It involves synchronizing the input buffer with the completion of the compression task, which fits the criteria for Medium effort due to state synchronization and async flow handling.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nCurrent logs and debug information is not very informative - while message history is captured, no files with detailed logs capturing LLM calls, API responses, are missing. It is next to impossible to debug cases with very timeouts, e.g. request to LLM doesn't produce response for a long time or returns specific errors.\n\nI'd like to see in logs timestamps with API calls, details of API calls, including messages if requested (e.g. set verbosity level) as message history is not easy to attribute to specific calls. \n\n### Why is this needed?\n\n- Support development/contribution to gemini-cli\n- Debugging of issues\n- Testing work with other LLMs\n\n### Additional context\n\n_No response_",
"number": 24033,
"title": "Provide detailed logs with LLM calls with `--debug`",
"url": "https://github.com/google-gemini/gemini-cli/issues/24033",
"analysis": "Add detailed raw request and response logging for all Gemini API calls when the `--debug` flag is active.",
"effort_level": "small",
"reasoning": "The task is highly localized to the `LoggingContentGenerator` class. It involves adding a few `debugLogger.debug` calls to capture and output the JSON payloads of API requests and responses, which are already being processed by this class. This aligns with the criteria for minor logging adjustments and localized fixes.",
"recommended_implementation": "In `loggingContentGenerator.ts`, wrap the `generateContent` and `sendMessage` calls with `debugLogger.debug` statements that log the stringified request and response objects.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nAdd an option to send a signal sent to the process which causes it to check stdin for more context.\n\n### Why is this needed?\n\nWhen I'm using gemini-cli with the -p flag, if it gets stuck due to a broken command (i.e., grep'ing a huge mono repo) or is going down a wrong path, I need to kill the process and start over.\n\nThis is problematic if I'm using the tool in a bash script that is operating on many folders, or if there has been a lot of great progress but it is spinning.\n\n### Additional context\n\n_No response_",
"number": 24030,
"title": "Provide method to 'interrupt' stuck agent when running in headless mode",
"url": "https://github.com/google-gemini/gemini-cli/issues/24030",
"analysis": "Provide a mechanism (like SIGINT handling) to interrupt a 'stuck' agent turn when running in headless/non-interactive mode.",
"effort_level": "medium",
"reasoning": "Implementing a signal handler that interrupts a 'stuck' agent turn to prompt for additional context requires more than a simple process exit. It involves modifying the asynchronous control flow to catch the signal, triggering the existing AbortController, and then transitioning the process state to read from stdin\u2014potentially in an environment where stdin was not originally expected to be interactive. This requires logic tracing across the CLI and the agent session management to ensure the session remains valid after the interruption.",
"recommended_implementation": "Add a `process.on('SIGINT', ...)` handler in `nonInteractiveCli.ts` that calls `abortController.abort()` to cleanly terminate the pending model request and exit the process.",
"validated": true
},
{
"body": "## Summary\nCurrently, ECONNRESET errors are not handled with user-friendly messages.\n\n## Proposed Change\nAdd a clear error message for ECONNRESET in fsErrorMessages.ts.\n\n## Expected Outcome\nUsers get better guidance when connection resets.",
"number": 23874,
"title": "Improve filesystem error handling for ECONNRESET",
"url": "https://github.com/google-gemini/gemini-cli/issues/23874",
"analysis": "Provide a user-friendly error message for the `ECONNRESET` system error code in filesystem operations.",
"effort_level": "small",
"reasoning": "The change is a trivial addition of a single error message string to a static mapping object in a single file (fsErrorMessages.ts). It falls under the category of string/content updates and trivial logic adjustments, requiring minimal effort and testing.",
"recommended_implementation": "Add a new entry for `'ECONNRESET'` to the `errorMessageGenerators` map in `fsErrorMessages.ts` with a description like 'The connection was reset by the filesystem or remote host.'",
"validated": true
},
{
"body": "## Summary\nCurrently, ETIMEDOUT filesystem errors are not handled with user-friendly messages.\n\n## Proposed Change\nAdd a clear error message for ETIMEDOUT in fsErrorMessages.ts.\n\n## Expected Outcome\nUsers get better guidance when operations time out.",
"number": 23861,
"title": "Improve filesystem error handling for ETIMEDOUT",
"url": "https://github.com/google-gemini/gemini-cli/issues/23861",
"analysis": "Provide a user-friendly error message for the `ETIMEDOUT` system error code in filesystem operations.",
"effort_level": "small",
"reasoning": "The change is a highly localized string/content update involving the addition of a single entry to a mapping object in one file (fsErrorMessages.ts). It requires no complex logic or cross-component integration.",
"recommended_implementation": "Add an entry for `'ETIMEDOUT'` to the `errorMessageGenerators` map in `fsErrorMessages.ts` with a clear message like 'The filesystem operation timed out.'",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWhen I hit Ctrl+O to see the full output of a shell command, it would also be nice to see the full command.\n\n### Why is this needed?\n\nI'd like to know the full command that gemini runs, with all arguments. That's needed for transparency to verify what it's doing, and to catch it if it does something incorrect or destructive.\n\n### Additional context\n\nThank you.",
"number": 23800,
"title": "please show full command with Ctrl+O",
"url": "https://github.com/google-gemini/gemini-cli/issues/23800",
"analysis": "Display the full executed shell command in the tool detail view triggered by `Ctrl+O`.",
"effort_level": "small",
"reasoning": "This is a localized UI adjustment within the Ink-based terminal interface. The shell command data is already captured in the ToolInvocation object; the task simply involves adding a Text component to the existing detail view triggered by the Ctrl+O keypress handler. It falls under the criteria for minor UI tweaks and displaying existing data.",
"recommended_implementation": "Update `packages/cli/src/ui/components/views/ToolOutputDetail.tsx` to display `invocation.command` at the top of the detail box, formatted as a code block.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nCurrently, the Gemini CLI hardcodes configuration and history to ~/.gemini. This ignores the XDG Base Directory Specification, which is the industry standard for Unix-like environments (Linux, macOS, BSD). This leads to \"home directory pollution\" and makes configuration management difficult for users who centralize their dotfiles.\n\nModify packages/core/src/utils/paths.ts to resolve GEMINI_DIR using the following priority:\n* GEMINI_CONFIG_DIR: Explicit environment override. Optional: allows user to custom location based on own preference\n* XDG_CONFIG_HOME/gemini: The standard location if the XDG variable is set instead of home .gemini.\n* ~/.gemini: Current hardcoded default.\n\n### Why is this needed?\n\n* System Consistency: Users who set XDG_CONFIG_HOME expect tools to respect it automatically.\n* Clean Home Directory: Prevents the creation of non-standard hidden folders in the user's root $HOME.\n* Security & Backups: Standardized paths allow for easier permission management and automated backup indexing.\n* Developer Experience: Aligning with tools like cargo, git, and nvim creates a more professional, system-aware CLI.\n\nCurrently the closest you get is by hacking GEMINI_CLI_HOME to XDG_CONFIG_HOME but then you have non-standard config/.gemini (source: https://raw.githubusercontent.com/google-gemini/gemini-cli/refs/heads/main/docs/cli/enterprise.md)\n\n> By default, Gemini CLI stores configuration and history in `~/.gemini`. You can use the `GEMINI_CLI_HOME` environment variable to point to a unique directory for a specific user or job. The CLI will create a `.gemini` folder inside the specified path.\n\n### Additional context\n\nRelevant file: https://raw.githubusercontent.com/google-gemini/gemini-cli/bbf5c2fe95d67a93c6fa64cbb11a7383296a8bea/packages/core/src/utils/paths.ts\n```ts\n// Current\nexport const GEMINI_DIR = '.gemini';\n\n// Proposed\nimport path from 'path';\nconst getGeminiDir = () => {\n if (process.env.GEMINI_CONFIG_DIR) return process.env.GEMINI_CONFIG_DIR; // Optional: would allow user to custom location based on own preference\n if (process.env.XDG_CONFIG_HOME) return path.join(process.env.XDG_CONFIG_HOME, 'gemini');\n return '.gemini';\n};\n\nexport const GEMINI_DIR = getGeminiDir();\n```\n\nThis builds on PR #2817 which was rejected due to non-XDG solution",
"number": 23796,
"title": "Support XDG Base Directory Specification for configuration",
"url": "https://github.com/google-gemini/gemini-cli/issues/23796",
"analysis": "Modify the CLI to follow the XDG Base Directory Specification for configuration and data storage (e.g., using `~/.config/gemini` if `XDG_CONFIG_HOME` is set).",
"effort_level": "small",
"reasoning": "The change is highly localized to a single file (packages/core/src/utils/paths.ts) and involves straightforward logic to check environment variables and return a path string. This fits the criteria for trivial logic/config adjustments and is easily reproducible and testable.",
"recommended_implementation": "In `paths.ts`, update the `getGeminiDir()` function to check `process.env.XDG_CONFIG_HOME` or `process.env.GEMINI_CONFIG_DIR` before defaulting to `path.join(os.homedir(), '.gemini')`.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nJust a very tiny improvement can be made to where you add a simple 1 liner \"npm install -g @google/gemini-cli\" after \u2715 Automatic update failed. Please try updating manually. (Or spend 1 minute like Claude implementing a simple sudo check and adding sudo infront of the 1liner suggestion.\n\n### Why is this needed?\n\nNot needed. Simple quality of life improvement.\n\n### Additional context\n\n_No response_",
"number": 23786,
"title": "Provide link when Automatic Update fails",
"url": "https://github.com/google-gemini/gemini-cli/issues/23786",
"analysis": "Provide a manual download/update URL in the TUI notification when the automatic background update fails.",
"effort_level": "small",
"reasoning": "This is a localized string and UI content update within the UpdateNotification component. It involves modifying a static error message to include a manual installation command, which falls under the criteria for minor UI/aesthetic adjustments and string updates.",
"recommended_implementation": "Update `packages/cli/src/ui/components/UpdateNotification.tsx` to accept an optional `downloadUrl` and render it using a blue `<Text>` element if the update state indicates a failure.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWhile working on PR #23477, I noticed that debug logging behavior is not consistently handled across components.\n\nSome components manually guard debug logs using checks like `process.env.NODE_ENV !== 'test'`, while others rely on the logger itself.\n\nThis creates duplication and inconsistency in how debug logs are handled.\n\nProposal:\nStandardize debugLogger behavior so that test environments automatically suppress debug output without requiring per-component checks.\n\nThis would:\n- reduce duplication across components\n- improve maintainability\n- ensure consistent logging behavior across the codebase\n\n### Why is this needed?\n\nCurrently, debug logging behavior is inconsistent across the codebase, with some components manually handling environment checks while others rely on the logger.\n\nThis leads to duplicated logic, harder maintenance, and potential inconsistencies in test output.\n\nA centralized approach would simplify component code and ensure consistent behavior across all debug logging.\n\n### Additional context\n\nThis was observed while working on PR #23477.",
"number": 23745,
"title": "Improve consistency of debugLogger behavior across CLI components",
"url": "https://github.com/google-gemini/gemini-cli/issues/23745",
"analysis": "Refactor the logging system to ensure `debugLogger` behavior and output formatting are consistent across both `packages/core` and `packages/cli`.",
"effort_level": "medium",
"reasoning": "Standardizing debugLogger involves modifying the core logging utility and refactoring multiple components across the core and CLI packages to remove manual environment guards. This requires logic tracing across the codebase and validation to ensure the TUI correctly handles the standardized output without display inconsistencies, fitting the criteria for integration across multiple components.",
"validated": true
},
{
"body": "### What happened?\n\nWhen tasks are completed, they are moved to the end of the task list in the UI. This makes sense for long task lists where we don't want completed tasks cluttering up the start. However, there is no delineation between the todo tasks and completed tasks, making it look like gemini just started at the end.\n\n### What did you expect to happen?\n\nI expected completed tasks to be clearly separated from todo tasks. Honestly I expected the order to not change at all but I can understand why you would want to do that for large lists.\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n\u2502 About Gemini CLI \u2502\n\u2502 \u2502\n\u2502 CLI Version 0.35.0 \u2502\n\u2502 Git Commit a3cc1c5 \u2502\n\u2502 Model Auto (Gemini 3) \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS win32 \u250
"number": 23730,
"title": "Completed tasks moving to the end is confusing",
"url": "https://github.com/google-gemini/gemini-cli/issues/23730",
"analysis": "Fix the confusing behavior where completed sub-tasks are automatically moved to the end of the task list.",
"effort_level": "small",
"reasoning": "This is a localized UI adjustment in the Todo component. The fix involves either modifying the sorting logic or adding a visual separator between task states within a single file (packages/cli/src/ui/components/messages/Todo.tsx), which aligns with the criteria for minor structural layouts and trivial logic changes.",
"recommended_implementation": "In `Todo.tsx`, remove any `.sort()` logic that prioritizes incomplete tasks, ensuring the `subtasks` array is rendered in its original order.",
"validated": true
},
{
"body": "### What happened?\n\nI like Gemini 3.1 its a good model for agentic work. Gemini CLI is awful. It's like going back in time even preceding the dreadful vim. What are the CLI developers doing? Editing is terrible. Gemini tries to make excuses that its a terminal. Big deal. The purpose of any UI for the model is to be helpful, to make it easy to do hard things. The CLI inverts that goal and makes it difficult to do easy things. \n\nMy day-to-day use is inside VSCode. Here I have to Ctrl-X to open a page into which I type. What?! We're 26 years into the 21st century and the 1980's is asking for its command line back. Maybe its that the CLI developers have never used anything but Linux so a UI is foreign. \n\nThe usability issues are all over the place. I asked Gemini how to do something in VSCode. It produced a configuration **but with line numbers**. No, no simple cut-and-paste. No I had cut-and-paste then remove the line number. Who is designing this? Who thinks putting line numbers that will be included in the copy buffer is a good idea? This is not a terminal thing, this is a thoughtless thing. You have one of, if not the best, LLM to work with. It can help you do a better job. You should try it. \n\nWhen I (laboriously) wrote my concerns into the terminal it wrote:\n\n\"You are completely right, and that is entirely valid feedback. The terminal environment definitely has strict limitations for multi-line text input compared to a real editor, which is why the Ctrl+X buffer exists as a workaround\u2014but as you noted, it still feels like a band-aid that interrupts your flow.\n\nThe issue with the line numbers on code blocks is a particularly painful UX oversight. The CLI's markdown renderer adds those line numbers to make reading code easier in the terminal, but completely breaks the ability to highlight and copy clean code. You shouldn't have to manually edit out line numbers just to use a snippet.\"\n\nOf course its going to agree with me but it makes the point that the behavior of the CLI is not frictionless. It then suggested using /bug or /feedback (couldn't find /feedback) but didn't offer to create the post so I'm typing again. I know Google is more interested in the higher goals of cutting edge research not mundane development tasks. But maybe, just maybe, it can spend a little bit more of its billions in revenue and make the CLI more usable.\n\n### What did you expect to happen?\n\nNot be clumsy.\n\n### Client information\n\n\n* **CLI Version:** 0.34.0\n* **Git Commit:** 49a86550c\n* **Session ID:** d6d16ae1-6380-43aa-8c9f-8aef1f4f75b0\n*%\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 23675,
"title": "Gemini CLI is Clumsy",
"url": "https://github.com/google-gemini/gemini-cli/issues/23675",
"analysis": "Address general UX 'clumsiness' (e.g., input lag, flickering, or non-standard key handling) reported in feedback.",
"effort_level": "medium",
"reasoning": "The issue describes fundamental UX friction in the TUI, specifically regarding input handling (Ctrl-X workflow) and output formatting (line numbers). Addressing this requires modifying React/Ink state management in InputPrompt.tsx to improve the input buffer experience and potentially adjusting the Markdown renderer or system prompt logic to handle code block formatting better. This involves logic tracing and state synchronization across multiple UI components, fitting the Medium criteria.",
"validated": true
},
{
"body": "> [!IMPORTANT]\n> Thanks for taking the time to suggest an enhancement!\n> Please search **existing issues** to see if a similar feature has already been requested.\n\n**What would you like to be added?**\nAdd a command to export the current session context (conversation history, loaded files, and state) to a JSON file that can be shared or resumed later.\n\n**Why is this needed?**\nCurrently sessions are ephemeral. Users cannot share their work-in-progress with teammates or save their session for later continuation.\n\n**Additional context**\nUse case: A developer wants to share their debugging session with a colleague, or save their work before restarting the CLI. The exported file could be loaded with `--session-file` flag.",
"number": 23663,
"title": "feat: Export session to file for sharing",
"url": "https://github.com/google-gemini/gemini-cli/issues/23663",
"analysis": "Add a feature to export the current conversation session to a standalone file (JSON or Markdown) for sharing or archival.",
"effort_level": "medium",
"reasoning": "Implementing session export and import requires integrating with the ChatRecordingService, handling asynchronous file I/O, and modifying the CLI state initialization to support loading from a file. Ensuring the session can be correctly resumed involves state synchronization and validation of the imported data, which fits the criteria for logic tracing and service integration across components.",
"recommended_implementation": "Add a `/session export <path>` subcommand in `packages/cli/src/ui/commands/sessionCommand.ts`. The action should retrieve the full transcript from `agentContext.chatRecordingService` and save it to the provided path.",
"validated": true
},
{
"body": "Tracker issue to address possibly redundant diffstat generation logic.\r\n\r\nSee [comment](https://github.com/google-gemini/gemini-cli/pull/23286#discussion_r2976246003_) on code change to properly calculate diffstats when user manually modifies AI suggested file edits. \r\n \r\n_Originally posted by @jacob314 in https://github.com/google-gemini/gemini-cli/pull/23286#discussion_r2976246003_\r\n\r\n",
"number": 23617,
"title": "Consolidate diffstat generation logic",
"url": "https://github.com/google-gemini/gemini-cli/issues/23617",
"analysis": "Consolidate the duplicated logic for generating `diffstat` (line additions/deletions) into a single shared utility.",
"effort_level": "medium",
"reasoning": "Consolidating diffstat generation logic requires tracing how file changes are calculated across multiple tool implementations (e.g., edit_file, apply_diff). It involves more than simple string extraction; it requires ensuring that the logic correctly handles edge cases where users manually modify AI-suggested edits, necessitating logic synchronization across the core utility and the tool execution layer, along with robust validation to prevent regressions in chat history reporting.",
"recommended_implementation": "Extract the line-counting and diff-aggregation logic into a `calculateDiffStat` function in `fileDiffUtils.ts` and update `edit.ts` and `write-file.ts` to use it.",
"validated": true
},
{
"body": "### URL of the page with the issue\n\nhttps://geminicli.com/extensions/\n\n### What is the problem?\n\nadd colab mcp https://developers.googleblog.com/announcing-the-colab-mcp-server-connect-any-ai-agent-to-google-colab/\n\n### What did you expect to happen?\n\ngoogle colab cpde execution with jules integration\n\n### Additional context\n\n_No response_",
"number": 23561,
"title": "GeminiCLI.com Feedback: Add colab MCP server to extensions",
"url": "https://github.com/google-gemini/gemini-cli/issues/23561",
"analysis": "Add a Google Colab MCP server entry to the official extensions gallery on GeminiCLI.com.",
"effort_level": "small",
"reasoning": "This is a content and metadata update for the extensions gallery. It involves adding a new entry to a static list or configuration file, which falls under the criteria for string/content updates and trivial configuration changes.",
"recommended_implementation": "Add the Colab MCP server configuration and description to the `extensions.json` registry file (or equivalent site metadata).",
"validated": true
},
{
"body": "### Overly Complex Configuration and Lack of Global Scope (Please learn from Claude Code)\n\nI would like to suggest a major overhaul of the configuration system for Gemini CLI and Antigravity. Currently, the settings setup is **excessively complex and highly fragmented**. \n\nThe biggest issue is that settings do not easily apply globally across the entire account or workspace. We have to manually configure environments, API settings, and rules per project or repeatedly copy/paste settings which is a significant friction point for adoption and daily use.\n\n**Feature Request:**\nPlease simplify the configuration system. We strongly request a global, unified configuration model similar to **Claude Code**, where settings are intuitive, easily managed, and seamlessly apply globally across the account without needing to wrestle with nested JSON configurations or repetitive setups for every new task.\n\n\"Please, just make it simple and globally applicable like Claude Code.\" This would drastically improve the user experience. Thank you!\n",
"number": 23501,
"title": "[Feature Request] Simplify Configuration System & Add Global Settings (Like Claude Code)",
"url": "https://github.com/google-gemini/gemini-cli/issues/23501",
"analysis": "Redesign and simplify the multi-tiered configuration system to provide a flatter schema and more intuitive global/local override behavior.",
"effort_level": "large",
"reasoning": "Redesigning the configuration system from a fragmented, nested structure to a unified global/local model requires significant architectural changes to the core Settings class, schema definitions, and UI components. It also necessitates a robust migration strategy for existing user data and complex logic for hierarchical setting resolution, fitting the criteria for a major subsystem overhaul.",
"validated": true
},
{
"body": "## What would you like to be added?\n\nGemini CLI should support resuming a session from any folder using the session GUID that is already accepted by `--resume`.\n\nConcretely, `gemini --resume <session-id>` should resolve sessions globally instead of only looking in the current project. If the current working directory does not match the session's original project root, the CLI should show the original folder and ask whether to:\n\n- resume in the current folder, or\n- cancel so the user can `cd` to the original folder and rerun the command.\n\nThe same global behavior should also apply consistently to `/resume`, `--list-sessions`, and related session-management flows.\n\n## Why is this needed?\n\nGemini CLI already supported passing a session GUID to `--resume` before PR #20667, and PR #20667 made that capability more discoverable by showing the GUID in the quit/footer UI.\n\nThat improved discoverability is helpful, but there is still a critical gap: the displayed GUID is only practically useful if the user is still in the original folder, because session discovery is still project-scoped.\n\nThis creates a broken workflow for real users:\n\n- a session ends and the CLI tells them to resume with `gemini --resume <guid>`\n- they open a new shell, switch directories, or restart from another repo/worktree\n- the GUID they were told to use no longer works because the CLI only searches the current project's local session store\n\nAt that point the resume token is visible but not portable. Supporting global cross-folder resume makes the existing GUID-based workflow actually reliable and useful.\n\n## Additional context\n\nPR #20667 improved the UX by surfacing the GUID, but it did not make resume global.\n\nThe missing behavior is:\n\n- globally unique session lookup by GUID\n- globally accessible session metadata/storage\n- safe handling when the current folder differs from the session's original folder\n- consistent behavior across `--resume`, `/resume`, `--list-sessions`, and related commands\n\nWithout this, the current resume story is only partially complete: the CLI shows users a precise resume command, but that command still depends on staying in the same folder where the session was created.\n",
"number": 23489,
"title": "Support resuming sessions from any folder with globally addressable session IDs",
"url": "https://github.com/google-gemini/gemini-cli/issues/23489",
"analysis": "Allow sessions to be resumed using their UUID from any directory, rather than being restricted to the directory where they were created.",
"effort_level": "medium",
"reasoning": "Implementing global session resumption requires modifying the session discovery logic to search across all project-specific storage directories rather than just the current one. It also necessitates adding an interactive prompt to handle directory mismatches and updating multiple entry points including --resume, /resume, and --list-sessions, which involves logic tracing and UI state management.",
"recommended_implementation": "In `resolveSession` (packages/cli/src/utils/sessions.ts), if the session is not found in the current project directory, use `fs.readdirSync` to iterate over all subdirectories in the sessions root and look for a matching UUID filename.",
"validated": true
},
{
"body": "## Problem Statement\n\nDevelopers frequently encounter friction when trying to commit code, only to be blocked by failing `pre-commit` hooks (such as ESLint warnings, Prettier formatting errors, or broken Vitest suites).\nCurrently, the process requires the developer to manually cancel the commit, read the terminal output, identify the failure, run Gemini CLI to help fix it, or try to patch it themselves before re-committing.\n\n## Proposal\n\nTo streamline the developer experience and make Gemini an indispensable part of the daily workflow, `gemini-cli` should introduce a first-class **\"Explain and Fix this Error\" Git Hook Integration**.\n\n1. **New CLI Command**: Add `gemini-cli install-hook` (or a similar command) that automatically installs a custom `pre-commit` wrapper script in the local `.git/hooks/pre-commit` directory.\n2. **Error Interception**: When the user runs `git commit`, if the underlying pre-commit checks fail and throw an exit code `> 0`, the wrapper will intercept the standard error output.\n3. **Interactive Fixes**: The CLI will then automatically activate and prompt the user interactively in the terminal:\n - *\"Your pre-commit checks failed with the following error (Vitest: expected 5 but got 4). Would you like Gemini to analyze the staged diff and propose a fix? [Y/n]\"*\n4. **Seamless Workflow**: If accepted, the agent analyzes the context, patches the error, and automatically stages the new changes to complete the commit successfully without the developer ever leaving their flow state.\n\n## Benefits\n- Solidifies Gemini CLI as a core developer productivity tool that automatically resolves friction.\n- Completely novel terminal experience comparing to standard IDE plugins.\n- Highly actionable, since the CLI already possesses powerful patching mechanisms\u2014it just needs the Git hook trigger.\n\n## Checklist\n- [ ] Add the `install-hook` command to the CLI package.\n- [ ] Create the bash/Node script template for the `pre-commit` wrapper.\n- [ ] Develop the hook runner that pipes `stderr` context into an interactive Gemini session.\n- [ ] Write integration and end-to-end tests for the Git hook lifecycle.\n",
"number": 23456,
"title": "Feature: Explain this Error Git Pre-Commit Hook Integration",
"url": "https://github.com/google-gemini/gemini-cli/issues/23456",
"analysis": "Implement a Git pre-commit hook integration that automatically pipes hook failures to Gemini for an explanation and suggested fix.",
"effort_level": "medium",
"reasoning": "This feature requires implementing a new CLI command, handling filesystem operations to install the hook into the .git directory, and creating a wrapper script to manage process exit codes and pipe stderr to the Gemini API. It involves service integration and asynchronous flow management, fitting the 1-3 day development window.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n### Description\n\nAdd a three-snapshot memory leak detection module to `packages/core/src/telemetry/` that implements the [3-snapshot technique](https://developer.chrome.com/docs/devtools/memory-problems#the_three_snapshot_technique) for identifying sustained memory leaks in the CLI.\n\n\n### Proposed Implementation\n\n- `captureLeakSnapshot()` \u2014 captures lightweight memory snapshots using `process.memoryUsage()` and `v8.getHeapSpaceStatistics()`\n- `calculateGrowth()` \u2014 computes deltas between two snapshots including per-heap-space breakdown\n- `analyzeSnapshots()` \u2014 applies the 3-snapshot technique with configurable byte and percentage thresholds, classifies severity\n- `formatLeakReport()` \u2014 generates human-readable diagnostic output\n\n\n### Why is this needed?\n\nThe CLI has multiple open OOM-related issues (#16271, #19607, #16356) but no built-in mechanism to programmatically detect memory leaks. The 3-snapshot technique is a well-established method that distinguishes genuine leaks from one-time allocations by requiring growth across two consecutive phases.\n\nThis is foundational infrastructure for the GSoC \"Terminal-Integrated Performance & Memory Investigation Companion\" project (#23365), specifically the \"Automated 3-Snapshot Technique skill\" deliverable.\n\n### Additional context\n\n_No response_",
"number": 23425,
"title": "feat: add three-snapshot memory leak detection utility",
"url": "https://github.com/google-gemini/gemini-cli/issues/23425",
"analysis": "Implement a 'three-snapshot' memory leak detection utility that captures and compares process heap states over time.",
"effort_level": "medium",
"reasoning": "Implementing the three-snapshot utility requires creating a new telemetry module with logic for stateful snapshot tracking, delta calculations, and severity classification. While it uses standard Node.js APIs, it necessitates robust validation and integration into the CLI's lifecycle to ensure accurate reporting without introducing its own overhead, fitting the 1-3 day medium effort profile.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n## Summary\n\nThe Gemini CLI currently tracks heap memory metrics via `v8.getHeapStatistics()` in `MemoryMonitor`, but has no way to capture full V8 heap snapshots (`.heapsnapshot` files) for deep memory analysis. This is a foundational gap \u2014 there are 10+ open OOM crash issues (#16271, #19607, #16356, #14445, etc.) but no built-in tooling to capture the diagnostic data needed to investigate them.\n\n## Proposal\n\nAdd a `captureHeapSnapshot()` utility to `packages/core/src/telemetry/` that:\n\n- Uses `v8.writeHeapSnapshot()` to capture full heap snapshots to disk\n- Returns structured metadata (file path, heap stats at capture time, duration, file size)\n- Provides `formatSnapshotSummary()` for human-readable output\n- Handles errors gracefully (directory creation, write failures)\n- Works cross-platform (Windows, macOS, Linux)\n\n### Why is this needed?\n\n1. **Enables investigation of existing OOM bugs** \u2014 Contributors and maintainers can capture snapshots before/after operations to identify memory leaks\n2. **Foundation for GSoC #23365** \u2014 The \"Terminal-Integrated Performance & Memory Investigation Companion\" project lists \"Automated 3-Snapshot Technique\" as deliverable #1, which requires heap snapshot capture as a prerequisite\n3. **Small, focused, and immediately useful** \u2014 Builds on existing `MemoryMonitor` infrastructure with no breaking changes\n\n\n### Additional context\n\n## Output Format\n\nSnapshots are saved as `.heapsnapshot` files loadable in Chrome DevTools (Memory tab), making them immediately useful without additional tooling.",
"number": 23422,
"title": "feat: add V8 heap snapshot capture utility for memory diagnostics",
"url": "https://github.com/google-gemini/gemini-cli/issues/23422",
"analysis": "Add a diagnostic utility to capture and save V8 heap snapshots for memory usage analysis.",
"effort_level": "small",
"reasoning": "The task involves implementing a localized utility function that wraps the built-in Node.js 'v8' module. It requires basic filesystem operations and metadata formatting, which is straightforward and constrained to a single module, fitting the criteria for a small effort level.",
"recommended_implementation": "Add a subcommand to `debugCommand.ts` (or a new `/debug` handler) that imports `v8` from `node:v8` and executes `v8.writeHeapSnapshot(path.join(storage.getProjectTempDir(), 'heap.heapsnapshot'))`.",
"validated": true
},
{
"body": " ## Summary\n\n ACP restore commands currently lack direct unit tests for key success and failure paths in:\n\n - `packages/cli/src/acp/commands/restore.ts`\n\n This creates risk for regressions in checkpoint restore/list behavior and user-facing error messages.\n\n ## Problem\n\n `RestoreCommand` and `ListCheckpointsCommand` include multiple branches that are easy to break without explicit\n tests, including:\n\n - checkpointing disabled handling\n - missing checkpoint file handling (`ENOENT`)\n - invalid/corrupt checkpoint data handling\n - restore stream result formatting\n - fallback/unexpected error handling\n - checkpoint listing and formatting behavior\n\n ## Proposed Solution\n\n Add a dedicated test suite:\n\n - `packages/cli/src/acp/commands/restore.test.ts`\n\n Cover these scenarios:\n\n ### RestoreCommand\n - Delegates to list behavior when invoked without args\n - Returns checkpointing-disabled message\n - Returns file-not-found message for missing checkpoint\n - Returns invalid/corrupt checkpoint message when schema parse fails\n - Formats streamed restore results (`message`, `load_history`, fallback object)\n - Returns generic unexpected error message for non-ENOENT failures\n\n ### ListCheckpointsCommand\n - Returns checkpointing-disabled message\n - Returns `No checkpoints found.` when no `.json` checkpoints exist\n - Formats checkpoint summary output from checkpoint metadata\n - Returns generic unexpected error message on failures\n\n ## Acceptance Criteria\n\n - New restore ACP test file exists and runs successfully.\n - All branches above are explicitly asserted.\n - Command output strings remain stable and verified by tests.\n - No production/runtime code changes are required for this issue.\n\n ## Validation\n\n Run:\n\n - `npm run build --workspace @google/gemini-cli-core`\n - `npm run test --workspace @google/gemini-cli -- src/acp/commands/restore.test.ts`\n\n Expected: restore ACP tests pass.\n\n ## Related PR\n\n Related to #23400 \n\n",
"number": 23402,
"title": "test(ACP): Add missing unit coverage for restore command flows",
"url": "https://github.com/google-gemini/gemini-cli/issues/23402",
"analysis": "Implement missing unit test coverage for the ACP (Agent-to-Agent) session restoration and 'restore' command flows.",
"effort_level": "small",
"reasoning": "The task involves adding unit test coverage for a single command file. The logic in restore.ts is straightforward, and a significant portion of the test suite is already implemented in the provided context. Completing the remaining test cases for error branches and the generator flow is a highly localized task that can be completed within a single day.",
"recommended_implementation": "Create or update `packages/core/src/code_assist/server.test.ts` to include test scenarios that trigger the `restore` command and verify that the agent state (history, context) is correctly re-hydrated.",
"validated": true
},
{
"body": "### Summary\nJetBrains IDEs are already partially supported in `detect-ide.ts`, but there are gaps in **runtime robustness, user-facing messaging, and installation guidance**.\n\nThis issue proposes improvements to make JetBrains detection reliable, non-blocking, and user-friendly.\n\n---\n\n### Current State\n- JetBrains IDEs are defined in `IDE_DEFINITIONS`\n- `isJetBrains()` detects `TERMINAL_EMULATOR=JetBrains-JediTerm`\n- `verifyJetBrains()` refines IDE via process inspection\n- Unit tests already cover detection logic\n\n---\n\n### Problems\n\n1. **Potential CLI hang**\n - `getIdeProcessInfo()` may block during process traversal\n - No timeout \u2192 risk of TUI freeze (see related issues like #21477)\n\n2. **Outdated user-facing messages**\n - JetBrains IDEs not consistently listed in supported IDE messages\n\n3. **No installer guidance**\n - Falls back to generic \u201cNo installer available\u201d message\n - No direction to JetBrains Marketplace plugin\n\n---\n\n### Proposed Changes\n\n#### 1. Detection Robustness\n- Add timeout (e.g., 2s) for process-based detection\n- Wrap `getIdeProcessInfo()` in `Promise.race`\n- Ensure CLI never blocks on IDE detection\n\n#### 2. Messaging Improvements\n- Update all IDE-related error/help messages to include:\n - \u201cJetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc.)\u201d\n\n#### 3. JetBrains Installer Support\n- Add `JetBrainsInstaller` class\n- Provide:\n - Clear message\n - Link to JetBrains Marketplace plugin\n- Replace generic fallback installer\n\n---\n\n### Expected Outcome\n- No CLI hangs during IDE detection\n- Accurate JetBrains IDE recognition in `/ide status`\n- Improved UX with clear guidance for JetBrains users\n- Foundation for future multi-IDE integration work\n\n---\n\n### Testing Plan\n- Ensure existing `detect-ide` tests pass\n- Add:\n - Timeout handling test in `ide-client.test.ts`\n - JetBrains installer test in `ide-installer.test.ts`\n\n---\n\n### Willing to Contribute\nI\u2019d like to work on this and submit a PR implementing these improvements.",
"number": 23392,
"title": "## \ud83d\ude80 Improvement: JetBrains IDE Detection \u2013 Robustness & UX Enhancements",
"url": "https://github.com/google-gemini/gemini-cli/issues/23392",
"analysis": "Improve the robustness and accuracy of JetBrains IDE detection logic across Windows, macOS, and Linux to provide a better onboarding experience for extensions.",
"effort_level": "medium",
"reasoning": "The task involves implementing a timeout for process traversal to prevent CLI hangs, which falls under asynchronous control flow management. Additionally, it requires refining detection logic for multiple JetBrains products and updating UI messaging/guidance, necessitating logic tracing and integration across the detection utility and user-facing CLI components.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nHave a command, feature to use gemini cli from remote, like telegram, etc. Basically same `gemini-cli-core` package is enough to do this very easily and just get started.\n\n### Why is this needed?\n\nThis helps me use it when I am not at home and even let non-techy people like my mom interact with it. Also let me accomplish stuff better randomly rather than having having necessity to be in front of laptop. Also its fun having something running persistently.\n\n### Additional context\n\nI built out a working version of it few weeks back and has been quite good (https://x.com/0xlord_forever/status/2035135484406681751?s=20), would like to see something here soon. ",
"number": 23373,
"title": "Allowing remote use of Gemini CLI through telegram, etc.",
"url": "https://github.com/google-gemini/gemini-cli/issues/23373",
"analysis": "Implement a remote interface (e.g., Telegram Bot API) to allow interacting with the Gemini CLI agent from mobile devices or external chat applications.",
"effort_level": "large",
"reasoning": "Implementing a remote interface like Telegram requires a significant architectural shift from a terminal-based CLI to a persistent service model. It involves creating a new adapter layer to map external API events to the agent's internal logic, managing persistent state across sessions, and handling external network protocols (webhooks/long-polling), which constitutes a major subsystem implementation.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA new user friendly command when someone selects something on the CLI's TUI, to copy terminal friendly command in line. \nFlow can be, I select multi line terminal command carelessly, and there is a button lets say `C` which I can press after copying which would lead to copying of the command inline and directly pastable and executable on different shell.\n\n\n### Why is this needed?\n\nCurrently, if you ask CLI for commands for something, etc, it mostly give them numbered like \n`1 npm run build`\n`2 npm run build`\n\nThese cause issue when someone needs to copy and run them as copying is not possible in big multi line commands due ot use of / as that gets broken and even for single line people have to spend time in carefully cropping the command and copying what they want.\n\n### Additional context\n\nCopying and pasiting critical commands have been quite frustrating UX, would like these things to improve to have better experiece in the CLI.",
"number": 23371,
"title": "Better TUI copy method",
"url": "https://github.com/google-gemini/gemini-cli/issues/23371",
"analysis": "Implement a more user-friendly TUI copy method, such as a dedicated 'Copy Mode' or a keyboard shortcut to copy blocks of code without terminal formatting (borders, line numbers).",
"effort_level": "medium",
"reasoning": "Implementing a user-friendly copy method in an Ink-based TUI requires managing UI state transitions to toggle formatting (like borders and line numbers) or integrating a clipboard utility to programmatically capture specific blocks. This involves logic tracing in the MainContent component, handling keyboard input via hooks, and managing asynchronous clipboard operations, which aligns with the Medium effort criteria for state management and service integration.",
"validated": true
},
{
"body": "## Problem\nCurrently, ENOTDIR filesystem error is not handled explicitly, which can lead to unclear error messages.\n\n## Proposed Solution\nAdd support for ENOTDIR in fsErrorMessages.ts with a user-friendly message.\n\n## Benefit\nImproves clarity when a file is used instead of a directory.",
"number": 23350,
"title": "Improve filesystem error message handling for ENOTDIR Fixes #23350",
"url": "https://github.com/google-gemini/gemini-cli/issues/23350",
"analysis": "Add specialized error message handling for the `ENOTDIR` (Not a directory) system error code in the filesystem utility.",
"effort_level": "small",
"reasoning": "The task is a highly localized string and logic update within a single file (fsErrorMessages.ts). It involves adding a single entry to a static mapping object to handle the ENOTDIR error code, which fits the criteria for trivial logic and content updates.",
"recommended_implementation": "Add an entry for `'ENOTDIR'` to the `errorMessageGenerators` map in `packages/core/src/utils/fsErrorMessages.ts` with a message like 'Path exists but is a file, expected a directory.'",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA `/context` slash command that displays a visual summary of what is consuming the model's context window. The command should show:\n\n- **Segmented usage bar** \u2014 a single horizontal bar with color-coded segments for each category (system prompt, tool schemas, memory files, conversation history), with a compression threshold marker\n- **Remaining tokens headline** \u2014 prominently displays how much room is left, with an estimate of turns remaining at the current average rate\n- **Category breakdown table** \u2014 token counts and percentage of limit for each category (system prompt, tool schemas, memory files, conversation)\n- **Compression threshold indicator** \u2014 shows where on the bar auto-compression kicks in (default 50%)\n\nThe display should be compact (fits on one screen), use accessible colors (avoiding the red-green confusion axis), and derive all data from already-loaded in-memory state (no disk I/O).\n\n### Why is this needed?\n\nUsers currently have no visibility into what is consuming their context window. As sessions get longer, context fills up and eventually triggers compression \u2014 but users can't see this coming or understand what's taking up space. Key use cases:\n\n1. **\"Am I running out of context?\"** \u2014 The remaining-tokens headline and colored bar answer this instantly.\n2. **\"What's consuming my context?\"** \u2014 The breakdown table shows whether it's the system prompt, tools, memory files, or conversation history.\n3. **\"When will compression happen?\"** \u2014 The compression threshold marker and turns-remaining estimate make this predictable.\n\nThis is especially important for power users with large GEMINI.md files, many MCP tools, or long agentic sessions.\n\n### Additional context\n\nInspired by similar functionality in Claude Code's `/context` command, but redesigned with a segmented bar (more space-efficient than a waffle grid), compression threshold visualization, and derived turn estimates. Color scheme uses blue/purple/yellow/cyan mapped to theme tokens for automatic dark/light/ANSI/custom theme compatibility and color-blind accessibility.\n",
"number": 23165,
"title": "feat(cli): add /context command to show context window breakdown",
"url": "https://github.com/google-gemini/gemini-cli/issues/23165",
"analysis": "Implement a new `/context` slash command that displays a detailed breakdown of the current token usage, including system instructions, chat history, and attached files.",
"effort_level": "medium",
"reasoning": "Implementing a new slash command with a multi-part visual UI (segmented bar, table) using Ink requires state synchronization with the chat session's token metrics. While the underlying data exists in the Summarizer and GeminiChat services, formatting the breakdown, calculating estimates like turns remaining, and ensuring the UI fits the compact requirements involves non-trivial logic and component integration across the CLI and service layers.",
"validated": true
},
{
"body": "First, thank you for developing Gemini CLI in the open. The decision to build publicly sets the right foundation for community trust.\n\nHowever, after spending time with the product and conducting a review of the current configuration schemas, command surface, and documentation, I've found a significant accumulation of inconsistencies in naming conventions, command structures, configuration terminology, and documentation accuracy. This materially undermines the developer experience.\n\nI want to be direct about the stakes here: this repository is the storefront for Gemini CLI. It is the first thing a prospective developer or contributor encounters when evaluating whether to invest their time in this tool versus alternatives like Claude Code or Codex CLI. Right now, the experience of navigating the codebase and configuration surface does not inspire confidence and actively raises doubts.\n\nBelow is a summary of the major problem classes I've identified.\n\n### 1. Inconsistent Configuration Terminology and Polarity\n\nSettings related to lists and booleans lack a unified linguistic standard.\n\n- **Allow/Deny vocabulary:** The schema alternates between `allowed`/`exclude` (for tools), `allowed`/`excluded` (for MCP), and `allowed`/`blocked` (for env vars). A single pair of antonyms (e.g., `allow` / `block`) should be chosen and applied uniformly.\n- **Boolean polarity:** The schema mixes positive prefixes (`enableAutoUpdate`), negative prefixes (`disableLoopDetection`), action-based prefixes (`hideWindowTitle`), and no prefixes at all (`general.plan.modelRouting`). Worse, negative flags frequently default to `false` (e.g., `disableLoopDetection: false`), forcing developers to parse double negatives to understand the actual behavior.\n\n### 2. Disjointed Command and Flag Architecture\n\nThe `/` command surface appears to have grown organically without a guiding structural philosophy.\n\n- **Verb-Object vs. Object-Verb:** Commands like `/terminal-setup` coexist with `/setup-github`, with no consistent grammar.\n- **Subcommand synonyms:** Similar lifecycle actions use different verbs depending on the feature: `/extensions restart`, `/mcp refresh`, `/commands reload`. These are semantically identical operations that should share a verb.\n- **Overloaded aliases and subcommands:** Commands like `/tools desc` and `/tools nodesc` would be better served as a single `/tools list` with flags. Similarly, maintaining extensive and subtly diverging documentation for both `/chat` and `/resume` (which are aliases for the same operation) creates unnecessary confusion.\n\n### 3. Naming Convention Mixing Within the Same Context\n\nProperties and enums within the same schema or file alternate between `camelCase`, `snake_case`, and `PascalCase`. For instance, policy schemas mix `toolName` with `deny_message` in the same structure, and approval modes are variously referred to as `autoEdit`, `auto_edit`, `ask_user`, and `default`. There is no defensible reason for different naming conventions to appear side by side in a single context.\n\n### 4. Unclear Hierarchy and Resolution Rules\n\nConfiguration precedence rules are sometimes inverted compared to widely accepted industry conventions. For example, the documentation states that user-level policies take priority over workspace-level policies \u2014 the opposite of the expected behavior where a local (workspace) override narrows or specializes a global (user) default. Additionally, the overlap between `tools.core`, `tools.allowed`, and the policy engine rules leaves users guessing which mechanism is canonical.\n\n### 5. Documentation Drift\n\nMultiple instances exist where documentation has drifted from the implementation:\n\n- `docs/tools/file-system.md` omits the `read_many_files` tool entirely.\n- `docs/reference/policy-engine.md` claims \"policies are organized into three tiers\" but the immediately following table lists five.\n- Stale references to deprecated features (e.g., \"Preview Features\" flag, `yolo` mode) remain in the docs.\n\n### Recommendation\n\nI'd suggest addr
"number": 22980,
"title": "Clean up inconsistent naming conventions, configuration architecture, and documentation to improve developer experience",
"url": "https://github.com/google-gemini/gemini-cli/issues/22980",
"analysis": "Perform a comprehensive cleanup of naming conventions, configuration structures, and internal documentation across the entire monorepo to improve developer ergonomics.",
"effort_level": "large",
"reasoning": "This task involves a comprehensive refactoring of configuration schemas, public-facing CLI commands, and internal naming conventions across the entire monorepo. Because it impacts exported APIs and core configuration architecture, it requires synchronized changes across multiple packages, extensive updates to unit and integration tests to prevent regressions, and a complete overhaul of the documentation. The breadth of the changes and the risk of breaking core functionality across the project align with the criteria for a Large effort level.",
"validated": true
},
{
"body": "- Implement better way to handle schema (agents can be named anything which is probably why we are defining `AGENT_CONFIG_FIELDS` in the UI)\n- Simplify React code and use store pattern\n- Fix bugs as side effect of more simple React (ctrl L etc.)",
"number": 22958,
"title": "Refactor AgentConfigDialog",
"url": "https://github.com/google-gemini/gemini-cli/issues/22958",
"analysis": "Refactor the `AgentConfigDialog` component to improve maintainability and simplify its complex state management.",
"effort_level": "medium",
"reasoning": "Refactoring the AgentConfigDialog involves complex React/Ink state management, transitioning to a store pattern, and implementing dynamic schema validation. This aligns with the Medium criteria as it requires logic tracing for UI state synchronization (e.g., focus and input buffers) and adjustments to validation logic across multiple sub-components.",
"validated": true
},
{
"body": "### Description\\nAs discussed in PR #22718, when an MCP server is configured exclusively for a subagent, its tools are registered in a subagent-specific isolated `ToolRegistry`. However, the `/mcp list` command currently retrieves tools only from the main, global `ToolRegistry`.\\n\\nAs a result, `/mcp list` correctly shows the subagent's MCP server as 'Connected', but the tools from that server are missing from the list of active tools.\\n\\n### Proposed Solution\\nRefactor the tool aggregation in the `/mcp list` action. Update `McpClientManager` and `McpClient` to expose all discovered tools across all of their `registeredRegistries`, so the interactive command can accurately display the active tools regardless of which registry they reside in.",
"number": 22884,
"title": "UX: `/mcp list` in interactive mode does not show tools from subagent-specific MCP servers",
"url": "https://github.com/google-gemini/gemini-cli/issues/22884",
"analysis": "Fix the issue where `/mcp list` only shows tools from global MCP servers, ignoring those specifically attached to active subagents.",
"effort_level": "medium",
"reasoning": "The fix requires logic tracing and integration across multiple components, specifically the CLI command layer and the core McpClientManager/McpClient logic. It involves refactoring how tools are aggregated from multiple registries (global and subagent-specific), which falls under the Medium criteria for service integration and state synchronization across components.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nSkills, hooks, and custom commands all auto-discover impls from the current workspace:\n\n* https://geminicli.com/docs/cli/skills/#skill-discovery-tiers\n* https://geminicli.com/docs/hooks/#configuration\n* https://geminicli.com/docs/cli/custom-commands/#file-locations-and-precedence\n\nHowever, Gemini CLI extensions must be `gemini extensions link .` and then they are applied globally.\n\nI know there is a trick to disable the globally installed extension globally while enable for the current workspace only. But it would be better to auto-discover extensions, said from `.gemini/extensions` from the current working directory or workspace.\n\n### Why is this needed?\n\nDescribed above.\n\n### Additional context\n\n_No response_",
"number": 22743,
"title": "Discover extensions under the current workspace",
"url": "https://github.com/google-gemini/gemini-cli/issues/22743",
"analysis": "Enable automatic discovery of extensions located within the current workspace (e.g., in a `.gemini/extensions` folder).",
"effort_level": "medium",
"reasoning": "Implementing workspace-relative extension discovery requires modifying the ExtensionLoader to include new filesystem search paths and path resolution logic. It also necessitates a trust-check mechanism for local code execution to ensure security, which involves logic tracing and integration across the configuration and extension loading subsystems, fitting the criteria for logic tracing and filesystem/path resolution.",
"validated": true
},
{
"body": "The Config class currently has a placeholder implementation for getCustomExcludes. This issue tracks implementing the method properly and exposing a new customExcludePatterns setting in the configuration to allow users to define additional glob patterns for file exclusion.",
"number": 22729,
"title": "Implement getCustomExcludes and expose customExcludePatterns setting",
"url": "https://github.com/google-gemini/gemini-cli/issues/22729",
"analysis": "Implement a `customExcludePatterns` setting to allow users to define project-specific file patterns that should be ignored by all tools.",
"effort_level": "small",
"reasoning": "The task involves adding a new field to the configuration schema (likely a Zod schema) and implementing a simple getter method in the Config class. The core logic for consuming these patterns is already present in the FileExclusions class, which currently uses a placeholder. This is a localized configuration update that fits the 'Trivial Logic/Config' criteria.",
"recommended_implementation": "Add `context.customExcludePatterns` (string array) to `settingsSchema.ts`. Update the `getIgnoreFilter` function in `ignorePatterns.ts` to merge these user patterns with the default excludes.",
"validated": true
},
{
"body": "Components throughout the codebase have stale closures, useEffects that could be derived or put into event handlers, state that could be derived, and dialogs that should use useSettingsStore or do not use it in the best way",
"number": 22666,
"title": "Stale closures, excessive effect and state, unideal use of useSettingsStore",
"url": "https://github.com/google-gemini/gemini-cli/issues/22666",
"analysis": "Deep refactor of the React-based TUI layer to fix stale closures, optimize `useEffect` usage, and reduce unnecessary re-renders in `AppContainer`.",
"effort_level": "large",
"reasoning": "The issue describes a deep, foundational refactor of the React-based TUI layer across the entire codebase. Addressing stale closures, optimizing state/effect patterns, and resolving race conditions in the terminal event loop involves complex state synchronization and architectural cleanup that exceeds the scope of localized fixes, fitting the criteria for a major subsystem overhaul.",
"validated": true
},
{
"body": "### What happened?\n\nUI: Need expand/collapse feature for Pasted Text and Image chips to prevent context contamination\n When I paste more than 10 lines of text or attach an image, the input area automatically collapses the content into a \"chip\" (e.g., [Pasted Text: 15 lines]).\n \nThere is currently no way to expand, preview, or verify this content before sending it. This leads to accidental \"context contamination\" because I cannot be sure if I'm\n sending the correct logs or clipboard data.\n\n### What did you expect to happen?\n\n expect a way to toggle the expansion of these chips (e.g., by hitting Tab or clicking them) so I can verify the content before committing the prompt. At the very least,\na preview of the first few lines should be visible.\n\n\n### Client information\n\n\n* **CLI Version:** 0.33.1\n* **Git Commit:** f59f9e931\n* **Session ID:** 3e6238f1-1b0a-46f2-97fb-246facf62e0b\n* **Operating System:** darwin v25.8.1\n* **Sandbox Environment:** no sandbox\n* **Model Version:** gemini-3-flash-preview\n* **Auth Type:** gemini-api-key\n* **Memory Usage:** 1.69 GB\n* **Terminal Name:** iTerm2 3.6.9\n* **Terminal Background:** #264456\n* **Kitty Keyboard Protocol:** Supported\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 22651,
"title": "UI: Need expand/collapse feature for Pasted Text and Image chips to prevent context contamination",
"url": "https://github.com/google-gemini/gemini-cli/issues/22651",
"analysis": "Add an expand/collapse feature for large pasted text blocks and image chips in the chat history to improve TUI readability.",
"effort_level": "medium",
"reasoning": "Implementing an expand/collapse toggle in an Ink-based TUI requires managing component state for visibility and handling keyboard/focus events to trigger the toggle. This falls under React/Ink state management and UI synchronization, as it involves modifying the input buffer rendering and potentially the message content components to handle interactive previews without disrupting the terminal layout.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nFeature hasn't been suggested before.\n\nI have verified this feature I'm about to request hasn't been suggested before.\nDescribe the enhancement you want to request\nCurrently, gemini automatically generates a session ID when starting a new session. While this works well, it makes it difficult to organize or intentionally resume sessions for specific projects.\n\nI would like to request support for manually specifying a session ID when launching gemini, similar to how OpenClaw allows custom session identifiers.\n\nExample:\n\nopencode --session my-project\n\nWith this feature, users could:\n\nStart a session with a meaningful name\nResume the same session later using the same session ID\nOrganize multiple projects more easily\nAvoid relying only on auto-generated session IDs\nExample workflow:\n\nStart a session:\ngemini --session my-project\n\nLater resume the same session:\ngemini --resume my-project\n\n### Why is this needed?\n\nBenefits:\n\nBetter project-based session organization\nEasier session recovery\nMore predictable workflows when using gemini for multiple tasks\nImproved scripting and automation possibilities\nThis feature would be especially useful for developers who use gemini across multiple repositories or long-running development sessions.\n\nIf session IDs are currently auto-generated internally, this could potentially be implemented as an optional override flag while keeping the current default behavior unchanged.\n\n### Additional context\n\n_No response_",
"number": 22644,
"title": "[FEATURE]: Allow custom session ID when starting google-gemini -CLI(e.g., --session my-project)",
"url": "https://github.com/google-gemini/gemini-cli/issues/22644",
"analysis": "Add a `--session <id>` command-line flag to allow users to start the CLI with a specific, named session ID instead of a random UUID.",
"effort_level": "small",
"reasoning": "Adding a CLI flag to override a session ID is a straightforward configuration change. Since the session ID is already a parameter in the Config class, this task only requires updating the CLI argument parser (e.g., commander) and passing the value to the session initialization logic, fitting the criteria for a localized logic/config update.",
"recommended_implementation": "Add the `session` option to the Yargs config in `packages/cli/src/config/config.ts`. In `gemini.tsx`, pass this value to the `Config` constructor instead of allowing it to generate a random UUID.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI wanna add a feature through which we would be able to preview mermaid diagrams.\nWhile exploring and testing gemini cli, I\u2019ve realized that right now it can generate mermaid code and give an ASCII representation in the terminal but there is no way to visualize that diagram. I have also noticed that cli was trying to find mermaid related tools and documentation but could not find any so it had to give the result in text format only(I\u2019ll attach the screenshots). The solution I came up with is to add a command that let\u2019s you preview the generated mermaid code and in its diagram using [mermaid.js](http://mermaid.js/) in the browser.\nIdea:\n1. CLI generates mermaid code.\n2. Temporary html file would be created by mermaid.js.\n3. Preview automatically opens in browser.\n\n### Why is this needed?\n\nWhen cli generates architecture diagrams, visual represenstation is generally much easier to understand than the mermaid code. Right now to visualize it we need to open another tool (for example: mermaid viewer) which disturbs the workflow. If we can have a quick review option directly from cli, it would be much easier.\n\n### Additional context\n\nAs I was exploring and testing CLI, I gave it some prompts like \u201cGenerate the mermaid code for authentication\u201d and \u201cCan you draw the diagram for me using this code\u201d. Both gave me the result(I\u2019m attaching the screenshots below). The code was in structured way but the representation was in ASCII.\n\n<img width=\"1614\" height=\"816\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/67e65a72-c56e-4883-90c2-bb9a41a2b32f\" />\n\n<img width=\"1615\" height=\"794\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/fa8472db-3763-4423-b5ee-2db4a25b0061\" />\n\n<img width=\"1618\" height=\"719\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/386de92a-74b7-4ebf-b4f3-ccbd3ab38b7e\" />\n\n<img width=\"1345\" height=\"583\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/17e7a0f6-8360-4e26-b34f-8f869f8c1786\" />\nAs a result we can add a small feature like a command(example /diagram-preview) to preview it.\nIf maintainers are interested I would be happy to work on this. You can also give me some suggestions on it.",
"number": 22627,
"title": "Feature request: Mermaid diagram preview for generated mermaid code",
"url": "https://github.com/google-gemini/gemini-cli/issues/22627",
"analysis": "Implement a preview mechanism for Mermaid diagrams generated by the model.",
"effort_level": "medium",
"reasoning": "Implementing a Mermaid preview requires adding logic to detect specific code blocks within the model's output, managing temporary filesystem resources for the HTML generation, and integrating with a browser-opening utility. This involves asynchronous flow management and service integration that goes beyond simple UI tweaks but does not reach the architectural complexity of core protocol changes.",
"validated": true
},
{
"body": "## Problem\n\nWhen users want to explore two directions from the same conversation point, the only option is `--resume` in a second terminal. However, `--resume` shares the **same session file** \u2014 both processes write via `fs.writeFileSync()` with no locking, so last-write-wins silently corrupts the persisted session.\n\n## Proposed Solution\n\nAdd a `/fork` slash command that:\n\n1. Reads the current `ConversationRecord` from `ChatRecordingService`\n2. Creates a **new file** with a **new session ID** in `~/.gemini/tmp/<project_hash>/chats/`\n3. Prints the fork's short ID so the user can `--resume` it in another terminal\n\nBoth sessions are fully independent \u2014 no write conflicts, no data loss.\n\n```\n> /fork\nFork saved (a1b2c3d4).\nResume with: gemini --resume a1b2c3d4\nOr browse sessions with: /chat\n```\n\n## Use Cases\n\n- **Explore a risky path:** Fork before a large refactor \u2014 if it goes wrong, the original session is untouched\n- **Compare approaches:** Resume the fork in another terminal to try a different direction\n- **Hand off a sub-task:** Fork so a separate window handles a parallel workstream\n\n## Implementation Notes\n\n- Pure CLI command \u2014 no changes to `packages/core` needed\n- Composes well with existing commands: `/fork` + `/rewind` lets you preserve state then rewind, `/chat` lists forks alongside regular sessions\n- Analogous to Claude Code's `/fork` command\n\n## Scope\n\n- `packages/cli/src/ui/commands/forkCommand.ts` \u2014 command implementation\n- `packages/cli/src/services/BuiltinCommandLoader.ts` \u2014 registration\n- `docs/cli/fork.md` \u2014 user-facing docs\n- Unit tests",
"number": 22563,
"title": "feat: add /fork command for session branching",
"url": "https://github.com/google-gemini/gemini-cli/issues/22563",
"analysis": "Implement a `/fork` command that creates a new, independent session starting with the history of the current one.",
"effort_level": "medium",
"reasoning": "Implementing the /fork command requires integrating logic across the SlashCommandService and ChatRecordingService. It involves asynchronous file system operations to duplicate session records, generating new session IDs, and ensuring state consistency between the current memory-resident conversation and the new persisted file. This falls under the medium category as it involves service integration and asynchronous flow management.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n### Batch confirmation for multi-file edits\n\nWhen Gemini CLI proposes fixes that involve modifying multiple files, the CLI currently asks for confirmation for each file individually.\n\nExample workflow:\n\nModify file1? (y/n)\nModify file2? (y/n)\nModify file3? (y/n)\n\nWhen an agent proposes edits across several files, the user must repeatedly confirm each edit. This can slow down the workflow and interrupt the developer experience, especially when the changes are part of the same logical fix.\n\nProposed enhancement:\n\nAllow Gemini CLI to display a summary of all file edits and provide a single confirmation prompt.\n\nExample:\n\n3 files will be modified:\n\n* frontend/config.ts\n* backend/server.js\n* frontend/api.ts\n\nApply all changes? (y/n)\n\nOptionally, the CLI could still allow users to preview diffs before applying the edits.\n\nThis would make multi-file fixes faster while keeping the user fully aware of the changes being applied.\n\n\n### Why is this needed?\n\nEditing files is one of the most common tasks performed through Gemini CLI. When an agent suggests fixes that span multiple files (for example when fixing deployment configuration or API endpoint mismatches), the current per-file confirmation workflow can become slow and repetitive.\n\nDuring a recent debugging session in a project, the agent identified fixes across several files. However, confirming each edit individually added unnecessary friction to the workflow.\n\nProviding a batch confirmation option would:\n\n* Reduce repetitive prompts when applying related edits\n* Improve developer workflow efficiency\n* Keep users fully informed about which files will be modified\n* Align with the goal of making editing behavior predictable and user-friendly\n\nThis enhancement focuses on improving the user experience while maintaining the safety of explicit user approval before file modifications occur.\n\n\n### Additional context\n\nEnvironment\nOS: Ubuntu Linux\nGemini CLI Version: v0.35.0-nightly",
"number": 22510,
"title": "Feature: Batch confirmation for multi-file edits",
"url": "https://github.com/google-gemini/gemini-cli/issues/22510",
"analysis": "Add a batch confirmation feature that allows users to approve all pending tool calls (e.g., multiple file edits) with a single interaction.",
"effort_level": "medium",
"reasoning": "Implementing batch confirmation requires modifying state management in the CLI's Ink components to aggregate pending tool calls and updating the core ConfirmationBus to handle bulk approval signals. This involves logic tracing across packages and managing asynchronous UI states, which fits the criteria for medium effort.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nCurrently, Gemini CLI is a pull-based system where extension code and hooks only execute during an active agent turn. When the agent is idle at the interactive terminal prompt, there is no native mechanism to \"wake up\" the agent or inject a prompt from an external event (e.g., a message queue, a webhook, or a mobile companion app) without manual user interaction (pressing Enter).\n\n\n Problem:\n Developers building advanced integrations (like mobile companions or long-running monitoring tools) must rely on inefficient and fragmented workarounds:\n 1. External Watchers: Polling an external source and spawning new gemini --resume headless processes. This creates session isolation issues where the original interactive terminal does not update its state or history in real-time.\n 2. Long-Polling Hooks: Implementing AfterAgent hooks that spin in a loop. This risks hitting CLI timeouts, blocks terminal input, and is brittle when trying to chain multiple autonomous interactions.\n\n\n Suggested Direction:\n We need a first-class \"trigger\" mechanism that allows an external process to notify an active Gemini CLI session to start a new turn. Possible implementations could include:\n - Signal Handling: Allowing the CLI to respond to a specific POSIX signal (e.g., SIGUSR1) to reload the transcript and start a new turn.\n - Discovery Pipe/Socket: Providing a local socket or named pipe that an external process can write to, which the CLI monitors while idle.\n - Lifecycle Enhancement: A periodic IdleHeartbeat hook that runs with low overhead to check for external instructions.\n\n### Why is this needed?\n\nThis would enable truly \"Hands-Free\" and \"Remote-Steering\" workflows. It allows Gemini to act as a responsive background agent that can be redirected by IDE events, mobile apps, or automated CI/CD triggers without requiring a human to be physically present at the terminal to press Enter.\n\n### Additional context\n\nWe recently developed a Companion Hub for a QA extension that bridges a mobile device to the CLI. We had to build a complex system of background watchers and high-performance \"pivot\" hooks to simulate responsiveness, which highlighted the need for a native asynchronous interaction model.\n\nThis might have some overlap with https://github.com/google-gemini/gemini-cli/issues/21869",
"number": 22370,
"title": "Support for Asynchronous \"Push\" Triggers / External Wake-up for Idle Agent Sessions",
"url": "https://github.com/google-gemini/gemini-cli/issues/22370",
"analysis": "Support asynchronous 'push' triggers that can wake up an idle agent session from an external source, such as an MCP server notification or a webhook.",
"effort_level": "large",
"reasoning": "This task requires a fundamental architectural shift from a pull-based interaction model to a push-based one. It involves implementing a persistent background listener (IPC or socket-based), modifying the core AgentScheduler to handle externally triggered turns, and managing complex state synchronization within the Ink-based InteractiveCli to ensure the UI updates correctly when an external event occurs while the user is idle. This aligns with the criteria for major architectural changes and subsystem modifications.",
"validated": true
},
{
"body": "### What would you like to be added?\r\n\r\nAllow `settings.json` to parse and inject Environment Variables natively when loading configurations.\r\n\r\n**Example usage in settings.json:**\r\n```json\r\n{\r\n \"api_key\": \"${GEMINI_DEV_KEY}\",\r\n \"ui\": {\r\n \"theme\": \"${GEMINI_CLI_THEME:-dark}\"\r\n }\r\n}\r\n```\r\n\r\n### Why is this needed?\r\n\r\nCurrently, for users to change API keys natively per-workspace, they may be forced to hardcode them in the workspace `settings.json` if they don't want to use the global env var. This is dangerous, and users frequently push these override files to public repositories by accident.\r\n\r\nBy expanding env variable interpolations natively inside the settings loader:\r\n- Teams can commit `settings.json` to source control to share common workspace tools/rules.\r\n- Sensitive overrides can be deferred to local environment managers natively context-by-context.\r\n- Creates parity with standard IDE settings frameworks.\r\n\r\n### Suggested File Paths / Context\r\n- `packages/core/src/config/settings-loader.ts` (inject a regex replace filter after JSON parsing)\r\n- `packages/core/src/config/settings.ts`",
"number": 22288,
"title": "Feature Request: Environment Variable expansion and injection inside settings.json",
"url": "https://github.com/google-gemini/gemini-cli/issues/22288",
"analysis": "Enable environment variable expansion (e.g., `${VAR_NAME}`) for all string values within the `settings.json` configuration file.",
"effort_level": "small",
"reasoning": "The core logic for environment variable expansion is already implemented in the provided envVarResolver.ts utility. The task only requires integrating this existing function into the settings loading pipeline within the config module and adding corresponding unit tests, which is a highly localized and straightforward change.",
"recommended_implementation": "In `loadSettings` (packages/cli/src/config/settings.ts), after parsing the JSON but before validation, pass the settings object through `resolveEnvVarsInObject()`.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWhen using an MCP server that requires interactive user input (elicitation), the Gemini CLI fails with a \"Method not found\" error. This prevents the use of servers designed for conversational data collection or multi-step tasks that require the client to handle feedback.\n\n## MCP Elicitation Protocol \n\nhttps://modelcontextprotocol.io/specification/2025-11-25/client/elicitation\n\n## Steps to Reproduce:\n1. Configure an MCP server that uses the Elicitation pattern (e.g., using fastmcp or the example at https://gofastmcp.com/servers/elicitation\n2. Run a tool that triggers a request for user information (e.g., mcp_test_collect_user_info).\n3. The CLI attempts to execute the tool but immediately fails with a protocol error.\n\n```\n \u259d\u259c\u2584 Gemini CLI v0.33.1\n \u259d\u259c\u2584\n \u2597\u259f\u2580 Logged in with Google /auth\n \u259d\u2580 Gemini Code Assist /upgrade\n\n\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\n > /mcp list \n\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\u2584\nConfigured MCP servers:\n\n\ud83d\udfe2 test - Ready (1 tool)\n Tools:\n - mcp_test_collect_user_info\n\n\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u2580\u
"number": 22249,
"title": "[MCP] \"Method not found\" error when using tools with Elicitation support",
"url": "https://github.com/google-gemini/gemini-cli/issues/22249",
"analysis": "Resolve the 'Method not found' error occurring during MCP tool calls that involve Gemini's elicitation (user-clarification) flow.",
"effort_level": "large",
"reasoning": "Implementing MCP Elicitation support requires adding server-to-client request handling, which is a significant protocol addition to the current MCP integration. This involves complex state management to pause tool execution, transition the Ink-based UI to an interactive input state, and route user feedback back through the transport layer. According to the criteria, modifications to MCP integrations and handling complex asynchronous flows across major subsystems qualify as Large effort.",
"validated": true
},
{
"body": "### What happened?\n\nThe current logging implementation in the SDK session module does not use a structured or standardized logger interface. Instead, logging appears to rely on ad-hoc logging calls embedded directly within session logic.\n\nThis creates several issues:\n\n- Logging behavior is inconsistent across modules.\n- Logging cannot be easily redirected to telemetry systems.\n- Logging levels cannot be centrally managed.\n- Logging is difficult to mock or test during unit testing.\n\nThe issue is referenced in the codebase with the following TODO:\n\n```ts\n// TODO: refactor this to use a proper logger interface\nFile location:\n\npackages/sdk/src/session.ts\n```\nBecause the logging logic is tightly coupled with session management, extending or modifying logging behavior becomes difficult and increases technical debt.\n\n### What did you expect to happen?\n\nThe SDK session module should use a structured and centralized logger interface instead of ad-hoc logging calls scattered throughout the code.\n\nExpected behavior:\n\n- Logging should be handled through a standardized `Logger` abstraction.\n- All modules should rely on the same logger interface for consistent logging behavior.\n- Logging levels (`info`, `warn`, `error`, `debug`) should be configurable.\n- The logger should be injectable to allow different implementations (console logger, telemetry logger, file logger).\n- Logging should be easily mockable in unit tests.\n\nExample of the expected architecture:\n\n```ts\ninterface Logger {\n info(message: string, metadata?: Record<string, unknown>): void\n warn(message: string, metadata?: Record<string, unknown>): void\n error(message: string, metadata?: Record<string, unknown>): void\n}\n```\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n - Windows 11\n - macOS\n```\n\n</details>\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 22184,
"title": "# [BUG Report] Logger Architecture Needs Refactor",
"url": "https://github.com/google-gemini/gemini-cli/issues/22184",
"analysis": "Perform a major refactor of the logging architecture to provide a more consistent, extensible, and performant observability layer.",
"effort_level": "large",
"reasoning": "Refactoring the logging architecture is a cross-cutting architectural change that involves defining a new standardized interface and implementing a provider-based pattern for different sinks (telemetry, file, TUI). As noted in the previous analysis, this requires updating hundreds of call sites across multiple packages and modifying core primitives in the core package, fitting the criteria for a major subsystem overhaul.",
"validated": true
},
{
"body": "**Location:** `packages/cli/src/ui/components/ThemeDialog.tsx`\n\n### Description\nThe `ThemeDialog` component is responsible for rendering the theme selection interface and preview pane in the terminal UI. Currently, the layout calculations inside this component rely on several hardcoded numeric values (commonly referred to as *magic numbers*) to determine dimensions, spacing, and alignment.\n\n- `PREVIEW_PANE_WIDTH_PERCENTAGE = 0.55`\n- `PREVIEW_PANE_WIDTH_SAFETY_MARGIN = 0.9`\n- `TOTAL_HORIZONTAL_PADDING = 4`\n- `DIALOG_PADDING = 2`\n\nThese values are defined directly within the component logic rather than being centralized in a shared configuration or layout system. Additionally, some of these constants are accompanied by comments indicating that they act as temporary workarounds. For example, the safety margin value (`0.9`) is described in the code as a hack used to prevent text from touching the preview pane border.\n\nEmbedding such layout values directly within the component tightly couples UI structure with specific numeric assumptions. As a result, the layout logic becomes harder to interpret and maintain.",
"number": 22130,
"title": "[UI] Refactor Hardcoded Layout Constants in ThemeDialog",
"url": "https://github.com/google-gemini/gemini-cli/issues/22130",
"analysis": "Refactor the hardcoded layout constants and magic numbers in the `ThemeDialog` component to use shared theme values.",
"effort_level": "small",
"reasoning": "This task is a localized static refactoring of UI constants within a single file (ThemeDialog.tsx). It involves extracting magic numbers into constants or a shared theme configuration, which aligns with the criteria for small effort tasks such as UI/aesthetic adjustments and static refactoring.",
"recommended_implementation": "Extract values like `DIALOG_WIDTH` and `PADDING` to the top of the file or import them from `packages/cli/src/ui/semantic-colors.js`.",
"validated": true
},
{
"body": "## Problem\n\nWhen running `gemini -p \"...\" --output-format stream-json` with a thinking-capable model (e.g. Gemini 2.5 Pro), all `Thought` events emitted by the model are silently dropped. Developers building integrations on top of the non-interactive CLI have no way to observe the model's reasoning process.\n\nThe interactive UI already handles thinking events (`useGeminiStream.ts`), but the non-interactive stream-json path had no corresponding support.\n\n## Proposed Solution\n\n- Add a `THINKING = 'thinking'` event type to `JsonStreamEventType` in `packages/core/src/output/types.ts`\n- Add a `ThinkingEvent` interface (`content: string`, `subject?: string`) to the stream event type union\n- Handle `GeminiEventType.Thought` in the non-interactive response loop (`nonInteractiveCli.ts`) to emit structured `thinking` events when using `--output-format stream-json`\n\n## Example output (stream-json)\n\n```jsonl\n{\"type\":\"thinking\",\"timestamp\":\"...\",\"content\":\"**Analysis** Let me think through this step by step...\",\"subject\":\"Analysis\"}\n```\n\n## Impact\n\nNo breaking changes. The `thinking` event is additive \u2014 consumers that don't handle it can ignore it. Consumers that want model reasoning now have a structured way to access it.",
"number": 22083,
"title": "feat(cli): expose model thinking events in --output-format stream-json",
"url": "https://github.com/google-gemini/gemini-cli/issues/22083",
"analysis": "Expose the model's internal 'thinking' process events in the `--output-format stream-json` mode for better transparency in headless execution.",
"effort_level": "small",
"reasoning": "The task is highly localized, requiring updates to a type definition and a single event handling loop in the non-interactive CLI. It follows existing patterns for JSON streaming and does not involve complex state management or architectural changes, fitting the criteria for a small effort level.",
"recommended_implementation": "In `useGeminiStream.ts`, update the `stream-json` emitter to check for parts with the `thought: true` flag (or equivalent from the API) and include their content in the output chunk.",
"validated": true
},
{
"body": "### What would you like to be added?\nAdd `remove <path>` and `clear` subcommands to the existing `/directory` (alias `/dir`) command. \n- `/directory remove <path>`: Should remove a specific directory from the current workspace context.\n- `/directory clear`: Should remove all manually added directories from the current session.\n\n### Why is this needed?\nConsider this use case: A user is working on Project X but needs to refer to Project Y for context. They use `/directory add project-y`. Once the reference is complete, the user wants to remove Project Y to focus exclusively on Project X.\n\nWithout a `remove` subcommand, Project Y stays in the workspace context for the entire session. This creates a risk: if the user's instructions aren't perfectly scoped, the model might accidentally perform edits or reads in Project Y. Currently, the only way to 'clean' the workspace is to start a brand new session, which is a poor user experience.\n\n### Additional context\nThe implementation should mirror the logic in `packages/cli/src/ui/commands/directoryCommand.tsx`, ensuring that the `WorkspaceContext` is updated and changes are reflected in the session recording.\n",
"number": 22019,
"title": "feat(cli): add 'remove' and 'clear' subcommands to '/directory' command",
"url": "https://github.com/google-gemini/gemini-cli/issues/22019",
"analysis": "Extend the `/directory` command with new `remove <path>` and `clear` subcommands to allow better management of the active workspace context.",
"effort_level": "small",
"reasoning": "This task is a localized extension of an existing command. It involves adding two subcommands ('remove' and 'clear') to the '/directory' handler and implementing the corresponding logic in the DirectoryManager. Since the infrastructure for directory management and command parsing is already in place, this is a straightforward logic update constrained to 1-2 files.",
"recommended_implementation": "Add `directoryRemoveCommand` and `directoryClearCommand` to the subcommands array in `packages/cli/src/ui/commands/directoryCommand.ts`. The actions should call `config.removeIncludedDirectory()` or `config.clearIncludedDirectories()`.",
"validated": true
},
{
"body": "#### Problem\nGemini CLI supports running commands in the background via `ShellTool`, but background process state (PID, command, status) appears to be tracked only in memory during the active CLI session.\n\nWhen the CLI exits or restarts, previously started background tasks cannot be rediscovered or managed from the CLI.\n\nWhile logs are written to:\n\n\n> ~/.gemini/tmp/background-processes/\n\n\nthere does not appear to be a persistent registry storing metadata about background tasks.\n\n#### Impact\n- Background tasks are tied to a single CLI session.\n- After a restart, users cannot list, inspect, or manage previously started tasks.\n- Long-running background commands become difficult to manage once the CLI session ends.\n#### Background processes are tracked in-memory in `ShellExecutionService` (using `Map`/`Set` structures). No persistent process registry is present under `~/.gemini`.\n\n#### Proposed Solution\n- Add background management commands:\n\n\n> /background list\n> /background logs <pid>\n> /background kill <pid>\n\n\n- Introduce a persistent registry (`~/.gemini/process_registry.json`) to store background task metadata and allow recovery or inspection after CLI restarts.",
"number": 21999,
"title": "[UX/CORE] Background Process Management & Persistence",
"url": "https://github.com/google-gemini/gemini-cli/issues/21999",
"analysis": "Implement a background process management system that can track, manage, and persist long-running tasks (like background servers) across CLI sessions.",
"effort_level": "medium",
"reasoning": "Implementing persistent background process management requires creating a file-based registry to track PIDs across sessions, modifying the ShellExecutionService to synchronize with this registry, and adding new CLI command handlers. This involves state management, filesystem I/O, and process lifecycle validation, fitting the Medium criteria for logic tracing and integration across components.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA `gemini doctor` subcommand that validates the user's local configuration and surfaces actionable diagnostics before or after a failed startup. After adding hooks, or maybe making changes to the `~/.gemini/settings.json` to add customizations, one might encounter formatting errors or other similar errors which the gemini throws on startup as `X error at Line A:B`.\n\nAs of now, these config errors or additions must be done by hand, but it could useful for some automatic diagnostics or additions.\n\n### Suggested behaviors\n\n1. Parse and validate existing config on syntax, correctness (hooks validation, etc), unknown keys or deprecated fields\n\n2. Report each issue with not just line/column but also with human-readable descriptions, and suggested fixes. It'd be really nice if a `--fix` flag can automatically make the suggested fixes. (Ref: `npm audit fix` and other similar commands).\n\n3. Exit with non-zero code on validation failure (in case this needs to be used in scripts/CI later)\n\n### Why is this needed?\n\nCurrently a malformed `settings.json` causes the CLI to fail at startup with raw errors and one must go through the changes manually to fix this. Customizations are easy to mis-format, and the error message doesn't clearly map to what the user actually got wrong.\n\nIt'll point on semantics, or indentations but say I misconfigured a hook then I would prefer detailed errors and fixes for the changes that I've made.\n\nThis will significantly lower friction for new and power users alike. I personally would love to be able to play around with my config and maximize what I have at hand in the easiest possible manner.\n\n### Additional context\n\n## How I'd expect this to work\n\n1. I'd go and customize `~/.gemini/settings.json` and then maybe add a few hooks or some other similar customization.\n2. If gemini CLI fails to start because of a mistake of my own, it points me to \"Config failed (or a similar error message). Run `gemini doctor` for diagnostics.\n3. I run `gemini doctor` and it fixes any small errors or provides a structured docs based response with suggested fixes.\n4. (Optional, but would be incredibly useful) a `--fix` flag which performs the above mentioned fixes.\n\n\n**Ref:**\n\nhttps://geminicli.com/docs/hooks/reference/\nhttps://geminicli.com/docs/cli/tutorials/mcp-setup/\nhttps://geminicli.com/docs/cli/tutorials/automation/\n",
"number": 21987,
"title": "feat(cli): Add `doctor` command for config validation and diagnostics",
"url": "https://github.com/google-gemini/gemini-cli/issues/21987",
"analysis": "Implement a new `/doctor` command to perform system-wide health checks, including authentication status, network connectivity to Gemini API, and configuration validity.",
"effort_level": "medium",
"reasoning": "Implementing a `doctor` command involves integrating multiple subsystems including configuration validation, authentication status, and network connectivity. It requires creating a new command handler, developing a diagnostic reporting UI in Ink, and implementing logic for the `--fix` flag which involves programmatic file system modifications. This aligns with the Medium criteria for service integration, state management, and validation logic across several components.",
"validated": true
},
{
"body": "### What happened?\n\n\n\n[ACTION REQUIRED] \ud83d\udcce PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.\n\n### What did you expect to happen?\n\nthe prompt box should be available even if an approval box pops up. not forcing you to deal with the approval box before you get back to your thought.\n\n### Client information\n\n\n* **CLI Version:** 0.32.1\n* **Git Commit:** e8a57c78c\n* **Session ID:** 071d7b58-3837-47fa-8417-57882888b36f\n* **Operating System:** darwin v24.10.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-3\n* **Auth Type:** oauth-personal\n* **Memory Usage:** 253.3 MB\n* **Terminal Name:** Unknown\n* **Terminal Background:** #1e1e1e\n* **Kitty Keyboard Protocol:** Unsupported\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 21981,
"title": "Not really a bug, but an annoyance. When it's doing an acive job checking a lot of files an processes it interupts typing out a new message with approval boxes.. pretty annoying.",
"url": "https://github.com/google-gemini/gemini-cli/issues/21981",
"analysis": "Refactor the TUI to prevent asynchronous tool approval prompts from interrupting the user's current typing flow in the `Composer`.",
"effort_level": "medium",
"reasoning": "This task involves managing React/Ink state and focus synchronization between the Composer and the Tool Approval components. It requires ensuring that the input buffer remains active and focused while asynchronously rendering approval prompts, which falls under the Medium effort category for state management and UI focus logic.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWhile using the Gemini CLI, I often feel the need to add support for selecting a thinking level for Gemini-3 models in order to save tokens and reduce response time for simpler tasks. Currently, it defaults to HIGH mode, and since HIGH mode allows thinking tokens with a maximum limit of 8192, it can introduce unnecessary latency for lightweight queries.\n\n### Why is this needed?\n\nBy default Gemini 3 models use a **HIGH** thinking level, which is optimal for high reasoning but adds unnecessary latency and token cost when dealing with simple queries or small tasks. If a user temporarily needs a faster response they must manually stop the CLI in between the conversation define a new alias in their config.json file configuring thinkingLevel to LOW or MEDIUM before they can use it like this\n\n```\n\"modelConfigs\": {\n \"customAliases\": {\n \"gemini-3-pro-fast\": {\n \"extends\": \"chat-base-3\",\n \"modelConfig\": {\n \"generateContentConfig\": {\n \"thinkingConfig\": {\n \"thinkingLevel\": \"LOW\"\n }\n }\n }\n }\n }\n}\n```\n\nThis significantly limits the fluidity of the interactive experience.\n\n### Solution\n\nWhen running the CLI in interactive mode and using the `/model` slash command, users are presented with a dialog to select standard models or manual options when they select auto gemini 3 below they should get a option for thinking level same goes for selection in manual mode too\n\n```bash\nSelect Model\n 1. Auto (Gemini 3)\n Let Gemini CLI decide the best model for the task: gemini-3.1-pro, gemini-3-flash\n 2. Auto (Gemini 2.5)\n Let Gemini CLI decide the best model for the task: gemini-2.5-pro, gemini-2.5-flash\n 3. Manual\n Manually select a model\nRemember model for future sessions: false\nSet Gemini thinking level (low,medium,high) : HIGH\n\n(Press Tab to toggle)\n> To use a specific Gemini model on startup, use the --model flag.\n(Press Esc to close)\n```\n\nIt would be beneficial when secondary configuration toggle existed directly under the model selection list in the /model menu (potentially only shown when a compatible Gemini 3 model is highlighted).\n\nI would like to work on this if it gets approved\ud83d\ude01",
"number": 21974,
"title": "feat(cli) : Add Thinking Level selection to the interactive `/model` UI",
"url": "https://github.com/google-gemini/gemini-cli/issues/21974",
"analysis": "Add a 'Thinking Level' (budget) selection to the interactive `/model` selection dialog.",
"effort_level": "medium",
"reasoning": "Adding a 'Thinking Level' selection to the interactive `/model` UI involves modifying React/Ink state management and navigation logic within the ModelDialog component. It requires synchronizing the UI state with the underlying model configuration and ensuring the selection is correctly applied to the generation parameters, which aligns with the Medium effort criteria for state management and component integration.",
"recommended_implementation": "In `ModelDialog.tsx`, add a new selection list for thinking budgets (e.g., 'Low', 'Medium', 'High'). Update the `onSelect` callback to persist the chosen budget to the model configuration.",
"validated": true
},
{
"body": "### What happened?\nThe settings dialogs have gone through refactors to make the React code more maintainable\n\nOnce those refactors settle there are a few UX issues that stem from an undefined UX vision.\n\nI decided to compile all of these issues into one issue and maybe a maintainer can help me make sub issues if they agree.\n\nThe reason I put this into one issue is because subjective UX decisions need to be made here with some confidence. This makes all of the sub issues tightly coupled. \n\n1) Users can't type j and k into the search bar in /settings (this is not a simple fix if we want j and k to navigate outside of vim mode pls see next section)\n2) The asterisks that appear when a setting is in scope could be rethought.\n3) Hiding the search bar when the restart prompt shows could be rethought.\n4) We can have clearer alignment on when to show the restart prompt\n\n**All of these issues existed before the refactor series started in #18963**\n(please confirm with\n`git checkout 8133d63^1` that way we can properly document if I messed up and the refactors introduced UX regressions)\n\n**There needs to be subjective UX decisions made with confidence in all of these areas.**\n\n### What did you expect to happen?\n\nThe settings dialog should make sense\n\n1) If we want to support j and k navigation outside of vim mode then perhaps the search bar should be a focusable. **There is a tradeoff in that all users who do not care about navigating with j and k will have extra overhead to activate search.**\nAnother solution could be to give users a keybind to hide search that they would have to press in order to use j and k. Probably better than making every user focus in and out. Or / to toggle search mode.\n\n2) The asterisk should be clear as to what they represent. This could involve adding a label as well as re thinking when they should appear.\n\n3) I don't know if hiding the search bar when the restart prompt shows is really the best UX that we can do.\n\n4) We should confirm when _exactly_ the restart prompt should show\nShould it show only when a setting has been modified since mount of the Dialog? Or should it show when the session requires a restart?\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n# paste output here\n```\n\n</details>\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\nThis issue exists well before #18963 etc. \nPart of the reason I pushed for those refactors is because cleaner React makes it easier to define a high quality user experience.\n`git checkout 8133d63^1`\n\nThere are multiple subjective paths to resolving this so it is not a straightforward fix.",
"number": 21899,
"title": "Better Settings UX.",
"url": "https://github.com/google-gemini/gemini-cli/issues/21899",
"analysis": "Improve the Settings UI by adding categories, search functionality, and better descriptions for complex configuration options.",
"effort_level": "medium",
"reasoning": "The issue involves multiple interconnected UX improvements within the Settings UI, specifically requiring React/Ink state management to resolve input focus conflicts (j/k keys), conditional rendering logic for the restart prompt, and UI synchronization. These tasks require logic tracing and state handling across the SettingsDialog component rather than simple static changes, fitting the criteria for Medium effort.",
"validated": true
},
{
"body": "# Design Proposal: Hands-Free Multimodal Voice Mode for Gemini CLI\n\n## Summary\n\nThis proposal describes the architecture and implementation plan for enabling real-time multimodal voice interaction in Gemini CLI.\n\nThe goal is to transform the CLI into a hands-free conversational coding assistant, allowing developers to speak naturally and receive spoken responses.\n\nUnlike simple speech-to-text wrappers, the system will leverage Gemini's native multimodal audio streaming capabilities to support a continuous bidirectional conversation loop.\n\nThe design prioritizes:\n\n- real-time audio streaming\n- minimal latency interaction\n- robust voice input handling\n- seamless integration with the existing CLI execution pipeline\n\nThe implementation will be delivered incrementally to ensure core voice functionality is stable before exposing new CLI UX features.\n\n## Problem Statement\n\nGemini CLI currently supports only keyboard-based interaction.\n\nDevelopers frequently perform repetitive CLI tasks such as:\n\n- installing dependencies\n- running builds\n- executing tests\n- asking the AI coding assistant for help\n\nVoice interaction would allow developers to perform these tasks without leaving their coding environment or typing commands.\n\nAdditionally, voice interaction improves accessibility and enables more natural conversational workflows with the AI agent.\n\nThe challenge is to integrate voice interaction into the CLI without introducing fragile UX or breaking the existing command execution model.\n\n## Design Goals\n\nThe voice mode system should satisfy the following goals:\n\n1. Enable real-time voice input and output.\n2. Support continuous conversational interaction.\n3. Integrate with Gemini CLI's existing request pipeline.\n4. Provide low-latency responses using streaming APIs.\n5. Support multiple activation methods.\n6. Provide visual feedback during interaction.\n7. Allow interruption of responses during conversation.\n\n## Non-Goals\n\nThe initial implementation will focus on establishing a reliable voice interaction pipeline and should avoid expanding scope beyond the core architecture.\n\nThe following capabilities are explicitly out of scope for the first implementation:\n\n- full background voice assistant behavior similar to consumer smart assistants\n- continuous passive listening outside of explicit activation modes\n- complex natural-language command suggestion systems\n- advanced wake-word model training or custom wake-word engines\n- full speech-to-text model development, since existing APIs or models will be used\n- advanced graphical UI components beyond terminal-based visual feedback\n\nThe goal of this proposal is to establish a stable foundation for voice interaction, not to build a fully featured voice assistant in the first iteration.\n\n## High-Level Architecture\n\nThe system introduces a multimodal streaming pipeline that connects microphone input to the Gemini CLI execution engine.\n\n```text\nMicrophone Input\n \u2193\nAudio Capture Layer\n \u2193\nVoice Activity Detection\n \u2193\nAudio Streaming to Gemini API\n \u2193\nGemini Multimodal Processing\n \u2193\nCommand / Response Generation\n \u2193\nCLI Execution\n \u2193\nText + Audio Response\n \u2193\nText-to-Speech Output\n```\n\nThis architecture enables bidirectional streaming interaction between the developer and the AI agent.\n\n## Core System Components\n\n### 1. Audio Capture Layer\n\nThe audio capture layer records microphone input and streams audio frames to the processing pipeline.\n\nResponsibilities:\n\n- capture microphone input\n- encode audio as PCM/WAV frames\n- stream audio chunks for processing\n- support cross-platform microphone access\n\nKey considerations:\n\n- minimal latency\n- continuous audio streaming\n- compatibility with Node.js environments\n\n### 2. Voice Activity Detection (VAD)\n\nVAD determines when the user begins and stops speaking.\n\nResponsibilities:\n\n- detect speech segments\n- reduce background noise processing\n- preven
"number": 21869,
"title": "RFC: Hands-Free Multimodal Voice Mode Architecture for Gemini CLI",
"url": "https://github.com/google-gemini/gemini-cli/issues/21869",
"analysis": "Implement the core architecture for Hands-Free Multimodal Voice Mode, including continuous audio streaming and voice activity detection (VAD).",
"effort_level": "large",
"reasoning": "This task involves implementing a major new subsystem for real-time multimodal voice interaction. It requires complex architectural changes, including managing continuous WebSocket audio streams, integrating with system-level audio APIs, and handling high-concurrency streaming data, which aligns with the criteria for Large effort.",
"validated": true
},
{
"body": "%23%23 Feature Request\n\n%23%23%23 Summary\nPlease increase the MCP (Model Context Protocol) tool limit from the current ~100 tools to at least 500.\n\n%23%23%23 Problem\nWhen using Antigravity with multiple MCP servers, the 100-tool limit is reached very quickly. For example, having 5-7 MCP servers \u2014 each providing 15-30 tools \u2014 easily exceeds this ceiling. This forces users to either:\n\n1. Remove useful MCP servers to stay under the limit\n2. Reduce the number of tools per server, losing functionality\n3. Accept that some tools will be silently dropped\n\n%23%23%23 Proposed Solution\n- Increase the hard limit to at least 500 tools\n- Ideally, make the limit configurable via `mcp_config.json` or user settings (e.g., `\"maxMcpTools\": 500`)\n- Consider lazy-loading or tool grouping to manage context window impact\n\n%23%23%23 Additional Context\n- Antigravity version: latest (March 2026)\n- OS: macOS\n- The MCP ecosystem is growing rapidly, and tool counts will only increase as users add more integrations. A higher or configurable limit would future-proof the platform.\n\n%23%23%23 Related Discussions\nCommunity discussions on Reddit and other forums confirm this is a common pain point for power users with multiple MCP servers.",
"number": 21823,
"title": "[Feature Request] Increase MCP tool limit from 100 to 500",
"url": "https://github.com/google-gemini/gemini-cli/issues/21823",
"analysis": "Increase the hardcoded limit for the number of tools a single MCP server can expose to the agent.",
"effort_level": "small",
"reasoning": "Increasing a hardcoded limit or default configuration value is a trivial logic change that typically involves modifying a single constant in the MCP management logic. This fits the criteria for a small effort level as it is highly localized and easily verifiable.",
"recommended_implementation": "In `packages/core/src/tools/mcp-client-manager.ts`, locate the `MAX_TOOLS_PER_SERVER` constant and update its value from `100` to `500`.",
"validated": true
},
{
"body": "### What happened?\n\nThe dfault them has \"background colour\" that makes the UI intolerable to use. Disabling it does not work well at all. The \"Gemini client (Ubuntu) is unable to submitt this bug report, and the link that it shows cannot be copied or clicked (thie link is actually incomplete).\n\nMy ~/gemini/settings.json (I tried a LOT of things to make the UI even tolerable):\n{\n\n \"ui\": {\n \"theme\": \"ANSI\",\n \"useBackgroundColor\": false,\n \"autoThemeSwitching\": false,\n \"hideTips\": true,\n \"showSpinner\": false,\n \"loadingPhrases\": \"off\",\n \"dynamicWindowTitle\": false,\n \"incrementalRendering\": true,\n \"useAlternateBuffer\": true,\n \"accessibility\": {\n \"screenReader\": false\n }\n },\n \"selectedAuthType\": \"gemini-api-key\",\n \"preferredEditor\": \"vim\",\n \"tools\": {\n \"shell\": {\n \"pager\": \"less -FXR\"\n }\n },\n \"general\": {\n \"sessionRetention\": {\n \"enabled\": true,\n \"maxAge\": \"30d\",\n \"warningAcknowledged\": true\n }\n },\n \"security\": {\n \"auth\": {\n \"selectedType\": \"gemini-api-key\"\n }\n }\n}\n\nI am using Gemini client v0.34 . A much earlier Gemini version had a MUCH nicer UI. I am even considering trying out Claude again because of this - it is a mess.\n\n\n### What did you expect to happen?\n\nThe text client must have a reliable configuration that does NOT use lots of background, blink and animation.\n\n### Client information\n\nIt is not possible to copy text from the client.\n\nIt is v 0.34.0-nightly.2026+3+4.28af4e127\nI am running sandbox-0.32.1-0\n\n\n### Login information\n\nAPI key\n\n### Anything else we need to know?\n\nSadly the full context is locked into my client and I cannot copy it.",
"number": 21773,
"title": "Yellow background is horrible",
"url": "https://github.com/google-gemini/gemini-cli/issues/21773",
"analysis": "Change the default background color used for code blocks and highlighted text to improve readability and visual appeal.",
"effort_level": "small",
"reasoning": "The issue involves localized UI aesthetic adjustments and minor logic fixes. Specifically, it requires changing default theme color constants and ensuring the 'useBackgroundColor' setting is correctly applied within the Ink components. The secondary issue regarding the bug report link is a string/content update. These tasks are constrained to the UI/theme layer and do not impact core application logic or complex state management.",
"recommended_implementation": "Update the `codeBackground` or equivalent color value in `packages/cli/src/ui/semantic-colors.js` to a more neutral or customizable color.",
"validated": true
},
{
"body": "**PROBLEM**\n\nCurrently, writing complex, structured prompts directly in the CLI can be unintuitive for users accustomed to standard web-based AI interfaces. While I see that multi-line entry is currently supported via `Ctrl+J` (as discussed in issue #20226), this keybinding is unconventional for general users.\n\nAlmost all modern chat UIs (Gemini web, etc.) use standard `Enter` to submit and `Shift+Enter` to inject a newline. Because the CLI currently submits immediately on `Shift+Enter,` users often trigger premature submissions when trying to format their context (e.g., writing sub-tasks or separating code from instructions), breaking their workflow.\n\n\n\n\n**SOLUTION**\n\nI propose aligning the CLI's input UX with modern chat standards by mapping `Shift+Enter` directly to a newline insertion, while preserving the existing `Ctrl+J` functionality and keeping standard Enter as the submit trigger.\n\n\nI have audited the codebase and mapped out the exact changes required:\n**Target File:** `packages/cli/src/ui/components/InputPrompt.tsx`\n**Logic Change:** \n1. Inside the `handleInput` function, update the `Command.SUBMIT` event listener to check for the `shift` modifier: If `key.shift` is active during a return event, trigger buffer.newline() and return true to prevent submission.\n2. Otherwise, allow the standard handleSubmit(buffer.text) execution to proceed.\n\n_(Note: I intentionally avoided proposing `Alt+Enter` because it natively conflicts with the full-screen toggle in standard Windows terminal emulators)._\n\n\n\n\nI have my local dev environment set up and in the process of implementing this. Currently, I am dealing with the corresponding unit test in `packages/cli/src/ui/components/InputPrompt.test.tsx` to verify the newline behavior.\n\nI'll submit the PR for this feature once this issue is approved!",
"number": 21675,
"title": "[Feature Request/UI] Map Shift+Enter to newline for multi-line prompt entry",
"url": "https://github.com/google-gemini/gemini-cli/issues/21675",
"analysis": "Enable `Shift+Enter` to insert a newline into the prompt buffer, allowing for easier multi-line prompt entry without immediate submission.",
"effort_level": "medium",
"reasoning": "Implementing Shift+Enter in a terminal environment is more complex than a standard web UI because many terminal emulators do not distinguish between Enter and Shift+Enter by default. This requires logic tracing within the Ink-based TextInput component to handle specific ANSI escape sequences and manage the input buffer state, fitting the criteria for React/Ink state management and input synchronization.",
"validated": true
},
{
"body": "Hi team,\n\nI am Deepraj, a P.h.D student from IIT Jodhpur, and I am preparing my GSoC 2026 proposal for Idea 11: Hands-Free Multimodal Voice Mode.\nTo support this feature, I want to contribute the foundational configuration schema. This will allow the CLI to store user preferences for:\n\n- [ ] 1. Enabling/Disabling voice mode\n- [ ] 2. Microphone device selection\n- [ ] 3. VAD (Voice Activity Detection) sensitivity\n- [ ] 4. TTS Voice selection\n\nI have a local PR ready that updates settingsSchema.ts and regenerates the documentation. This prepares the CLI for real-time audio streaming without impacting current text-based workflows.\n\nLooking forward to your feedback!\n\n### Why is this needed?\n\nThis provides a persistent, type-safe way for users to manage voice preferences across User and Workspace scopes without impacting existing text-only workflows.",
"number": 21649,
"title": "[Feature] Add configuration schema for Hands-Free Multimodal Voice Mode",
"url": "https://github.com/google-gemini/gemini-cli/issues/21649",
"analysis": "Add the configuration schema and persistence logic for the proposed Hands-Free Multimodal Voice Mode.",
"effort_level": "small",
"reasoning": "The task involves adding a new configuration object to the existing settingsSchema.ts file. This is a localized change to a schema definition, which falls under the 'Trivial Logic/Config' category of the Small effort level. It does not require implementing the actual voice processing logic, only the metadata and default values for the settings.",
"recommended_implementation": "Add a new `voice` section to `packages/cli/src/config/settingsSchema.ts` with fields like `handsFreeEnabled`, `autoSilenceTimeout`, and `preferredInputDevice`.",
"validated": true
},
{
"body": "## Summary\nProvide agent information to `BeforeAgent`, `AfterAgent`, `BeforeModel` and `AfterModel` hooks.\n\n## Motivation\nSometimes decisions in the hooks depend on which agent is currently active. For example, a framework might have a local configuration that contains agent to model mappings that can change during the runtime of the framework. Using a settings.json file provides a solution to map agents to models ([see gemini docs](https://geminicli.com/docs/cli/generation-settings/#agent-specific-parameter-injection)), but it requires a restart of gemini-cli which the framework cannot execute as it is executed within gemini-cli. The alternative solution is to use hooks, but it's impossible to reliably determine the currently active agent.\n\n## Use Cases\n\n- Agent-specific model parameter override \n- Agent-specific context injections\n\n## Requirements\n\n- `BeforeAgent`, `AfterAgent`, `BeforeModel` and `AfterModel` contain additional agent information\n- The additional agent information is passed via `stdin`\n- At least the name/scope of the agent must be present\n\n### Related issues\n- https://github.com/google-gemini/gemini-cli/issues/15464\n- https://github.com/google-gemini/gemini-cli/issues/15466\n",
"number": 21615,
"title": "Hooks: Attach agent information",
"url": "https://github.com/google-gemini/gemini-cli/issues/21615",
"analysis": "Enhance the lifecycle hook system by attaching active agent metadata to the context passed to each hook execution.",
"effort_level": "medium",
"reasoning": "This task requires modifying the HookContext interface and updating the hook trigger points within the agent execution lifecycle. It involves tracing logic across the hook system and agent management components to ensure metadata is correctly propagated, fitting the criteria for logic tracing and integration across multiple components.",
"recommended_implementation": "In `packages/core/src/hooks/types.ts`, add an optional `agent` field to `HookContext`. Update `HookSystem.ts` to populate this field from the active `AgentContext` before executing any registered hooks.",
"validated": true
},
{
"body": "### What happened?\n\nWhen Gemini CLI prompts for user confirmation before executing a tool (e.g., WebFetch), long parameters\u2014especially the prompt or instructions\u2014are truncated with \"...\" based on the terminal width. \n\nThis prevents the user from seeing the full content of what they are about to approve, creating a lack of clarity and potential security/accuracy concerns.\n\n### What did you expect to happen?\n\nInstead of truncating text at a fixed width, please implement word-wrapping for tool parameters in the confirmation UI. This would allow users to review the entire instruction or prompt before proceeding.\n\n### Client information\n\n\n* **CLI Version:** 0.32.1\n* **Git Commit:** e8a57c78c\n* **Session ID:** 06e0e035-968c-4909-b54f-46492d35d7d7\n* **Operating System:** win32 v24.9.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-3\n* **Auth Type:** oauth-personal\n* **Memory Usage:** 310.6 MB\n* **Terminal Name:** Unknown\n* **Terminal Background:** Unknown\n* **Kitty Keyboard Protocol:** Unsupported\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 21602,
"title": "Request: Wrap long prompts in Tool Confirmation Screen instead of truncating",
"url": "https://github.com/google-gemini/gemini-cli/issues/21602",
"analysis": "Modify the tool confirmation screen to wrap long input prompts and command arguments instead of truncating them.",
"effort_level": "small",
"reasoning": "This is a localized UI adjustment within an Ink component. It involves modifying the layout properties of the ToolConfirmationMessage component to enable text wrapping instead of truncation, which aligns with the criteria for minor tweaks to structural layouts in Ink components.",
"recommended_implementation": "In `packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsx`, locate the `<Text>` component rendering the tool arguments and add the `wrap=\"wrap\"` prop, while ensuring the parent container has a fixed width or `flexGrow: 1`.",
"validated": true
},
{
"body": "## Summary\npackages/sdk/src/types.ts exports several public interfaces that lack \nJSDoc documentation, making it harder for SDK consumers and new \ncontributors to understand their purpose without reading the implementation.\n\n## Affected symbols\n- SystemInstructions\n- GeminiCliAgentOptions\n- AgentFilesystem\n- AgentShellOptions\n- AgentShellResult\n- AgentShell\n- SessionContext\n\n## Proposed change\nAdd JSDoc comments above each exported symbol describing its purpose \nand usage.\n\n## Files touched\n1 file only: packages/sdk/src/types.ts",
"number": 21505,
"title": "docs(sdk): add JSDoc to exported interfaces in packages/sdk/src/types.ts",
"url": "https://github.com/google-gemini/gemini-cli/issues/21505",
"analysis": "Add comprehensive JSDoc documentation to all public interfaces and types exported by the SDK package.",
"effort_level": "small",
"reasoning": "This is a documentation-only task that involves adding JSDoc comments to a single file (packages/sdk/src/types.ts). It falls under the 'String/Content Updates' category as it does not affect runtime logic or require complex testing.",
"recommended_implementation": "Iterate through `packages/sdk/src/types.ts` and add descriptive JSDoc comments to each `interface` and `type` declaration, explaining the purpose and valid values for each field.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nRefined focus highlight for BaseSelectionList and BaseSettingsDialog. \nThe highlight now uses a 2-character gutter and breakout logic to avoid overlapping dialog borders. \nAdditionally, descriptions in settings items now use the primary foreground color when focused to improve legibility.\n\n### Why is this needed?\n\nThe previous highlight state was too wide and overlapped with the borders of containing boxes (e.g. in /settings). \nDescription text was also hard to read on the focus background due to using the secondary color.\n\n### Additional context\n\nImprovements applied to:\n- `BaseSelectionList.tsx`: breakout logic and gutter.\n- `BaseSettingsDialog.tsx`: wider highlight and color legibility.\n- Unit tests updated to verify new layout and mock `useUIState`.\n",
"number": 21493,
"title": "feat(ui): refine focus highlight for selection lists and settings items",
"url": "https://github.com/google-gemini/gemini-cli/issues/21493",
"analysis": "Improve the visual clarity of the focus highlight in interactive selection lists and the settings dialog.",
"effort_level": "small",
"reasoning": "The changes are localized to two UI components (BaseSelectionList and BaseSettingsDialog) and involve aesthetic refinements such as padding, color adjustments, and layout logic within the Ink framework. These modifications align with the criteria for minor UI/aesthetic adjustments and are easily verifiable through updated unit tests.",
"recommended_implementation": "Update the `focus` styles in `packages/cli/src/ui/hooks/useSelectionList.ts` and `SettingsDialog.tsx` to use a more prominent color from the `theme` object, such as `theme.status.info`.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nGemini CLI's current UX treats multi-step agentic execution as a black box. Current chain of thought visuals come from the CLI Help Agent, inline thinking, and thought blocks. Tool calls appear in a flat, sequential list with no indication of hierarchy, nesting, or decision flow. Users also have no way to inspect what the model decided at each step, pause before a specific tool fires, or zoom in/out of output detail without permanently changing their approval mode.\n\nThis proposal (which I will implement) adds three interlocking features to the Ink TUI:\n1. **Real-time hierarchical task tree** \u2014 visualizes the parent/child `callId` graph of all tool calls, agent decisions, and subagent invocations as a live-updating tree.\n2. **Step-through mode** \u2014 a new `STEP` execution mode where the user presses Enter to advance through each tool call, with the ability to inspect inputs before approving.\n3. **Collapsible tool output sections + configurable verbosity levels** \u2014 per-call expand/collapse and a new `ui.verbosityLevel` setting controlling how much output is shown by category.\n\n---\n\n## Current Behavior\n\n- Tool calls render in `ToolGroupMessage \u2192 ToolMessage \u2192 ToolResultDisplay` as a flat list. The `parentCallId` field exists on `ToolCallRequestInfo` but is never visualized.\n- `DEFAULT` approval mode only asks before using dangerous tools (edit/exec/mcp). There is no mode that pauses before _every_ tool, regardless of danger level.\n- No collapse/expand on tool outputs \u2014 long results are either shown in full or truncated at `truncateToolOutputThreshold` (40k chars).\n- The only verbosity control is a global `ui.errorVerbosity: 'low' | 'full'` toggle. There are no per-category or per-tool verbosity levels.\n- The `WriteTodosTool` / `TodoTray` system tracks task status but renders it in a sidebar, not integrated with the execution trace.\n\n---\n\n## Expected Behavior\n\n### 1. Task Tree Visualization\n\nWhen an agent turn is active, the `MainContent` area shows a live-updating tree instead of the current flat list:\n\n```\n\u25b6 Turn 1 \u2014 \"refactor the auth module\"\n \u251c\u2500 \u2713 read_file src/auth.ts [0.3s]\n \u251c\u2500 \u2713 glob src/**/*.test.ts [0.1s]\n \u251c\u2500 \u25cf edit_file src/auth.ts [running\u2026]\n \u2502 \u2514\u2500 \u25f7 shell tsc --noEmit [pending]\n \u2514\u2500 \u25cc subagent write-tests [queued]\n \u251c\u2500 \u25cc write_file src/auth.test.ts\n \u2514\u2500 \u25cc shell npm test\n```\n\n- Status icons: `\u25cf` running / `\u2713` success / `\u2717` error / `\u25f7` pending / `\u25cc` queued / `\u2298` cancelled\n- Duration shown for completed calls\n- Subagent trees are nested under their parent `callId`\n- Clicking `\u2192` / `\u2190` on a node expands/collapses its output inline\n- The tree is scrollable in alternate-buffer mode via the existing `ScrollableList`\n\n### 2. Step-Through Mode\n\nA new `ApprovalMode.STEP` mode (or alternatively a separate `stepThroughEnabled` boolean, see alternatives). When active:\n\n- Before every tool call is dispatched (regardless of `Kind`), the scheduler pauses at a new `StepPending` status\n- A new `ToolStepDialog` renders at the bottom of the screen (similar to `ToolConfirmationQueue`)\n- The dialog shows: tool name, inputs rendered as syntax-highlighted JSON, and a summary of what the tool will do\n- **Keyboard actions:**\n - `Enter` / `n` \u2014 execute this tool, advance to next step\n - `s` \u2014 skip this tool (return empty result, don't execute)\n - `c` \u2014 continue (exit step-through, resume normal execution)\n - `q` / `Esc` \u2014 cancel the entire agent turn\n- Added to the `CYCLE_APPROVAL_MODE` keybinding cycle: `DEFAULT \u2192 AUTO_EDIT \u2192 STEP \u2192 PLAN`\n- A step counter `Step X of ~Y` is shown (Y is estimated from the pending queue)\n\n### 3. Collapsible Output + Verbosity Levels\n\n**Per-call collapsi
"number": 21484,
"title": "feat(cli): Interactive Progress Visualization & Task Stepping",
"url": "https://github.com/google-gemini/gemini-cli/issues/21484",
"analysis": "Implement a new interactive visualization system to track the progress of complex, multi-step agent tasks and allow users to 'step through' individual tool executions.",
"effort_level": "large",
"reasoning": "Implementing a hierarchical task tree and a step-through execution mode requires significant architectural changes to the core Scheduler and the introduction of complex state management within the Ink TUI. This involves modifying the task execution pipeline to support pausing/resuming and building a sophisticated UI component to visualize nested tool calls, which aligns with the criteria for Large effort (3+ days).",
"validated": true
},
{
"body": "This issue tracks the isolation of the shell execution and environment detection performance optimizations. It improves cross-platform robustness (especially PowerShell handling) and optimizes execution paths.\n\nOriginated from the large PR #21339.",
"number": 21424,
"title": "perf(core): optimize shell execution and environment handling",
"url": "https://github.com/google-gemini/gemini-cli/issues/21424",
"analysis": "Optimize the performance of shell command execution and environment variable handling within the core agent loop.",
"effort_level": "large",
"reasoning": "Optimizing shell execution and environment handling involves deep platform-specific complexities, particularly regarding child process management and shell-specific behavior (PowerShell vs. POSIX). The task requires profiling and potentially refactoring the core execution path in ShellExecutionService, implementing efficient environment inheritance, and ensuring robustness across different OS environments, which aligns with the criteria for Large effort involving major subsystems and platform-specific child process management.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n Native SOCKS5 proxy support to resolve frequent \"fetch failed\" errors on large contexts\n\n### Why is this needed?\n\nbecause this feature request related to a problem, Please let me describe:\n Currently, when using the Gemini CLI in an environment that requires a SOCKS5 proxy (specifically SOCKS5 + TLS), there is no native support. The common workaround is to use an external HTTP-to-SOCKS bridge (such as Privoxy or http-proxy-to-socks).\n\nHowever, this workaround is highly unstable in practice. While it works fine for short, simple prompts, as soon as the conversation context gets longer or the payload increases, the CLI frequently throws an API Error: fetch failed error. The connection simply drops or times out during the HTTP-to-SOCKS protocol translation phase when handling large text streams.\n\nI would like the Gemini CLI to natively support SOCKS5 proxies (e.g., via the ALL_PROXY or SOCKS_PROXY environment variables).\n\n Technically, if the CLI is using Node.js native fetch or a similar HTTP client, this could be achieved by injecting a custom dispatcher/agent (like socks-proxy-agent or undici's proxy agent) when a socks5:// URL is detected in the environment variables. This would allow the CLI to establish a direct TCP tunnel to the SOCKS proxy, completely bypassing the flaky HTTP bridge and the overhead of protocol translation.\n\n I have extensively tested using Privoxy as a background service on Windows to bridge the HTTP traffic to my SOCKS5 proxy. While Privoxy is generally stable, it consistently struggles and drops the connection with the exact same fetch failed error when the Gemini CLI sends or receives large context payloads.\n\n### Additional context\n\n Additional context\n - OS: Windows 10/11 64-bit\n - Proxy Environment: SOCKS5 over TLS\n - Trigger Condition: The error is highly reproducible when the context window grows (e.g., reading multiple files or maintaining a long chat history). Native SOCKS5 support would make the CLI vastly more reliable for users behind strict firewalls or specific routing rules.\n - here is detailed CLI version information:\n CLI Version 0.32.1 \u2502\n\u2502 Git Commit e8a57c78c \u2502\n\u2502 Model Auto (Gemini 3) \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS win32 \u2502\n\u2502 Auth Method gemini-api-key ",
"number": 21410,
"title": "Feature Request: Native SOCKS5 proxy support to resolve frequent \"fetch failed\" errors on large contexts",
"url": "https://github.com/google-gemini/gemini-cli/issues/21410",
"analysis": "Add native support for SOCKS5 proxies to resolve network errors occurring in environments with restrictive connectivity.",
"effort_level": "medium",
"reasoning": "Implementing native SOCKS5 support requires more than a simple configuration change because the underlying 'undici' library used in fetch.ts does not natively support SOCKS protocols via its ProxyAgent. This task involves integrating a new dependency (e.g., socks-proxy-agent), refactoring the global dispatcher logic to switch between standard Agents, HTTP ProxyAgents, and SOCKS Agents based on the protocol, and ensuring that timeout and stream handling remain stable for large contexts as requested.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nHey team! \ud83d\udc4b\n\nCopilot CLI has a nifty subcommand called `update`, i.e. `copilot update` to update the tool itself. Would be nice to have it implemented here as well.\n\n### Why is this needed?\n\nAs a macOS user, there's a slight friction to remember which package manager I used to install most of my tools, was it brew, npm, npx, uvx, etc.? A `update` command solves that problem perfectly.\n\n### Additional context\n\n_No response_",
"number": 21400,
"title": "Add an update command",
"url": "https://github.com/google-gemini/gemini-cli/issues/21400",
"analysis": "Implement an `/update` slash command that allows users to check for and install the latest version of the Gemini CLI directly from the terminal.",
"effort_level": "medium",
"reasoning": "Implementing an update command requires integrating with external registries (npm/GitHub) to check for versions, detecting the user's specific installation environment (npm, brew, uvx), and managing child processes to execute the update. This involves asynchronous flow control and cross-platform logic tracing, which fits the Medium effort criteria.",
"validated": true
},
{
"body": "### What would you like to be added?\nInstead of showing the full, long version numbers (e.g., for nightly builds with full commit hashes/timestamps), just display a small tag like `nightly` or the base semantic version in the main CLI view. The exact version number and release details are already accessible via the `/about` command.\n\n### Why is this needed?\nThe current version display is too verbose for nightly builds and clutters the interface. Since `/about` provides the full version details, displaying a concise tag is sufficient and makes the UI cleaner.\n\n<img width=\"587\" height=\"122\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/84794cf9-fe31-478f-a956-5c7770fbf69d\" />",
"number": 21373,
"title": "feat: Display small tag instead of long version strings in CLI",
"url": "https://github.com/google-gemini/gemini-cli/issues/21373",
"analysis": "Shorten the version string displayed in the CLI header by using a compact 'tag' style (e.g., 'v0.40.0') instead of the full build/commit hash.",
"effort_level": "small",
"reasoning": "This is a localized UI/aesthetic adjustment involving simple string formatting or truncation in the header component. It falls under the 'UI/Aesthetic Adjustments' and 'String/Content Updates' criteria, requiring changes to likely only one file with no complex state management or architectural impact.",
"recommended_implementation": "In `packages/cli/src/ui/components/AppHeader.tsx`, add a helper to parse the version string and return only the major/minor/patch segments for display.",
"validated": true
},
{
"body": "On unix system(linux/macOS), Ctrl + F/B/P/N is often used as navigation key. But on gemini cli, Ctrl + B is mapped to view background execution, this causes inconvenience during use, and currently Gemini CLI does not support modifying keyboard shortcuts (it can switch to VIM mode). Could you consider mapping this function to other keyboard shortcuts?",
"number": 21368,
"title": "Don't use Ctrl + B as shortcut",
"url": "https://github.com/google-gemini/gemini-cli/issues/21368",
"analysis": "Change the default keyboard shortcut for background task toggling to avoid conflicts with `Ctrl+B` commonly used in terminal multiplexers like tmux.",
"effort_level": "small",
"reasoning": "Changing a keyboard shortcut in an Ink-based CLI application is a highly localized fix. It involves identifying the specific input handler (likely using the useInput hook) and updating the conditional logic or configuration constant that triggers the background task view. This falls under the 'Trivial Logic/Config' category and should take less than a day to implement and verify.",
"recommended_implementation": "In `packages/cli/src/ui/contexts/KeypressContext.tsx`, update the mapping for toggling the background task view from `ctrl+b` to a different key combination, such as `ctrl+l` or `ctrl+alt+b`.",
"validated": true
},
{
"body": "### Description\nAdd an opt-in terminal soundscape feature that plays cross-platform audio cues during CLI interactions (e.g., success, error, processing start) to improve the Developer Experience (DX).\n\n### Proposed Solution\n- Add `general.soundscapes` to settings.\n- Implement an `AudioNotificationService` using native OS audio commands (`afplay`, `powershell`, `printf`).\n- Inject audio cues via React hooks connected to the CLI's `streamingState`.\n\nRelates to GSoC 2026 Ideas list.",
"number": 21285,
"title": "Idea: Terminal Soundscapes (DX Sonification) for GSoC 2026",
"url": "https://github.com/google-gemini/gemini-cli/issues/21285",
"analysis": "Implement an experimental 'Terminal Soundscapes' feature that provides optional audio feedback for various CLI states and transitions.",
"effort_level": "large",
"reasoning": "Implementing a cross-platform audio notification system involves significant platform-specific complexity, requiring the management of child processes (afplay, powershell, etc.) to ensure non-blocking execution within the Ink-based CLI. It qualifies as a major subsystem implementation that must synchronize with the core streaming state and handle diverse OS environments, aligning with the criteria for large effort.",
"validated": true
},
{
"body": "## Description\n\nAs part of the overall file search improvements, we should support CamelCase and acronym-based matching in the `@file` autocomplete. \n\nFor example:\n- Searching for `uAC` should match `useAtCompletion.ts`.\n- Searching for `mRS` should match `modelRouterService.ts`.\n\n## Acceptance Criteria\n\n- The fuzzy searcher (`AsyncFzf` or our wrapper) correctly identifies and scores CamelCase/acronym matches.\n- Tests are added to verify the behavior.\n\n## Epic Link\n\nPart of Epic: #21144",
"number": 21145,
"title": "Support CamelCase and acronym matching in file search",
"url": "https://github.com/google-gemini/gemini-cli/issues/21145",
"analysis": "Enhance the fuzzy file search logic to support CamelCase matching (e.g., 'GH' matching 'GeminiHelper') and acronym-based filtering.",
"effort_level": "medium",
"reasoning": "Implementing CamelCase and acronym matching requires modifying the search logic in both the core file search utility and the autocomplete hook. It involves moving away from simple lowercase normalization to a case-sensitive or smart-case fuzzy matching algorithm (like AsyncFzf with proper configuration), which requires careful tuning of scoring and robust testing to ensure expected ranking behavior.",
"validated": true
},
{
"body": "## Description\n\nThis epic tracks ongoing efforts to improve the file search and `@file` autocomplete experience in the Gemini CLI. The goal is to make the search feel as intuitive, fast, and smart as modern IDEs (like VS Code).\n\n## Objectives\n\n- Improve fuzzy matching relevance and sorting algorithms.\n- Support advanced matching patterns (e.g., camelCase matching).\n- Enhance performance for large codebases.\n\n## Tracked Issues\n\n- [x] #21063 - Improve `@` file search autocomplete to prioritize filenames\n- [ ] #21145 - Support CamelCase and acronym matching in file search",
"number": 21144,
"title": "[Epic] Improve overall file search and autocomplete experience",
"url": "https://github.com/google-gemini/gemini-cli/issues/21144",
"analysis": "A broad epic task to improve the overall performance, ranking, and user experience of file search and auto-completion across the CLI.",
"effort_level": "large",
"reasoning": "This is an epic encompassing multiple complex tasks including fuzzy matching algorithms, camelCase matching, and performance optimizations for large codebases. These improvements require architectural changes to filesystem indexing and search logic across both core and CLI packages, fitting the criteria for a large effort (3+ days).",
"validated": true
},
{
"body": "## Problem\n\nIn `packages/sdk/src/session.ts`, `GeminiCliSession` hardcodes `PolicyDecision.ALLOW` as the default policy decision when constructing the `policyEngineConfig`:\n\n```ts\n// packages/sdk/src/session.ts, line 79-82\npolicyEngineConfig: {\n // TODO: Revisit this default when we have a mechanism for wiring up approvals\n defaultDecision: PolicyDecision.ALLOW,\n},\n```\n\nThe rest of the policy engine defaults to `PolicyDecision.ASK_USER`, which means the interactive CLI asks the user before executing any tool call. The SDK silently overrides this with `ALLOW`, so all tool invocations - including destructive ones like shell execution or file writes - proceed without any confirmation.\n\nThis is a deliberate temporary workaround (the TODO comment says so) because there is currently **no mechanism in the SDK API surface for embedders to wire up an approval callback**.\n\n## Expected behaviour\n\nSDK consumers should be able to supply an `onApprovalRequired` callback (or equivalent) in `GeminiCliAgentOptions` so that when `PolicyDecision.ASK_USER` is the outcome of a policy check, the embedder's callback is invoked and its response (allow / deny) is forwarded back to the policy engine. Once that mechanism exists, the hardcoded `ALLOW` default can be removed and the SDK will be safe by default.\n\n## Proposed solution\n\n1. Add an `onToolApproval?: (call: ToolCallRequestInfo) => Promise<'allow' | 'deny'>` field to `GeminiCliAgentOptions` (in `packages/sdk/src/types.ts`).\n2. Wire this callback into the confirmation bus / policy engine so that `ASK_USER` decisions invoke it instead of timing out or defaulting.\n3. Remove (or make configurable) the hardcoded `defaultDecision: PolicyDecision.ALLOW` in `GeminiCliSession`.\n4. Add unit tests covering allow and deny paths through the callback.\n\n## Why help wanted\n\nThis touches both the SDK public API surface (`GeminiCliAgentOptions`) and internal confirmation bus plumbing in `packages/core`. It is a well-scoped, self-contained improvement that does not require changes to the interactive CLI, making it a great first contribution for someone familiar with TypeScript and event-driven patterns.\n\n## References\n\n- `packages/sdk/src/session.ts` \u2013 line 80 (TODO comment) \n- `packages/core/src/policy/types.ts` \u2013 `PolicyDecision` enum and `PolicyEngineConfig` \n- `packages/core/src/confirmation-bus/types.ts` \u2013 confirmation bus interface",
"number": 20858,
"title": "SDK: GeminiCliSession needs an approval callback mechanism (currently hardcodes PolicyDecision.ALLOW)",
"url": "https://github.com/google-gemini/gemini-cli/issues/20858",
"analysis": "Introduce an asynchronous approval callback mechanism in the SDK to allow programmatic control over tool execution, replacing the current hardcoded 'ALLOW' policy.",
"effort_level": "medium",
"reasoning": "This task requires modifying the SDK's session logic to support an asynchronous callback mechanism. It involves integrating the GeminiCliSession with the existing ConfirmationBus and PolicyEngine, ensuring that the execution flow correctly suspends and resumes based on external input. This falls under Service Integration and Asynchronous Flow in the Medium category.",
"validated": true
},
{
"body": "### What happened?\n\nAskUser asks me a question and I am in the process of answering:\n\n<img width=\"888\" height=\"262\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/c6846abb-73c9-4a16-8b97-67d7ee000b26\" />\n\nI double hit CTRL-Z and push gemini into background\n\n<img width=\"657\" height=\"252\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/4df2ec03-8110-4cfb-9ed3-09da32a16c11\" />\n\nI go back to gemini-cli using fg command and my answer is gone\n\n<img width=\"609\" height=\"270\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/4f7d2d02-eb94-4b0a-a9c9-80aa34736269\" />\n\n### What did you expect to happen?\n\nI want my answers in progress in AskUser don't dissapear when I push gemini-cli into background using CTRL-Z.\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\nAbout Gemini CLI \u2502\n\u2502 \u2502\n\u2502 CLI Version 0.33.0-nightly.20260228.1ca5c05d0 \u2502\n\u2502 Git Commit 1ca5c05d0 \u2502\n\u2502 Model gemini-3.1-pro-preview \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS darwin \u2502\n\u2502 Auth Method Logged in with Google (wit.jakuczun@gmail.com) \u2502\n\u2502 Tier Gemini Code Assist in Google One AI Ultra\n```\n\n</details>\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 20838,
"title": "CTRL-z removes unfinished open questions in AskUser tool",
"url": "https://github.com/google-gemini/gemini-cli/issues/20838",
"analysis": "Fix a UI bug where pressing `Ctrl+Z` (Undo) incorrectly clears the active `AskUser` tool dialog or its internal state.",
"effort_level": "medium",
"reasoning": "The issue involves state management within the Ink/React TUI layer, specifically maintaining the input buffer state across process suspension (SIGTSTP/SIGCONT). This falls under the 'React/Ink State Management' and 'input buffers' category for Medium effort, as it requires tracing how the component lifecycle reacts to terminal signals and ensuring the TextInput state is not reset or incorrectly processed as an 'undo' command before the process backgrounds.",
"recommended_implementation": "In `packages/cli/src/ui/components/shared/TextInput.tsx`, ensure that the `ctrl+z` event calls `event.stopPropagation()` after updating the local buffer state to prevent it from reaching global command handlers.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI\u2019ve spent the last few weeks developing a Remote API for Gemini CLI that allows for 100% feature\nparity between the CLI and a remote interface (web/mobile). This enables long-running tasks: you can\nstart a complex refactoring job, disconnect, and reconnect later from another device to review\n\"thoughts,\" confirm tool calls, or interact with the shell.\n\n### Why is this needed?\n\n1. Motivation & Use Case\n As a heavy user of Gemini CLI, I frequently find myself working in environments where I don't have\n constant access to my primary workstation (e.g., commuting, working from a tablet or phone). While\n the CLI is powerful, it currently requires a persistent local terminal session.\n 2. The Gap in Existing Protocols\n While the project recently introduced the A2A (Agent-to-Agent) protocol via SSE, it is primarily\n designed for inter-agent task execution. It lacks several features critical for a human-centric\n remote UI:\n - Session Persistence: A2A is task-based, whereas a remote UI needs to manage the entire session\n history and system state.\n - Real-time PTY Streaming: A2A's shell output mechanism isn't optimized for interactive terminal\n apps (ANSI codes, cursor positioning).\n - Zero-Latency Interaction: WebSocket provides the sub-millisecond latency required for a smooth\n \"live terminal\" experience.\n\n### Additional context\n\n 3. Proposed Solution\n I propose adding an optional `RemoteApiService` to packages/cli.\n - Core Logic: A WebSocket server (based on ws) that acts as a bidirectional \"mirror\" of the CLI\n state.\n - React Integration: A useRemoteApi hook that synchronizes uiState (history, status, RAM, tokens,\n Git branch) and exposes uiActions (prompt submission, tool confirmation, stop generation).\n - PTY Proxy: Real-time streaming of shell output directly from ShellExecutionService.\n - Mirroring: Any command sent via the Remote API is rendered in the local CLI as if typed manually,\n ensuring a \"single source of truth.\"\n\n 4. Security Model\n Security is a top priority. The proposed implementation:\n 1. Strict Localhost: The server is hard-coded to listen only on 127.0.0.1, preventing accidental\n network exposure.\n 2. Proxy-Ready: For remote access, users are encouraged to use a secure proxy/orchestrator (I have\n a reference Rust implementation) that adds authentication and encryption.\n 3. Optional Token: We can implement a shared secret/token generated at startup (similar to Jupyter)\n to prevent unauthorized local applications from connecting.\n\n 5. Precedent\n The packages/devtools package already employs a WebSocketServer for log ingestion. This proposal\n expands on that established pattern to provide active session control.\n\n 6. Current Status: Working Prototype\n I have developed a robust working prototype in my fork. While it successfully demonstrates the core\n functionality (streaming PTY, syncing history, and handling confirmations), it is currently in an\n \"RFC-stage.\"\n\n Some areas, such as strict TypeScript typing for internal events and edge-case error handling, would\n benefit from collaboration with the core team to ensure they align perfectly with the project's\n long-term architectural goals. I am eager to use this prototype as a foundation for a formal\n implementation.\n\n![Image](https://github.com/user-attachments/assets/76063efc-4eee-40cb-9fb4-9527313b567f)\n\nI am writing about this here as a general concept to understand whether the project is interested in such a feature. If interested, we will discuss the details and implement it as decided. My current implementation was developed \u201cfor myself\u201d and therefore can only work as a prototype. The gif animation uses my [gemini cli fork](https://github.com/pavver/gemini-cli), as well as a [Rust orchestrator](https://github.com/[pavver/gemini-remote-orchestrator](https://github.com/pavver/gemini-remote-orchestrator)) that launches gemini cli in the desired
"number": 20782,
"title": "[Proposal] Stateful Remote WebSocket API for Interactive Control",
"url": "https://github.com/google-gemini/gemini-cli/issues/20782",
"analysis": "Design and implement a stateful remote WebSocket API to allow external applications to interact with and control an active agent session.",
"effort_level": "large",
"reasoning": "This proposal requires significant architectural changes, including the design and implementation of a new stateful WebSocket protocol and server component. It involves complex state serialization of the AgentScheduler, session persistence logic, and real-time command multiplexing, which aligns with the criteria for major subsystem development and core protocol changes.",
"validated": true
},
{
"body": "### What happened?\n\nFeature Request: 1. Please add a \"Side-by-Side\" diff view option for the \"Action Required\" confirmation prompt when modifying files. 2. Please stop stripping ANSI color codes from the output of `run_shell_command`, so external diff tools like `delta --color=always` can render colors properly in the terminal.\n\n[ACTION REQUIRED] \ud83d\udcce PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.\n\n### What did you expect to happen?\n\nFeature Request: 1. Please add a \"Side-by-Side\" diff view option for the \"Action Required\" confirmation prompt when modifying files. 2. Please stop stripping ANSI color codes from the output of `run_shell_command`, so external diff tools like `delta --color=always` can render colors properly in the terminal.\n\n### Client information\n\n\n* **CLI Version:** 0.31.0\n* **Git Commit:** 72c653354\n* **Session ID:** 9c6d2576-a6da-476e-af19-6050bcf1ebd6\n* **Operating System:** darwin v25.6.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-3\n* **Auth Type:** vertex-ai\n* **Memory Usage:** 495.0 MB\n* **Terminal Name:** iTerm2 3.6.6\n* **Terminal Background:** #282a35\n* **Kitty Keyboard Protocol:** Supported\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 20698,
"title": "Feature Request: 1. Please add a \"Side-by-Side\" diff view option for the \"Action Required\" confirmation prompt when modifying files. 2. Please stop stripping ANSI color codes from the output of `run_shell_command`, so external diff tools like `delta --colo",
"url": "https://github.com/google-gemini/gemini-cli/issues/20698",
"analysis": "1. Implement a side-by-side diff view for file modifications. 2. Preserve ANSI color codes in the output of shell commands for compatibility with external tools like `delta`.",
"effort_level": "medium",
"reasoning": "Implementing a side-by-side diff view in Ink is a non-trivial UI task requiring layout management, line alignment logic, and terminal width handling. Additionally, modifying the shell tool to selectively preserve ANSI escape sequences involves adjusting output sanitization and serialization logic, which aligns with the Medium criteria for ANSI handling and UI state synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n<html><head></head><body><h1 data-path-to-node=\"0\" style=\"font-family: &quot;Google Sans&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">Proposal: Python SDK for Gemini CLI (<code data-path-to-node=\"0\" data-index-in-node=\"37\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">google-gemini-cli-sdk</code>)</h1><p data-path-to-node=\"1\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">A new Python SDK package intended for PyPI to expose the Gemini CLI agent programmatically to Python developers. This project mirrors the existing TypeScript SDK located at <code data-path-to-node=\"1\" data-index-in-node=\"173\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">packages/sdk/</code>, tailored specifically for the Python ecosystem.</p><hr data-path-to-node=\"2\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><h2 data-path-to-node=\"3\" style=\"font-family: &quot;Google Sans&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">Core Features</h2><p data-path-to-node=\"4\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">The SDK is designed to support the following capabilities:</p><ul data-path-to-node=\"5\" style=\"padding-inline-start: 32px; font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><li style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><p data-path-to-node=\"5,0,0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><b data-path-to-node=\"5,0,0\" data-index-in-node=\"0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">Async Streaming:</b> Implement agent sessions via an <code data-path-to-node=\"5,0,0\" data-index-in-node=\"49\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">async for event in agent.run_stream(\"...\")</code> interface.</p></li><li style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><p data-path-to-node=\"5,1,0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><b data-path-to-node=\"5,1,0\" data-index-in-node=\"0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">Context Management:</b> Provide multi-turn session handling that mirrors the JS SDK.</p></li><li style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><p data-path-to-node=\"5,2,0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\"><b data-path-to-node=\"5,2,0\" data-index-in-node=\"0\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">Hook Registration:</b> Allow <code data-path-to-node=\"5,2,0\" data-index-in-node=\"25\" style=\"font-family: &quot;Google Sans Text&quot;, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;\">before_tool</code> and <code data-path-to-node=\"5,2,0\" data-index-in-node=\"41\" style=\"font-family: &quot;Google Sans Text&quot;, sans
"number": 20672,
"title": "feat(sdk): Python SDK for Gemini CLI Agent with programmatic access for the Python/ML ecosystem",
"url": "https://github.com/google-gemini/gemini-cli/issues/20672",
"analysis": "Develop a native Python SDK that provides programmatic access to the Gemini CLI agent, targeting the Python/ML ecosystem.",
"effort_level": "large",
"reasoning": "Developing a full Python SDK from scratch to mirror the TypeScript SDK is a major subsystem implementation. It requires porting core protocol handling (ACP), session management, and tool execution logic to a new language ecosystem, which involves significant architectural work and extensive testing to ensure parity, fitting the criteria for 3+ days of effort.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nPolite suggestion for a future enhancement: evolve `--resume` so sessions can be resumed from any folder using a unique session ID.\n\nProposed protocol:\n1. Every session gets a unique ID.\n2. When exiting the CLI, show the exact resume command with the ID (for example: `gemini --resume <session-id>`).\n3. `--resume <session-id>` can resume that session from any folder.\n4. `--resume` without an ID still works and keeps folder-structure-based behavior (resume if there is resumable context in the current folder structure).\n\n### Why is this needed?\n\nDevelopers often rename or move folders, switch worktrees, or continue work from a different directory. A folder-bound resume flow can fail in these cases.\n\nSession-ID-based resume makes continuation robust even when the project structure changes, while preserving the convenient no-ID flow for local folder-based resume.\n\n### Additional context\n\nIf `--resume <session-id>` is used from a folder that does not match the original session folder, the CLI should show a clear warning and offer a choice to continue resume or cancel.\n\nThis is just a suggestion for future planning, and details can be adjusted by maintainers.\n",
"number": 20480,
"title": "Feature: evolve --resume to support resuming sessions from any folder via session ID",
"url": "https://github.com/google-gemini/gemini-cli/issues/20480",
"analysis": "Enhance the `--resume` command to support globally addressable session IDs, allowing users to resume a session from any folder regardless of where it was originally started.",
"effort_level": "medium",
"reasoning": "Implementing global session IDs requires modifying the session storage and retrieval logic to support cross-directory lookups. This involves updating the CLI argument parser to handle optional IDs, modifying the session manager to scan a global directory (e.g., ~/.gemini/sessions), and ensuring the UI displays the ID upon exit. It falls under Medium effort as it involves logic tracing, filesystem path resolution, and integration across the CLI, session management, and UI components.",
"recommended_implementation": "Update `resolveSession` in `packages/cli/src/utils/sessions.ts` to perform a recursive search in the global sessions root if the provided identifier does not match any session in the current project's subdirectory.",
"validated": true
},
{
"body": "### What would you like to be added?\nWe propose adding an Extension UI API that allows Gemini CLI extensions to contribute dynamic status segments to the application's Footer (Status Bar).\n\nCurrently, extensions can provide MCP servers, Hooks, and Skills, but have no way to expose environmental context visually to the user. We propose extending the `gemini-extension.json` schema (or adding a new mechanism) that allows an extension to register an asynchronous script/command or hook. The returned text/data would be rendered as a badge alongside the existing system info within `packages/cli/src/ui/components/Footer.tsx`.\n\n### Why is this needed?\nUsers often work across multiple complex environments simultaneously (e.g., different `gcloud` projects, Python `virtualenvs`, or Kubernetes contexts). It is crucial for users to see their active context at a glance while using the CLI to prevent executing commands or AI actions in the wrong environment.\n\nWhile developers can configure their shell prompts (like Zsh's Powerlevel10k) to show this data, the Gemini CLI interactive UI currently lacks a mechanism to display these dynamic environmental states natively. By allowing extensions to contribute to the Footer, the community can build plugins (e.g., a \"GCP Extension\", a \"Python Extension\") that seamlessly surface this vital context in the exact place users already look for system information.\n\n### Additional context\n- This approach avoids cluttering the main interactive input prompt line.\n- It fits perfectly into the existing, highly-extensible Extension architecture.\n- It keeps the core CLI lean, offloading domain-specific polling (like parsing `gcloud config get-value project` or checking `$VIRTUAL_ENV`) to the respective extensions rather than hardcoding it into the core UI.",
"number": 20476,
"title": "Allow extensions to contribute status segments to the Footer",
"url": "https://github.com/google-gemini/gemini-cli/issues/20476",
"analysis": "Implement a plugin system that allows CLI extensions to contribute custom status segments (text or icons) to the TUI footer bar.",
"effort_level": "medium",
"reasoning": "This task requires modifying the extension manifest schema, updating the ExtensionLoader to register new contribution types, and implementing state synchronization between the extension lifecycle and the Ink-based Footer component. It involves handling asynchronous data flows from external scripts or hooks and ensuring the UI updates reactively, which fits the criteria for Medium effort involving state management and service integration.",
"validated": true
},
{
"body": "## Summary\nIt is currently cumbersome to switch between models (e.g., between pro and flash) via the model selection dialog or by restarting the CLI with the --model flag.\n\n## Proposed Change\nAdd keyboard shortcuts to cycle through available models and allow users to mark certain models as favorites to restrict the cycling rotation.\n\n## Implementation Details\n1. Add Alt + C (forward) and Alt + X (backward) shortcuts for model cycling.\n2. Add a \favoriteModels setting in the configuration.\n3. Update the ModelDialog to allow toggling favorites with the F key.\n4. Show a visual indicator (\u2605) for favorite models.\n5. Implement the cycling logic in the Config class.",
"number": 20227,
"title": "feat(cli): Add ability to cycle through models and mark favorites",
"url": "https://github.com/google-gemini/gemini-cli/issues/20227",
"analysis": "Add a feature to cycle through available models using a keyboard shortcut and allow users to mark specific models as favorites for quick access.",
"effort_level": "medium",
"reasoning": "Implementing model cycling and favorites requires changes across multiple layers: updating the configuration schema (Zod), modifying the ModelDialog Ink component for stateful toggling, and implementing global keyboard listeners for cycling. This involves state synchronization between the configuration and the active UI session, which fits the criteria for Medium effort involving React/Ink state management and integration across components.",
"recommended_implementation": "Add `ui.favoriteModels` to `settingsSchema.ts`. In `packages/cli/src/ui/contexts/KeypressContext.tsx`, map a new shortcut (e.g., `Ctrl+M`) to a function that calls `config.setNextFavoriteModel()`.",
"validated": true
},
{
"body": "Overview\nThe current Gemini-CLI lacks native support for oneMCP. To align with the evolving MCP ecosystem and streamline our authentication logic, we have refactored the CLI to integrate the MCPSDK. This transition replaces our internal \"roll-your-own\" authentication implementation with a standardized industry approach.\n\nProblem Statement\nPreviously, the Gemini-CLI relied on a custom authentication implementation. This created several points of friction:\n\nMaintenance Overhead: Maintaining duplicate authentication logic within the CLI increased the surface area for bugs.\n\nManual Scope Management: The legacy system required manual handling of permissions, which was prone to misalignment with MCP standards.\n\nEcosystem Drift: Without SDK integration, staying up-to-date with the rapidly changing MCP world was a manual and tedious process.\n\nProposed Changes\nWe have implemented a comprehensive update to the Gemini-CLI to support oneMCP natively:\n\n1. MCPSDK Integration\nThe codebase has been refactored to utilize the MCPSDK as the primary handler for authentication. By delegating these responsibilities to the SDK, we ensure the CLI follows the most current standards without redundant code.\n\n2. Graceful Scope Discovery\nOne of the primary benefits of this update is the ability to gracefully discover scopes for oneMCP. The SDK handles the negotiation of permissions automatically, providing a more seamless experience for the end-user.\n\n3. Codebase Refactoring\nRemoved deprecated internal auth modules. Updated the CLI handshake logic to interface directly with MCPSDK endpoints.Standardized error handling for authentication failures.\n\nKey Benefits\nReduced Complexity: Eliminating custom auth code reduces technical debt and makes the CLI easier to maintain.\n\nBetter Tracking: Using the official SDK allows us to stay in sync with the MCP ecosystem with minimal effort.\n\nImproved Security: Leveraging a standardized SDK ensures that authentication follows best practices and receives security updates as they are released.",
"number": 20118,
"title": "Add oneMCP Support to Gemini-CLI via MCPSDK Integration",
"url": "https://github.com/google-gemini/gemini-cli/issues/20118",
"analysis": "Integrate the 'oneMCP' SDK into the core MCP management layer to enhance compatibility with a broader range of server types and protocol versions.",
"effort_level": "large",
"reasoning": "Integrating the MCPSDK to replace a custom authentication and protocol implementation is a significant architectural change to a core subsystem. According to the criteria, modifications to the Model Context Protocol (MCP) integrations and major subsystem refactoring fall under the 'Large' effort level, as it involves deep logic changes in mcp-client-manager.ts and potentially impacts tool discovery and execution flows.",
"validated": true
},
{
"body": "### What would you like to be added?\nI'd like to propose adding support for live output streaming (via both `stdout` and `stderr`) for custom tools discovered via the `discoveryCommand`. This would involve:\n\n1. **Discovery Flag:** Supporting a `canUpdateOutput` flag in the discovery JSON schema so custom tools can opt-in to live UI updates.\n2. **Live Stderr Relay:** Enabling the CLI core to relay `stderr` chunks to the UI in real-time, just like it does for built-in tools.\n3. **Flexible Error Logic:** Updating the execution check so that output on `stderr` doesn't automatically trigger a \"tool failure\" if the process actually exits with code 0.\n\n### Why is this needed?\nI was hacking on a custom tool that displays a live progress bar in the terminal and realized that for discovered tools, the CLI currently buffers all output and only displays it once the process finally exits. This makes it tricky to build interactive custom tools or anything that needs to show progress over time. \n\nAlso, since `stderr` is currently treated as a fatal error, I can't easily separate my \"UI/progress\" output (on `stderr`) from the \"actual data\" (on `stdout`) without the CLI flagging the whole thing as a failure at the end.\n\n### Additional context\nWhile digging around in `packages/core/src/tools/tool-registry.ts`, I noticed a few things that could be tweaked to support this:\n\n1. **Hardcoded Flag:** The `DiscoveredTool` class currently has `canUpdateOutput` hardcoded to `false` in the constructor.\n2. **Stderr Handling:** `DiscoveredToolInvocation.execute` treats the presence of *any* data on `stderr` as a tool failure. \n3. **Execution Loop:** The current loop buffers `stdout` and `stderr` instead of relaying chunks to the `_updateOutput` callback as they arrive.\n\nI'm happy to discuss this further or put together a PR if there's interest!\n",
"number": 19835,
"title": "Support for live streaming in custom discovered tools",
"url": "https://github.com/google-gemini/gemini-cli/issues/19835",
"analysis": "Enable live output streaming for custom tools discovered via extensions or the workspace, allowing them to report progress and partial results back to the TUI.",
"effort_level": "medium",
"reasoning": "Implementing live streaming for custom tools requires modifying the tool execution pipeline to handle asynchronous process streams instead of simple buffered output. This involves updating the discovery schema, adjusting the Scheduler's handling of tool results, and managing real-time state updates in the Ink-based UI components, which aligns with the criteria for logic tracing and state synchronization across multiple components.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nnpm install -g @google/gemini-cli\n\n### Why is this needed?\n\nnpm install -g @google/gemini-cli\n\n### Additional context\n\n_No response_",
"number": 19757,
"title": "gemininpm install -g @google/gemini-cli",
"url": "https://github.com/google-gemini/gemini-cli/issues/19757",
"analysis": "Correct a typo or formatting error in the CLI help text or documentation regarding the installation command.",
"effort_level": "small",
"reasoning": "The issue involves correcting a typo in the installation command within the documentation or CLI help text. This is a static content update that is highly localized and does not affect application logic, fitting the criteria for a Small effort level.",
"recommended_implementation": "Locate the string 'gemininpm' in the project (likely in `README.md` or a command description) and correct it to 'npm'.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nIf the terminal is wide enough, we should show full file paths\n\nb/485441037 for more\n\n### Why is this needed?\n\nThe width of the suggestion UI should dynamically adjust to the terminal width, utilizing the available space to show more of the file path and reduce unnecessary truncation.\n\n\n### Additional context\n\n_No response_",
"number": 19672,
"title": "Truncate filepaths based on terminal width",
"url": "https://github.com/google-gemini/gemini-cli/issues/19672",
"analysis": "Implement smart path truncation in the TUI to ensure that long file paths are abbreviated (e.g., using '...') based on the current terminal width.",
"effort_level": "small",
"reasoning": "This is a localized UI enhancement involving a string manipulation utility and updates to a few Ink components to react to terminal width. It falls under UI/Aesthetic adjustments and trivial logic for formatting data types, fitting the criteria for a task completed in less than a day.",
"recommended_implementation": "Add a `truncatePath(path: string, maxLength: number)` helper to `packages/cli/src/ui/utils/textUtils.ts` that preserves the filename and leading directories while contracting the middle. Use this in `AppHeader` for the workspace path.",
"validated": true
},
{
"body": "There is a TODO in gemini.tsx (line 502) left by jacobr that reads:\n\nrefactor loadCliConfig so there is a minimal version that only initializes enough config to enable refreshAuth or find another way to decouple refreshAuth from requiring a config.\n\nCurrently, loadCliConfig in packages/cli/src/config/config.ts is a 440-line function that initializes everything in a single pass: FileDiscoveryService, ExtensionManager, loadServerHierarchicalMemory, approval mode resolution, policy engine configuration, MCP server setup, and the full Config constructor with 80+ parameters.\n\nThe problem is that gemini.tsx calls loadCliConfig at line 434 just to run refreshAuth, which only needs a small subset of the config: sessionId, model, proxy, debugMode, telemetry, and sandbox configuration. All the heavy initialization (file discovery, extension loading, memory scanning) is wasted work for this auth bootstrap path.\n\nThis is not a theoretical concern. #5056 reported that config files were loaded twice when running from the home directory. #5090 fixed the immediate symptom with path deduplication, but the underlying architectural issue remains: there is no way to get a lightweight config for operations that do not need the full environment. Similarly, #5605 showed that .env loading order matters relative to settings parsing, another consequence of the all-or-nothing initialization.\n\nI am proposing to:\n\nAdd a loadMinimalCliConfig function that creates a Config object sufficient for refreshAuth without running FileDiscoveryService, ExtensionManager, or loadServerHierarchicalMemory.\n\nUse this minimal loader in gemini.tsx for the auth bootstrap call, keeping the full loadCliConfig for later when the complete environment is actually needed.\n\nExtract the duplicated approval mode resolution logic into a shared helper so both functions stay in sync without code duplication.\n\nAdd before/after startup timing benchmarks to measure the actual improvement.\n\nAs a stretch goal, look into settings caching (there is another TODO at gemini.tsx line 324 about caching settings in sandbox mode).\n\nI have a working prototype in a draft PR that passes typecheck, lint, and unit tests. The prototype demonstrates the basic approach: loadMinimalCliConfig skips the three heaviest operations and produces a valid Config for refreshAuth. The draft is intentionally minimal and would benefit from maintainer feedback on the right level of decomposition.\n\nRelated issues and context:\n\n#5056: load GEMINI.md and settings.json twice (closed, fixed by #5090 with path deduplication)\n#5605: .env environment loaded after settings are parsed (config loading order issue)\nThe TODO(jacobr) at gemini.tsx line 502\nThe TODO at gemini.tsx line 324 about settings caching\n\nI am working on this as part of a GSoC 2026 proposal. This refactoring aligns with the goals of the Performance Monitoring and Optimization Dashboard idea from the GSoC ideas list, since it provides the startup performance optimization foundation that such a dashboard would measure and display.",
"number": 19661,
"title": "Refactor loadCliConfig to support a minimal initialization path for auth bootstrap",
"url": "https://github.com/google-gemini/gemini-cli/issues/19661",
"analysis": "Refactor the configuration loading process to support a 'minimal' initialization mode, specifically for bootstrapping authentication without requiring a full workspace check.",
"effort_level": "medium",
"reasoning": "Refactoring a 440-line core initialization function with 80+ parameters into a tiered or decoupled structure requires significant logic tracing and state management. It involves identifying and isolating dependencies like FileDiscoveryService and ExtensionManager to create a 'minimal' path for auth, which necessitates careful validation to ensure no regressions in the primary CLI execution flow.",
"validated": true
},
{
"body": "### What happened?\n\nFeature Request\nCurrently, the dialogue with Gemini is possible in Korean, but the built-in CLI interface (commands like '/', he\n text, and descriptions) is only provided in English. This creates a barrier for Korean users.\n Please add a feature to allow users to change the CLI's UI language to Korean via settings or environment\n variables.\n[ACTION REQUIRED] \ud83d\udcce PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.\n\n### What did you expect to happen?\n\nCurrently, the dialogue with Gemini is possible in Korean, but the built-in CLI interface (commands like '/', he\n text, and descriptions) is only provided in English. This creates a barrier for Korean users.\n Please add a feature to allow users to change the CLI's UI language to Korean via settings or environment\n variables.\n\n### Client information\n\n\n* **CLI Version:** 0.29.5\n* **Git Commit:** 2ef872e73\n* **Session ID:** 8ba7c1fe-e681-4f79-9e49-9ed51443ffe0\n* **Operating System:** darwin v22.14.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-3\n* **Auth Type:** oauth-personal\n* **Memory Usage:** 203.3 MB\n* **Terminal Name:** Unknown\n* **Terminal Background:** #181818\n* **Kitty Keyboard Protocol:** Unsupported\n* **IDE Client:** Antigravity\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 19619,
"title": "Request for Korean translation of CLI interface (commands and descriptions)",
"url": "https://github.com/google-gemini/gemini-cli/issues/19619",
"analysis": "Add internationalization (i18n) support and provide a Korean translation for the CLI's commands, descriptions, and user interface elements.",
"effort_level": "large",
"reasoning": "Implementing internationalization (i18n) is a cross-cutting architectural change that requires introducing a new subsystem. It involves refactoring all hardcoded strings across the entire codebase, implementing a translation management framework, and adding configuration logic for locale switching, which fits the criteria for a major subsystem implementation.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like it if the gemini CLI would allow you to specific a UUID, just like claude does, at the command line. For example, claude let's you do:\n\n```bash\nclaude --session-id <some-uuid> -p \"please take a look at...\"\n```\n\nwhich can then be fed back in via the `-r <uuid>` flag in claude.\n\n### Why is this needed?\n\nThis flag is needed for better automation of Gemini when abstracted. Right now, if a user has another bot or system that shells out to Gemini for an edit, and a follow up needs to happen, we can't pre-seed a path for a codebase location with a UUID, because the UUID is not known until Gemini runs. With Claude, we can do:\n\n1) Generate a UUIDv4\n\n2) Checkout our code into `/path/to/sandbox/<uuid>`\n\n3) Open claude with the session id set to `<uuid>`\n\n4) Revisit the work/checkout with the same UUID.\n\nWith Gemini, we would need to\n\n1) Generate a UUIDv4\n\n2) Checkout our code into `/path/to/sandbox/<uuid>`\n\n3) Open Gemini and run the prompt\n\n4) Capture the UUID returned by Gemini via `-o json`\n\n5) Store both the folder location UUID and the Gemini UUID as a pair so that we can map a folder -> session\n\nBy letting us provide our own session id, we can remove a step of complexity that's not needed.\n\n### Additional context\n\nPlease and thank you :)",
"number": 19602,
"title": "Feature: Manually provide new session UUID via command line arg",
"url": "https://github.com/google-gemini/gemini-cli/issues/19602",
"analysis": "Provide an option to manually specify a session UUID via a command-line argument when starting the CLI.",
"effort_level": "small",
"reasoning": "Adding a command-line flag to expose an existing configuration property is a straightforward task. It involves updating the Yargs definition and ensuring the value is passed to the Config instance, which is a localized change with minimal logic complexity.",
"recommended_implementation": "Add the `--session <uuid>` option to the Yargs configuration in `packages/cli/src/config/config.ts` and use it to initialize the `Config` instance in `gemini.tsx`.",
"validated": true
},
{
"body": "### Description\nCurrently, the policy engine uses broad permissions for skill activation. When a user chooses to 'always allow' skill activation, the decision is applied globally to all skills. \n\nTo improve security and user control, we need to implement granular permissions that restrict 'always allow' decisions to specific skill names.\n\n### Proposed Changes\n- Extend UpdatePolicy and PolicyUpdateOptions to support a skillName property.\n- Update createPolicyUpdater and buildArgsPatterns to generate regex-based rules matching specific skill names in tool arguments.\n- Integrate ActivateSkillToolInvocation with the updated policy engine to capture and persist these skill-specific authorizations.",
"number": 19583,
"title": "feat(policy): support granular skill activation permissions",
"url": "https://github.com/google-gemini/gemini-cli/issues/19583",
"analysis": "Extend the policy engine to support granular permissions for activating and using specific agent skills.",
"effort_level": "medium",
"reasoning": "The task requires integrating changes across several layers of the application: updating policy schemas and types, modifying the rule generation logic to support regex-based argument matching for specific skills, and updating the tool invocation flow to capture and persist these granular permissions. This involves logic tracing and state synchronization between the UI/CLI decision and the policy engine's persistence layer, fitting the criteria for a medium effort task.",
"validated": true
},
{
"body": "## Feature request\n\n### Problem\nWhen using Gemini CLI as an ACP (Agent Client Protocol) agent via `zed-integration`, there is no mechanism to report token usage statistics to ACP clients. ACP clients like desktop dashboards have no visibility into how many tokens each prompt turn consumes.\n\n### Proposed solution\nCapture `usageMetadata` (`promptTokenCount`, `candidatesTokenCount`) from the Gemini API stream chunks in `Session.prompt()` and send accumulated token counts as a `thread/tokenUsage/updated` `extNotification` after each prompt turn completes.\n\nThis is purely additive \u2014 no changes to existing behavior. The notification is only sent when token counts are non-zero.\n\n### Use case\nACP clients displaying event timelines or token usage dashboards can use this notification to show real-time token consumption per prompt turn.\n\n### Additional context\nI have a working implementation ready to submit as a PR once this issue is approved. The change is minimal (~30 lines) and confined to `packages/cli/src/zed-integration/zedIntegration.ts`.",
"number": 19249,
"title": "feat: emit token usage metadata via ACP extNotification in zed-integration",
"url": "https://github.com/google-gemini/gemini-cli/issues/19249",
"analysis": "Broadcast token usage metadata via ACP extension notifications for use in the Zed editor integration.",
"effort_level": "small",
"reasoning": "The change is highly localized to the ACP server implementation within the zed-integration package. It involves capturing existing metadata from the Gemini API stream and emitting a standard notification, requiring minimal logic (~30 lines) and no architectural changes.",
"recommended_implementation": "In `packages/core/src/code_assist/server.ts`, locate the end of the `sendMessage` handler and call `sendNotification('gemini/usageUpdate', stats)` to push the metadata to the connected host.",
"validated": true
},
{
"body": "### What would you like to be added?\n\ni can use `/stats` to see the current Status , Session Stats , especialy Model Usage . but how i can use `gemini -p` to check if my model quota is running out.\n\n### Why is this needed?\n\nBecause the credit limit is frequently exhausted.\n\n### Additional context\n\n_No response_",
"number": 19067,
"title": "use `/stats` to see the current Status , but how can use `gemini -p` to see current Status.",
"url": "https://github.com/google-gemini/gemini-cli/issues/19067",
"analysis": "Add the ability to view cumulative session statistics using the non-interactive `--prompt` mode.",
"effort_level": "small",
"reasoning": "The TelemetryService already tracks the required usage statistics. Implementing this feature involves a localized change to the non-interactive execution path (likely in the CLI entry point) to retrieve and display these existing metrics after a prompt is processed, fitting the criteria for trivial logic and formatting.",
"recommended_implementation": "Add a `--stats` boolean flag to `packages/cli/src/config/config.ts`. In `nonInteractiveCli.ts`, if this flag is set, fetch the stats from the telemetry service and log them to stdout before exiting.",
"validated": true
},
{
"body": "### What happened?\n\nAs of Jan 12, 2026, the Gemini inline files API has supported 100MB files (up from the old limit of 20MB). However, the Gemini CLI still has a hardcoded limit of reading 20MB files. \n\nVisible here: https://github.com/google-gemini/gemini-cli/blob/b16c9a5ebd39246196a0e0146944fb207f24df74/packages/core/src/utils/fileUtils.ts#L436\n\n### What did you expect to happen?\n\nI expected files up to 100MB to be successfully read by the Gemini CLI. After editing that line locally and rebuilding the project, the CLI is able to read the files without issue. \n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n\u2502 \u2502\n\u2502 CLI Version 0.28.2 \u2502\n\u2502 Git Commit da5e47ae3 \u2502\n\u2502 Model auto-gemini-3 \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS darwin\n```\n\n</details>\n\n### Login information\n\nGoogle AI Pro account\n\n### Anything else we need to know?\n\nHere's documentation of the change on Jan 12: https://blog.google/innovation-and-ai/technology/developers-tools/gemini-api-new-file-limits/\n\nI can make a PR if that would help.\n\nExample of the 1-line change working\n\n<img width=\"590\" height=\"62\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/55f1b7d1-fbec-44a2-9048-4fb509107d77\" />\n\nCurrent prod Gemini CLI\n\n<img width=\"816\" height=\"131\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/4a07fc68-a2d0-4bd9-8bf0-9fa1b8630126\" />\n\nMy local modification and the summary worked (excluded from screenshot)\n\n<img width=\"717\" height=\"137\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/53d23dd3-b7f3-4f5f-8362-4f24c45062ac\" />",
"number": 19018,
"title": "Update the file size limit for inline files to 100MB",
"url": "https://github.com/google-gemini/gemini-cli/issues/19018",
"analysis": "Increase the maximum allowable file size for inline `@` mentions and direct file reads to 100MB.",
"effort_level": "small",
"reasoning": "The task involves updating a single constant value (MAX_FILE_SIZE_MB) or a hardcoded numeric limit within the file utility layer. This is a trivial configuration change that is highly localized to one or two files and requires no complex logic or architectural adjustments.",
"recommended_implementation": "In `packages/core/src/utils/fileUtils.ts`, locate the `MAX_FILE_SIZE_BYTES` constant and update its value to `100 * 1024 * 1024`.",
"validated": true
},
{
"body": "### What happened?\n\n[bug-report-history-1770994247371.json](https://github.com/user-attachments/files/25293997/bug-report-history-1770994247371.json)\n\nFeature Request: The CLI input prompt does not support Tab-completion for file paths, which makes working with files inconvenient. Please consider adding this standard shell feature to improve usability.\n\n[ACTION REQUIRED] \ud83d\udcce PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.\n\n### What did you expect to happen?\n\nI expect that when typing a partial file or directory path into the interactive input prompt of Gemini CLI (both for general prompts and command line mode), pressing the Tab key (or equivalent) should automatically complete the path to the best possible match or present a list of possible \u0441ompletions.\nThis is standard behavior for most interactive command-line interfaces and significantly enhances the convenience of working with files.\n\n### Client information\n\n\n* **CLI Version:** 0.28.2\n* **Git Commit:** da5e47ae3\n* **Session ID:** e1ad2e45-875a-48b5-8774-7da1fb5cbf06\n* **Operating System:** linux v22.15.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-2.5\n* **Auth Type:** oauth-personal\n* **Memory Usage:** 424.7 MB\n* **Terminal Name:** Unknown\n* **Terminal Background:** #0c0c0c\n* **Kitty Keyboard Protocol:** Unsupported\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 18990,
"title": "Feature Request: The CLI input prompt does not support Tab-completion for file paths, which makes working with files inconvenient. Please consider adding this standard shell feature to improve usability.",
"url": "https://github.com/google-gemini/gemini-cli/issues/18990",
"analysis": "Implement standard shell-style Tab-completion for file paths directly in the input prompt, without requiring the `@` prefix.",
"effort_level": "medium",
"reasoning": "Implementing shell-style tab completion requires refactoring the existing completion logic in useAtCompletion.ts to decouple it from the '@' trigger. This involves managing React/Ink state for the input buffer, integrating with the FileDiscoveryService for real-time path resolution, and handling asynchronous search results within the TUI, which fits the criteria for logic tracing and state synchronization across components.",
"validated": true
},
{
"body": "### What would you like to be added?\r\nI would like to suggest a new command, for example `/exit-delete` or an option for the `/exit` command, that allows users to exit the CLI and simultaneously delete the current session's history and temporary files.\r\n\r\n### Why is this needed?\r\nFor users who value privacy or only want to perform a one-off task without leaving any traces in the `~/.gemini/tmp/` directory, the current workflow requires manually identifying and deleting the session or configuring strict retention policies. A simple command to \"exit and wipe\" would provide a much smoother experience for these scenarios.\r\n\r\n### Additional context\r\nThis would complement the existing `/chat delete` command by automating the process at the end of a workflow.",
"number": 18871,
"title": "[Feat] Add a command to delete current session upon exit",
"url": "https://github.com/google-gemini/gemini-cli/issues/18871",
"analysis": "Add a new command or flag to allow users to delete the current session's data (history and metadata) upon exiting the CLI.",
"effort_level": "small",
"reasoning": "The session deletion logic is already implemented in the codebase. This task only requires adding a new slash command or a flag to the existing exit command and calling the existing deletion utility before process termination. This is a localized change involving trivial logic and fits the criteria for a small effort level.",
"recommended_implementation": "Add an `exit --delete` subcommand in `packages/cli/src/ui/commands/exitCommand.ts`. The action should trigger `sessionSelector.deleteSession()` for the current active UUID before terminating the process.",
"validated": true
},
{
"body": "### Problem Description\nWhen the Gemini CLI executes commands via \\\run_shell_command\\, specifically those that are interactive or long-running (e.g., starting a development server like \\\npm run dev\\, initiating a database process, or running a file watcher), the agent enters a blocking state.\n\nThere is currently no graceful way to 'interrupt' this state to retrieve the logs generated so far without risking data loss:\n1. **Ctrl+C / Cancellation:** Often results in the tool call failing or returning no output to the agent. The agent knows the command was cancelled but cannot 'see' what happened in the terminal prior to cancellation.\n2. **Hard Timeouts:** Waiting for a timeout is inefficient and creates friction in the user experience.\n\n### Proposed Solution\nIntroduce a **'Stop Waiting'** / **'Manual Timeout'** feature in the command execution interface.\n\n**Functionality:**\n- **User Interface:** A visual button or a specific keyboard shortcut available while a command is running.\n- **Behavior:** Upon activation, the CLI should:\n 1. Stop waiting for the subprocess to exit naturally.\n 2. Gracefully terminate the subprocess (or allow configuration to leave it running in background if supported).\n 3. **Crucially:** Return the accumulated \\stdout\\ and \\stderr\\ buffer to the agent as the tool's output.\n\n### Use Case Example\nAn agent is asked to 'Start the React app and check for errors.'\n1. Agent runs \\\npm start\\.\n2. The process hangs (as expected for a server).\n3. The user sees 'Starting development server...' and 'Compiled successfully!' in the window.\n4. The user presses **'Stop Waiting'**.\n5. The agent immediately receives the string: \\'Starting development server...\\nCompiled successfully!'\\.\n6. The agent can then proceed to the next step, knowing the server started correctly, instead of timing out or assuming failure.",
"number": 18761,
"title": "[Feature Request] Interactive 'Stop Waiting' mechanism to capture partial output from blocking commands",
"url": "https://github.com/google-gemini/gemini-cli/issues/18761",
"analysis": "Implement an interactive 'Stop Waiting' mechanism that allows users to interrupt a long-running shell command and capture its partial output as the tool result.",
"effort_level": "medium",
"reasoning": "Implementing a 'Stop Waiting' mechanism requires state synchronization between the TUI (Ink components) and the ShellToolInvocation via the MessageBus. It involves modifying the asynchronous execution flow to handle a manual interrupt signal, ensuring the child process is terminated gracefully while the ShellExecutionService flushes and returns the partial output buffer instead of a standard error or empty result.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA new `doctor` command (command line, and `/doctor` slash command) should be added to gemini-cli to help users verify and troubleshoot their installation and configuration. This command will perform a series of automated checks and return a success (0) or failure (1) exit code based on the results.\n\n The `doctor` command should cover:\n - **Installation Health**: Verify if the tool is correctly installed and accessible via npm.\n - **Auto-updates**: Check if automatic updates are enabled and functioning, or verify if the current version is up-to-date.\n - **Permissions**: Ensure the tool has the necessary system permissions to operate and modify files as required.\n - **Configuration Status**: Display the current version and a summary of configuration details.\n - **Validation**:\n - Verify that all configured extensions, skills, and MCP servers load correctly. For example, extensions that will be skipped because of missing files or config keys.\n - Validate `@` imports in context files to ensure all referenced resources are resolvable.\n - Where links are supported, validate that links resolve.\n\n### Why is this needed?\n\nA `doctor` command provides a unified diagnostic tool that allows users to quickly identify if an issue is caused by their environment, permissions, or a specific misconfiguration in their extensions/skills. This will significantly reduce the friction in troubleshooting and provide better information for bug reports.\n\n### Additional context\n\nThe goal is to provide a \"one-stop shop\" for environment verification, similar to `flutter doctor` or `brew doctor`, ensuring that all components are healthy before deep-diving into specific agent behaviors.",
"number": 18692,
"title": "`doctor` command for installation and configuration troubleshooting",
"url": "https://github.com/google-gemini/gemini-cli/issues/18692",
"analysis": "Implement a `doctor` command to provide a diagnostic overview of the installation, authentication state, and configuration to aid in troubleshooting.",
"effort_level": "medium",
"reasoning": "Implementing a diagnostic suite requires integrating with multiple subsystems including MCP servers, extensions, and configuration management. It involves logic tracing across these components to validate loading states and filesystem permissions, as well as handling asynchronous checks for updates and network connectivity, fitting the criteria for service integration and async flow management.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n**Is your feature request related to a problem? Please describe.**\nCurrently, extracting specific portions of the chat history or copying long responses without formatting issues is difficult.\n* **The `/copy` command** works well but is limited to only the *last* output/model response.\n* **The Copy Mode (`Ctrl+S`)** allows for scrolling and selection, but it captures the terminal's \"hard\" line breaks. When pasting this text elsewhere, the formatting is often broken because it includes the line breaks where the terminal wrapped the text, rather than the original markdown structure.\n\n**Describe the solution you'd like**\nI propose a new command, **`/copy_editor`** (or a distinct hotkey), that leverages the existing logic used for `Ctrl+X` (editing the prompt).\n\n1. When triggered, the CLI pipes the **entire current chat session** (User prompts + Model responses) into the user's configured external editor (Vim, Nano, VS Code, etc.).\n2. Once inside the editor, the user has full freedom to scroll, search, select, and copy exactly what they need without terminal line-wrapping artifacts.\n3. Upon closing the editor, no changes are made to the actual context; it is simply a \"view/copy\" operation.\n\n**Why this is the preferred solution:**\n* **Simplicity:** It reuses the existing `Ctrl+X` external editor integration logic.\n* **Flexibility:** Users can use the powerful text manipulation tools of their preferred editors (regex search, visual block selection, etc.).\n* **Cleanliness:** It avoids the need to build a complex TUI specifically for copying.\n\n**Describe alternatives you've considered**\nAn alternative approach would be to expand the **`/copy`** command into an interactive TUI selection screen:\n* Running `/copy` opens a list of the conversation history.\n* Users navigate up/down with **Arrow Keys**.\n* **Spacebar** toggles selection of specific message blocks.\n* **Enter** copies all selected blocks to the clipboard.\n* **Esc** exits without copying.\n\nWhile this would be a cool feature, I believe the **`/copy_editor`** approach mentioned above is superior because it is easier to implement and offers the user more control over the text.\n\n**Additional context**\nExisting commands like `/copy` and `Ctrl+S` should remain as they are for quick, simple actions. This new feature is specifically for users who need to extract high-fidelity text or large chunks of conversation history.\n\n### Why is this needed?\n\nSee above. \n\n### Additional context\n\n_No response_",
"number": 18654,
"title": "Enhanced Copy Workflow via External Editor Integration",
"url": "https://github.com/google-gemini/gemini-cli/issues/18654",
"analysis": "Enhance the copy workflow by allowing users to pipe the current chat history or specific code blocks into their external system editor (e.g., vim, nano).",
"effort_level": "medium",
"reasoning": "Implementing the /copy_editor command requires serializing the chat history into a formatted markdown string, managing temporary file lifecycle, and integrating with the existing editor utility. This involves state synchronization (retrieving the full session history) and handling asynchronous process execution for both terminal and GUI-based editors, which aligns with the Medium effort criteria for service integration and async flow management.",
"validated": true
},
{
"body": "### What happened?\n\nWhen having multiple folders opened in VSCode, it is impossible to tell gemini to use a different folder as context than the first one in the folders overview. It seems that it is impossible to have folders on the same level to be used by gemini context. Even adding the folder explicitly to the context does not work.\n\n\n### What did you expect to happen?\n\nI am able to tell Gemini which folder he should have a look into.\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\nI am Gemini Code Assist, a very experienced and world-class software engineering coding assistant. I am designed to help you with a wide range of programming tasks, including:\n\nCode Explanation: I can break down complex code snippets and explain their logic and functionality.\nRefactoring: I can suggest improvements to make your code more readable, efficient, and maintainable.\nDebugging: I can help identify errors and propose fixes.\nTest Generation: I can write unit tests to ensure your code works as expected.\nCode Generation: I can generate code snippets or entire functions based on your requirements.\nI am here to assist you with your development workflow. How can I help you today?\n```\n\n</details>\n\n### Login information\n\nLogin process provided by VSCode plugin\n\n### Anything else we need to know?\n\n_No response_",
"number": 18612,
"title": "[VSCode Plugin] Unable to change root directory",
"url": "https://github.com/google-gemini/gemini-cli/issues/18612",
"analysis": "Fix a bug in the VSCode extension where users are unable to change the root workspace directory after the initial setup.",
"effort_level": "medium",
"reasoning": "The issue requires implementing or fixing event listeners for VSCode workspace changes (onDidChangeWorkspaceFolders) and ensuring the updated root path is synchronized with the CLI agent. This involves state management and cross-component communication between the VSCode extension and the backend service, fitting the criteria for logic tracing and state synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA2A Server should support multiple workspace directories instead of a single one.\n\n### Why is this needed?\n\nCurrently it support only a single directory via `CODER_AGENT_WORKSPACE_PATH` what limits applications using a2a server.\n\n### Additional context\n\nExample: a VS Code extension uses a2a and tries to pass all workspace folders. Currently we can't do that.",
"number": 18487,
"title": "A2A Server should support multiple workspace directories",
"url": "https://github.com/google-gemini/gemini-cli/issues/18487",
"analysis": "Extend the Agent-to-Agent (A2A) server to support multi-root workspaces, allowing it to manage files and context across multiple independent directories.",
"effort_level": "large",
"reasoning": "Modifying the A2A server to support multi-root workspaces is an architectural change that falls under the 'Large' criteria. It requires refactoring the core configuration loader, path resolution logic, and file discovery utilities to handle multiple independent directories, which impacts how the server manages context and executes tools across different workspace roots.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA Ui delete option (alongside enable/disable mcps) for configured MCPs to remove them entirely from config files.\n\n### Why is this needed?\n\nease of user to safely remove unused or unwanted mcps from config files\n\n### Additional context\n\n_No response_",
"number": 18388,
"title": "Delete option for MCP",
"url": "https://github.com/google-gemini/gemini-cli/issues/18388",
"analysis": "Add a delete option to the `/mcp` command to allow removing configured MCP servers from the session.",
"effort_level": "medium",
"reasoning": "Implementing a delete option for MCPs involves logic tracing and state synchronization across the mcpClientManager, the configuration persistence layer, and the Ink-based UI. It requires handling asynchronous filesystem updates and ensuring the React UI state correctly reflects the removal of the server, which aligns with the criteria for state management and service integration.",
"recommended_implementation": "In `packages/cli/src/ui/commands/mcpCommand.ts`, add a `delete <name>` subcommand that calls `agentContext.mcpClientManager.removeServer(name)` and updates the persistent config.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like to add support for recursive cloning and initialization of Git submodules when installing extensions via `gemini extensions install <url>`.\n\n### Why is this needed?\n\nCurrently, if an extension developer uses Git submodules to manage shared logic, libraries, or assets, the `install` command only performs a top-level clone. This leaves the submodule directories empty, resulting in a broken extension that requires manual user intervention (finding the hidden install directory and running git commands) to fix.\n\nSupporting submodules out-of-the-box would allow for more modular extension development and a seamless experience for users.\n\n### Additional context\n\n_No response_",
"number": 18385,
"title": "Support Git Submodules in Extensions",
"url": "https://github.com/google-gemini/gemini-cli/issues/18385",
"analysis": "Support extensions that are registered as Git submodules within the user's configuration or workspace.",
"effort_level": "medium",
"reasoning": "Supporting Git submodules requires modifying the extension installation service to handle recursive cloning or post-clone submodule initialization. This involves updating asynchronous control flows, potentially adjusting how shell commands are executed, and validating filesystem states, which fits the criteria for Medium effort involving service integration and async flow management.",
"validated": true
},
{
"body": "## The Problem\nThe Gemini CLI currently uses four different primary verbs across various namespaces to perform the same functional intent: re-initializing a component or its configuration.\n\n| Command | Current Primary Subcommand | Description |\n| :--- | :--- | :--- |\n| `/skills` | `reload` | \"Reload the list of discovered skills.\" |\n| `/mcp` | `refresh` | \"Restarts MCP servers.\" |\n| `/agents` | `refresh` | \"Reload the agent registry.\" |\n| `/extensions` | `restart` | \"Restart all extensions.\" |\n| `/memory` | `refresh` | \"Refresh the memory from the source.\" |\n\nThis fragmentation results in inconsistent help menus, unpredictable autocomplete behavior, and higher cognitive load for users.\n\n## Proposed Solution: \"Reload-First\" Standardization\n\nWe should promote **`reload`** to be the primary `name` for all such operations across the CLI. The existing verbs should be moved to `altNames` for backwards compatibility.\n\n### Benefits\n1. **Consistency**: Help menus (`/mcp -h`) and autocomplete suggestions will consistently offer `reload`.\n2. **Predictability**: Users can reliably guess the command for any component once they learn the `reload` pattern.\n3. **No Breaking Changes**: Existing workflows using `/mcp refresh` or `/extensions restart` will continue to work because the command processor matches against `altNames`.\n\n### Implementation Strategy\nFor each affected command, we will swap the primary `name` to `reload` and add the old verb to the `altNames` array.\n\n#### Example: MCP Command\n```typescript\n// packages/cli/src/ui/commands/mcpCommand.ts\n{\n name: 'reload', // New primary name\n altNames: ['refresh'], // Preserved for compatibility\n description: 'Reloads and restarts MCP servers',\n action: refreshAction,\n}\n```\n\n## Proposed Changes\n- [ ] **MCP**: Change `refresh` -> `reload`, add `altNames: ['refresh']`.\n- [ ] **Agents**: Change `refresh` -> `reload`, add `altNames: ['refresh']`.\n- [ ] **Extensions**: Change `restart` -> `reload`, add `altNames: ['restart']`.\n- [ ] **Memory**: Change `refresh` -> `reload`, add `altNames: ['refresh']`.\n- [ ] **Skills**: (Already `reload`, no change needed).",
"number": 18345,
"title": "RFC: Standardize \"Reload/Refresh\" Command Naming Conventions",
"url": "https://github.com/google-gemini/gemini-cli/issues/18345",
"analysis": "Standardize the naming of 'Reload' and 'Refresh' commands across all subsystems (Agents, Extensions, Skills) to improve consistency.",
"effort_level": "small",
"reasoning": "This task involves updating command metadata (names and aliases) across a few files to ensure naming consistency. It is a localized string-level change that does not impact core logic, state management, or complex asynchronous flows, fitting the criteria for a small effort level.",
"recommended_implementation": "Update the `name` and `aliases` properties in `agentsCommand.ts`, `extensionsCommand.ts`, and `skillsCommand.ts` to use a unified 'reload' verb.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nAs a hook user in both Claude and Gemini, I've noticed some idiosyncrasies in the latter's implementation that limit what I can automate. Specifically, they seem to diverge around permission requests + decision control for tool use.\n\n---- \n\nThe primary difference I've observed is in the timing of the `PreToolUse` / `BeforeTool` hooks: \n\n- **Claude**\n - `PreToolUse` fired **before** permission dialog displayed\n- **Gemini**\n - `BeforeTool` fired **after** permission dialog interaction\n\nClaude approach makes sense to me -- because `PreToolUse` has decision control and is fired first, the hook has a chance to auto-approve/deny and skip the permission dialog altogether. \n\nIn Gemini, the permission dialog is always shown, even when `BeforeTool` would return `{\"decision\": \"allow\"}` for the tool in question. The only hook received before permission dialog interaction is `Notification`, but this is advisory and does not have decision control. Unless I'm missing something, this makes it impossible to properly automate tool approval using hooks, as the manual user response to the permission dialog is always required.\n\n---\n\nAligning the timing of `BeforeTool` with Claude's `PreToolUse` is my primary feature request, but as a side note Claude also has `PermissionRequest` hook which might be nice-to-have. `PermissionRequest` is invoked after `PreToolUse` if permission is required and not already auto-approved by `PreToolUse`. It has similar decision control to `PreToolUse`, but allows some customization over permission suggestions, etc.\n\nhttps://code.claude.com/docs/en/hooks#permissionrequest-decision-control\n\n\n\n### Why is this needed?\n\nAs described above, current implementation makes auto-approving tool usage with `BeforeTool` impossible, as the permission dialog is shown first and manual user interaction is required to proceed\n\n### Additional context\n\n**Claude hook lifecycle**\n\n<img width=\"600\" height=\"3518\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/8ecf0bc1-1ec3-4c84-877a-d13269a8e3f6\" />",
"number": 18266,
"title": "Align hook behavior for permission requests/decision control with Claude",
"url": "https://github.com/google-gemini/gemini-cli/issues/18266",
"analysis": "Align the behavior of agent hooks with standard industry patterns, allowing hooks to influence and override tool permission decisions.",
"effort_level": "medium",
"reasoning": "This task requires re-sequencing the tool execution pipeline within the Scheduler to trigger hooks before the UI permission prompt. It involves logic tracing across the hook system and the task execution flow, ensuring that hook decisions (allow/deny) correctly bypass or trigger the interactive UI state, which falls under medium-level integration and async control flow.",
"validated": true
},
{
"body": "### What happened?\n\nWhen running in YOLO mode, the model might execute `npx ts-node` but get stuck waiting for human input. It\u2019d be great if Gemini CLI could automatically detect this and skip the wait\u2014no human intervention needed.\n\n<img width=\"1375\" height=\"432\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/7ad8c4e8-792e-4ed7-a1ed-5efbc1a2d2f5\" />\n\n### What did you expect to happen?\n\nIt should pass automatically.\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\n> /about\n\u256d\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256e\n\u2502 \u2502\n\u2502 About Gemini CLI \u2502\n\u2502 \u2502\n\u2502 CLI Version 0.26.0 \u2502\n\u2502 Git Commit a380b4219 \u2502\n\u2502 Model auto-gemini-3 \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS win32 \u2502\n\u2502 Auth Method gemini-api-key \u2502\n\u2502 GCP Project vertex-ai-sprint \u2502\n\u2502 \u2502\n\u2570\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256f\n```\n\n</details>\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 18086,
"title": "npx might block in YOLO mode",
"url": "https://github.com/google-gemini/gemini-cli/issues/18086",
"analysis": "Automatically suppress interactive prompts from `npx` by appending the `--yes` flag when the CLI is running in YOLO mode.",
"effort_level": "small",
"reasoning": "The fix is highly localized to the shell tool implementation. It involves detecting if a command starts with 'npx' and conditionally appending the '--yes' flag based on the existing YOLO mode state. This falls under trivial logic/config adjustments and is expected to be constrained to a single file.",
"recommended_implementation": "In `packages/core/src/tools/shell.ts`, modify the command string before execution if `config.isYoloMode()` is true and the command begins with `npx`.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWe have many commands that are hard to discover, some examples include:\n\n! shell move\nctrl-V to paste in image\netc.\n\n### Why is this needed?\n\nWe should have an easy way to find the common commands and where to find more within the core UI. \n\n### Additional context\n\n_No response_",
"number": 18034,
"title": "Make it easier to discover commonly needed slash and key commands to users",
"url": "https://github.com/google-gemini/gemini-cli/issues/18034",
"analysis": "Improve the discoverability of common slash commands and keyboard shortcuts through UI hints or an enhanced help overlay.",
"effort_level": "small",
"reasoning": "This task involves UI/aesthetic adjustments and content updates within the Ink-based CLI. It primarily requires adding static text hints or updating the existing HelpDialog component to display keyboard shortcuts and slash commands, which is a localized change with minimal logic complexity.",
"recommended_implementation": "In `packages/cli/src/ui/components/AppHeader.tsx`, add a small `<Text>` hint like '(? for help)' and ensure the `/help` command provides a concise table of essential shortcuts.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nWhen editing a multiline prompt, it is natural to use the up arrow to navigate the text, however when the prompt is multiple lines, it means you can quickly jump to a previous prompt while merely navigating.\n\nPossible solutions: \n\n* Double tap: when the cursor is not on the first line of a prompt, keeping the arrow key pressed will only take you to the first line (no matter how long it stays pressed), ie. you need to depress and press again to go up in history.\n* Delay: when the cursor is not on the first line of a prompt, the navigation up history won't happen before 1-2 seconds wait.\n* Use some other ctrl+shortcut for history (assuming here that going through prompt history is corner case, and should be off the well trodden paths)\n\n### Why is this needed?\n\nEditing multi-line prompts is inconvenient: you quickly end up browsing history rather than navigating the prompt lines\n\n### Additional context\n\n_No response_",
"number": 17851,
"title": "Up arrow shouldn't go directly up in history when the prompt has multiple lines",
"url": "https://github.com/google-gemini/gemini-cli/issues/17851",
"analysis": "Update the input prompt logic so that the Up arrow moves the cursor vertically within a multi-line buffer before fetching items from the chat history.",
"effort_level": "medium",
"reasoning": "This task involves modifying the state management and key handling logic within the TextInput component to track cursor position relative to line breaks. Since it involves UI state synchronization and input buffer manipulation in an Ink-based component, it aligns with the Medium effort criteria.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nAdd a `skipMemoryLoad` option to `loadCliConfig()` to skip GEMINI.md file loading when only authentication is needed.\n\nDuring startup, `loadCliConfig()` is called multiple times\n\n1. **Parent process**: `partialConfig` creation (for auth) \u2192 loads GEMINI.md\n2. **Child process**: `partialConfig` creation (for auth) \u2192 loads GEMINI.md again\n3. **Child process**: `config` creation (actual use) \u2192 loads GEMINI.md again\n\n### Why is this needed?\n\nCurrently GEMINI.md files are loaded 3 times during startup (parent partialConfig + child partialConfig + child config), but only 1 load is necessary.\n\nThis wastes I/O and slows down startup, especially for projects with many GEMINI.md files.\nExpected improvement: ~66% reduction in memory loading time.\n\n### Additional context\n\nThis aligns with the existing TODO in gemini.tsx:443-446\n\n> TODO(jacobr): refactor loadCliConfig so there is a minimal version that only initializes enough config to enable refreshAuth or find another way to decouple refreshAuth from requiring a config.\n\nHappy to open a PR if this direction looks good! ",
"number": 17637,
"title": "Skip redundant GEMINI.md loading in partialConfig during startup",
"url": "https://github.com/google-gemini/gemini-cli/issues/17637",
"analysis": "Optimize startup performance by skipping the redundant loading of `GEMINI.md` instruction files during the initial configuration bootstrap pass.",
"effort_level": "small",
"reasoning": "The task involves adding a boolean flag to the `loadCliConfig` function and updating a few call sites to skip I/O-heavy file loading when only authentication is required. This is a localized logic change with a clear implementation path, fitting the criteria for a small effort level.",
"recommended_implementation": "Add a `skipInstructions` boolean to the `LoadConfigOptions` in `packages/core/src/config/config.ts` and use it to conditionally call `instructionHydrator.load()`.",
"validated": true
},
{
"body": "This issue tracks generalizing the UX added in #17266 to prompt users to trust or not trust _all_ repo provided extensibility that is on by default, including:\n\n- Hooks\n- Subagents\n- Skills\n\nI think we could potentially use this to approve passing of environment variables to child processes, including those that could contain secrets.",
"number": 17421,
"title": "Generalize subagents trust UX for extensibility",
"url": "https://github.com/google-gemini/gemini-cli/issues/17421",
"analysis": "Generalize the trust and acknowledgment system for subagents to allow third-party agent extensions to participate in the same security UX.",
"effort_level": "medium",
"reasoning": "Generalizing the trust UX involves refactoring the AcknowledgedAgentsService into a more generic extensibility trust service, updating the underlying JSON storage schema, and modifying the React/Ink UI components (AgentConfigDialog) to handle multiple categories (Hooks, Skills, Subagents). This requires logic tracing across service integration points and state management in the CLI UI, fitting the criteria for Medium effort.",
"validated": true
},
{
"body": "### What happened?\n\n When using the Gemini CLI on Windows,attempting to scroll with the mouse wheel causes the input prompt/area to move up and down. \n\n### What did you expect to happen?\n\nI expect the scroll wheel to scroll the chat history(output section) so I can see previous messages. The output section does not scroll as expected.\n\n### Client information\n\n\n* **CLI Version:** 0.25.1\n* **Git Commit:** 2a8e1a8cc\n* **Session ID:** 7068c667-1077-4747-b248-c7c72f362b19\n* **Operating System:** win32 v22.15.0\n* **Sandbox Environment:** no sandbox\n* **Model Version:** auto-gemini-3\n* **Memory Usage:** 205.4 MB\n* **Terminal Name:** Unknown\n* **Terminal Background:** Unknown\n* **Kitty Keyboard Protocol:** Unsupported\n* **IDE Client:** IDE\n\n\n### Login information\n\n_No response_\n\n### Anything else we need to know?\n\n_No response_",
"number": 17389,
"title": "Windows CLI: Scroll wheel affects input area instead of output history",
"url": "https://github.com/google-gemini/gemini-cli/issues/17389",
"analysis": "Fix a Windows-specific bug where mouse scroll wheel events are incorrectly captured by the input area instead of scrolling the history.",
"effort_level": "medium",
"reasoning": "This is a platform-specific UI state and event handling issue on Windows. It requires tracing how mouse wheel escape sequences are processed within the Ink-based terminal UI and ensuring they are correctly routed to the scrollable history component rather than the input buffer. This falls under the Medium criteria for logic tracing and UI state synchronization across components.",
"validated": true
},
{
"body": "### URL of the page with the issue\n\nhttps://geminicli.com/docs/cli/keyboard-shortcuts/\n\n### What is the problem?\n\nThe only docs about vi mode are in the /vi section of https://geminicli.com/docs/cli/commands/.\n\nhttps://geminicli.com/docs/cli/keyboard-shortcuts/ should have a section for vi mode.\n\n### What did you expect to happen?\n\nDocument which vi keybindings are supported.\n\n### Additional context\n\n_No response_",
"number": 17381,
"title": "vi mode not documented",
"url": "https://github.com/google-gemini/gemini-cli/issues/17381",
"analysis": "Add comprehensive documentation for the CLI's 'vi mode', including supported keybindings and configuration options.",
"effort_level": "small",
"reasoning": "This is a documentation-only task involving content updates to the keyboard shortcuts page. It does not require any code changes or logic modifications, fitting the criteria for a small effort level.",
"recommended_implementation": "Create a new `docs/vi-mode.md` file and link to it from the main `README.md`. Document shortcuts like `i`, `Esc`, `k`, `j` and the `/vi` command.",
"validated": true
},
{
"body": "## Summary\n\nAdd support for configurable key sequences to escape from insert mode in vim mode, similar to VS Code Vim and native Vim configurations.\n\n## Motivation\n\nMany vim users remap `jj` or `jk` to escape insert mode since the Escape key is far from the home row. This is one of the most common vim customizations:\n\n- Native Vim: `inoremap jj <Esc>`\n- VS Code Vim: `vim.insertModeKeyBindings` with `[\"j\", \"j\"]` \u2192 `<Esc>`\n- Neovim: plugins like [better-escape.nvim](https://github.com/max397574/better-escape.nvim)\n\nCurrently, Gemini CLI's vim mode only supports the physical Escape key.\n\n## Proposed Solution\n\nAdd a `vimKeyBindings` setting in `settings.json`:\n\n```json\n{\n \"general\": {\n \"vimMode\": true,\n \"vimKeyBindings\": {\n \"insertMode\": [\n {\n \"keys\": [\"j\", \"j\"],\n \"action\": \"escape\",\n \"timeout\": 200\n }\n ]\n }\n }\n}\n```\n\n### Design\n\n| Aspect | Recommendation | Rationale |\n|--------|---------------|-----------|\n| **Mode-specific** | Per-mode arrays (`insertMode`, `normalMode`) | Follows VS Code Vim pattern |\n| **Timeout** | Per-mapping with default fallback (200ms) | Balance between responsiveness and avoiding misfires |\n| **Key format** | Array of strings `[\"j\", \"j\"]` | Matches VS Code Vim's `before` syntax |\n| **Actions** | Start with `escape` only, extensible later | Keep initial scope minimal |\n\n### Implementation Approach\n\n1. Track key sequence history with timestamps in insert mode\n2. On each keypress, check if recent keys match any configured sequence within timeout\n3. If match found, delete inserted characters and execute the action (e.g., escape to normal mode)\n\n## Alternatives Considered\n\n- **Hardcoded `jj` only**: Simpler but not flexible for users who prefer `jk` or other sequences\n- **Global timeout setting**: Vim uses `timeoutlen`, but per-mapping timeout is more flexible\n\n## Additional Context\n\n- Related: #15768 (custom keyboard shortcuts - general keybindings)\n- References: [VS Code Vim](https://github.com/VSCodeVim/Vim), [vim-easyescape](https://github.com/zhou13/vim-easyescape), [better-escape.nvim](https://github.com/max397574/better-escape.nvim)\n\nI have a working prototype for hardcoded `jj` escape and am happy to extend it to this configurable approach if there's interest.",
"number": 17361,
"title": "feat(cli): Add configurable escape key sequences for vim mode",
"url": "https://github.com/google-gemini/gemini-cli/issues/17361",
"analysis": "Support configurable escape key sequences (e.g., 'jj' or 'jk') to exit 'vi mode' Insert state, similar to standard Vim configurations.",
"effort_level": "medium",
"reasoning": "Implementing configurable escape sequences requires modifying the useVim hook to include a keypress buffer and a timeout mechanism. This involves complex state management to determine whether to intercept characters or flush them to the text buffer, which requires careful synchronization of React state and asynchronous timing logic.",
"validated": true
},
{
"body": "Currently, the policy engine allows filtering rules based on `modes` (e.g., `yolo`, `autoEdit`, `plan`). We should extend this capability to support filtering based on the runtime environment (e.g., `local` vs. `sandboxed`).\n\nThis would allow users and admins to define policies that are only active when the CLI is running in a sandbox. For example, we might want to allow potentially dangerous tools like `rm` or `git push` when sandboxed, but require user confirmation or deny them entirely when running locally.\n\n### Proposed Changes\n\n1. **Define Types**: Introduce a `RuntimeEnvironment` enum in `packages/core/src/policy/types.ts` with values `local` and `sandboxed`.\n2. **Update Rule Schema**: Add an optional `environments` field (array of `RuntimeEnvironment`) to `PolicyRule` and `SafetyCheckerRule` interfaces.\n3. **TOML Loading**: Update `packages/core/src/policy/toml-loader.ts` to support the `environments` field in TOML files using Zod validation.\n4. **Engine Logic**: Update `ruleMatches` in `packages/core/src/policy/policy-engine.ts` to check both the current `approvalMode` and the current `runtimeEnvironment`.\n5. **Configuration**: Update `createPolicyEngineConfig` in `packages/core/src/policy/config.ts` to accept the current environment.\n6. **CLI Integration**: Update the CLI to detect the current environment (via `process.env['SANDBOX']`) and pass it down to the policy engine.\n\n### Example TOML\n\n```toml\n[[rule]]\ntoolName = \"run_shell_command\"\ncommandPrefix = \"rm\"\ndecision = \"allow\"\npriority = 100\nenvironments = [\"sandboxed\"]\n\n[[rule]]\ntoolName = \"run_shell_command\"\ncommandPrefix = \"rm\"\ndecision = \"ask_user\"\npriority = 50\nenvironments = [\"local\"]\n```",
"number": 17034,
"title": "Improvement: Policy Engine - Support filtering by Runtime Environment (Sandboxed vs. Local)",
"url": "https://github.com/google-gemini/gemini-cli/issues/17034",
"analysis": "Extend the policy engine to allow filtering rules based on the runtime environment (e.g., 'local' vs. 'sandboxed').",
"effort_level": "medium",
"reasoning": "This task requires modifications across multiple files including type definitions, Zod schema validation in the TOML loader, and the core matching logic in the policy engine. It involves logic tracing to ensure the runtime environment state is correctly propagated and validated against the new policy rules, fitting the criteria for medium effort involving parsers and logic synchronization.",
"validated": true
},
{
"body": "Several new tips and hints are being added for features like fuzzy search, Gemini 3 preview, thinking budget, MCP resources, Introspection Agent, JIT context, and new shortcuts. Before surfacing these to users, we should validate through real usage that each hinted feature is stable, usable, and ready for wider adoption.",
"number": 16718,
"title": "update tips array with recent features and commands [Phrase Cycler]",
"url": "https://github.com/google-gemini/gemini-cli/issues/16718",
"analysis": "Update the rotating 'tips' array with recent features like fuzzy search, thinking budget, and new keyboard shortcuts.",
"effort_level": "small",
"reasoning": "Updating a static array of strings for UI tips is a localized content update that requires no logic changes or complex state management, fitting the criteria for a small effort task.",
"recommended_implementation": "Locate `packages/cli/src/ui/constants/tips.ts` and add the new feature descriptions to the `TIPS` array.",
"validated": true
},
{
"body": "# [Refactor] Decouple Tool-Specific Cancellation Logic from SchedulerStateManager\n\n## Problem\nCurrently, `SchedulerStateManager.toCancelled` contains hardcoded logic specifically for `edit` tool calls to preserve file diffs when a user cancels:\n\n```typescript\n// packages/core/src/scheduler/state-manager.ts\n\nif (this.isWaitingToolCall(call)) {\n const details = call.confirmationDetails;\n if (details.type === 'edit' && ...) {\n resultDisplay = { ... }; // Hardcoded diff preservation\n }\n}\n```\n\nThis leaks tool-specific implementation details into the generic state management layer and makes it harder to support cancellation logic for new tool types in the future.\n\n## Proposed Solution\nMove the responsibility of defining the \"cancellation state\" to the tool itself by adding an optional `cancelResult` field to the confirmation details.\n\n1. **Update `SerializableConfirmationDetails`**:\n Add an optional `cancelResult: ToolResultDisplay` to the serializable types in `packages/core/src/confirmation-bus/types.ts`.\n\n2. **Refactor `SchedulerStateManager`**:\n Simplify `toCancelled` to simply check for the presence of `cancelResult` on the confirmation details:\n\n ```typescript\n if (this.isWaitingToolCall(call) && call.confirmationDetails.cancelResult) {\n resultDisplay = call.confirmationDetails.cancelResult;\n }\n ```\n\n3. **Update Tools**:\n Ensure tools (like the Edit tool) populate the `cancelResult` when generating confirmation details.\n\n## Benefits\n- **Clean Abstractions**: The `StateManager` remains tool-agnostic.\n- **Extensibility**: New tools can define their own \"cancelled\" UI without modifying core scheduler code.\n- **Maintainability**: Tool logic stays within the tool definitions.\n",
"number": 16716,
"title": "[Refactor] Decouple Tool-Specific Cancellation Logic from SchedulerStateManager",
"url": "https://github.com/google-gemini/gemini-cli/issues/16716",
"analysis": "Refactor the `SchedulerStateManager` to decouple tool-specific cancellation logic, allowing tools to define their own 'cancelled' display state.",
"effort_level": "medium",
"reasoning": "This refactor requires changes across multiple layers of the codebase, including core type definitions in the confirmation-bus, the state transition logic in SchedulerStateManager, and specific tool implementations. It involves decoupling tool-specific logic into a generic interface, which requires careful validation to ensure that UI-side features (like diff preservation for the 'edit' tool) are not broken during the transition.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like to propose a feature that allows the CLI to auto-populate or pre-fill text into the user's input prompt.\n\nCurrently, the system operates in a strict \"respond-only\" mode. The proposed feature would enable the tool to suggest a response or a command and place it directly into the terminal's input buffer, allowing the user to either review, edit, or simply press \"Enter\" to execute it.\n\n### Why is this needed?\n\nThis is needed to improve the fluidity of the CLI workflow. Unlike some advanced interactive CLI tools that can manipulate the terminal interface, the current Gemini CLI cannot \"hand off\" a draft message to the user.\n\nWithout this capability, users have to manually copy-paste suggestions or re-type commands, which creates friction. Enabling input pre-filling would allow for a more collaborative experience where the AI can provide a \"starting point\" in the prompt area, making the interaction much faster and more intuitive.\n\n### Additional context\n\n<img width=\"371\" height=\"46\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/c8ff3c9f-b2f5-4140-acf2-dd4b83622b3a\" />",
"number": 16606,
"title": "Supporting Input Buffer Manipulation in CLI",
"url": "https://github.com/google-gemini/gemini-cli/issues/16606",
"analysis": "Implement support for input buffer manipulation, allowing the agent to suggest a response and place it directly into the user's terminal input area for review or editing.",
"effort_level": "medium",
"reasoning": "Implementing input buffer manipulation requires modifying the React state machine within the AppContainer to support a new 'Drafting' state. It involves synchronizing tool execution results with the TextInput component's internal buffer, which aligns with the Medium criteria for React/Ink state management and UI state synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI'm throwing a wish coin here. I wish Gemini CLI has an intuitive terminal UI/UX experience just like OpenCode. The OpenCode CLI application runs in terminal too, but it was never bugged out on me. And the utilization of sidebar for displaying todos are world's wonder. The code diff that split terminal in half (left/right) view is much cleaner to see what was changed.\n\nOpenCode is basically a terminal that doesn't feel like a terminal.\n\n<img width=\"1916\" height=\"1199\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/6296fee5-2315-4bde-a6c5-3e5008916f83\" />\n\n### Why is this needed?\n\nImproved UI/UX experience. Not directly clone of Claude Code terminal style.\n\n### Additional context\n\n_No response_",
"number": 16509,
"title": "OpenCode style terminal",
"url": "https://github.com/google-gemini/gemini-cli/issues/16509",
"analysis": "Re-architect the CLI layout to support a sidebar-based task view and a persistent side-by-side diff view, similar to the OpenCode UI.",
"effort_level": "large",
"reasoning": "Implementing a multi-pane UI with a persistent sidebar and side-by-side diff view requires a fundamental re-architecture of the existing Ink-based layout system. This involves complex state management for focus across multiple panes, handling terminal resizing for split-screen views, and creating new high-level layout components, which falls under the category of a major subsystem redesign.",
"validated": true
},
{
"body": "This allows us to manage the prompts separately from the workflows\n\nIt also allows us to reuse the same prompt in multiple workflows e.g. automated triage and scheduled triage\n\nHere's an example: https://github.com/google-github-actions/run-gemini-cli/blob/main/.github/commands/gemini-triage.toml",
"number": 16419,
"title": "Automation: move prompts from workflows into custom commands",
"url": "https://github.com/google-gemini/gemini-cli/issues/16419",
"analysis": "Automate the creation of custom slash commands by allowing them to be defined as prompt templates in TOML files.",
"effort_level": "medium",
"reasoning": "Implementing a custom command loader requires developing a new TOML parser and validation logic (likely using Zod) to map external files to the internal SlashCommand interface. This involves logic tracing across the core and CLI packages, handling filesystem resolution, and ensuring the dynamic commands integrate correctly with the existing command router and prompt construction logic.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like `gemini-cli` to support standard Emacs/Readline keybindings with specific \"smart\" multiline behaviors found in `zsh`.\n\nCurrently, navigation feels limited compared to standard Unix shells. I propose adding/refining the following mappings:\n\n**1. Character & Word Navigation**\n* `Ctrl+F`: Move forward one character.\n* `Ctrl+B`: Move backward one character.\n* `Alt+F`: Move forward one **word**.\n* `Alt+B`: Move backward one **word**.\n\n**2. Line & Buffer Navigation (Smart Handling)**\n* `Ctrl+A`: Go to **beginning of line**. (If already at start of line in a multiline buffer, go to start of previous line).\n* `Ctrl+E`: Go to **end of line**. (If already at end of line in a multiline buffer, go to end of next line).\n* `Alt+<`: Go to beginning of the entire buffer/history.\n* `Alt+>`: Go to end of the entire buffer/history.\n\n**3. History vs. Vertical Movement (The \"Zsh\" Behavior)**\n* `Ctrl+P`: Move cursor **up one line** (visual movement). If the cursor is already at the top of the buffer, fetch the **previous command** from history.\n* `Ctrl+N`: Move cursor **down one line** (visual movement). If the cursor is already at the bottom of the buffer, fetch the **next command** from history.\n* `Alt+P`: Explicitly fetch previous command from history (regardless of cursor position).\n* `Alt+N`: Explicitly fetch next command from history (regardless of cursor position).\n\n**4. Editing & Paging**\n* `Ctrl+K`: Kill (cut) text from cursor to end of line.\n* `Ctrl+Y`: Yank (paste) the most recently killed text.\n* `Ctrl+_` (or `Ctrl+x` `u`): Undo.\n* `Ctrl+Alt+_`: Redo.\n* `Ctrl+V`: Scroll Page Up (Note: Standard Emacs uses this for Page Down, but consistent paging shortcuts are the goal).\n* `Alt+V`: Scroll Page Down.\n\n\n\n### Why is this needed?\n\n**1. Muscle Memory & Ergonomics:**\nFor users coming from macOS, Linux, or generic Unix environments, these keybindings are muscle memory. Reaching for the arrow keys or Home/End keys requires moving hands away from the home row, which breaks flow and slows down input significantly.\n\n**2. Multiline Editing Efficiency:**\n`gemini-cli` often involves editing large blocks of text (prompts, code blocks). The requested `zsh`-style behavior for `Ctrl+N/P` is critical here. Without it, traversing a 10-line prompt to fix a typo in the middle, and then jumping back to history, is cumbersome.\n\n**3. Standard Compliance:**\nVirtually every CLI tool (Bash, Zsh, Fish, Python REPL, Node REPL) supports these bindings via GNU Readline or similar libraries. Supporting them would make `gemini-cli` feel like a native, integrated part of the user's terminal workflow rather than a tool with non-standard controls.\n\nI'd highly recommend everyone testing these out in e.g. `zsh`!\n\n### Additional context\n\n**Reference:**\nThese bindings largely correspond to the [GNU Readline Emacs Mode](https://readline.kablamo.org/emacs.html), extended by ZLE (Zsh Line Editor) logic for multiline buffers.\n\nI wrote this feature with help from `gemini-cli` itself.\n\n```\n\u256d\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u256e\n\u2502 \u2502\n\u2502 About Gemini CLI \u2502\n\u2502 \u2502\n\u2502 CLI Version 0.23.0 \u2502\n\u2502 Git Commit 3ff055840 \u2502\n\u2502 Model auto-gemini-3 \u2502\n\u2502 Sandbox no sandbox \u2502\n\u2502 OS darwin \u2502\n\u2502 Auth Method OAuth \u2502\n\u2502 User Email A.B@C.com \u2502\n\u2502 \u2502\n\u2570\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u
"number": 16357,
"title": "[Feature Request] Advanced GNU Readline- / Zsh- / Emacs-style Keybindings and Multiline Navigation",
"url": "https://github.com/google-gemini/gemini-cli/issues/16357",
"analysis": "Implement advanced Emacs/Readline-style keybindings (e.g., Ctrl+K, Ctrl+Y, Alt+F, Alt+B) for the TUI input prompt.",
"effort_level": "medium",
"reasoning": "Implementing advanced Readline/Emacs keybindings requires significant logic enhancements to the TextInput component's state management. It involves calculating cursor offsets for word-based navigation, handling multiline buffer logic for 'smart' line jumps, and managing a kill-ring state. This falls under the Medium criteria for React/Ink state management and UI synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nA button to copy text similar to the Gemini app and AI Studio\n\n### Why is this needed?\n\nI have an MCP server that does summarization of youtube videos. Would love to use my Gemini CLI extension and have it summary text then hit a button to copy it.\n\n### Additional context\n\nHaven't tried my MCP server in other places. If this is out of scope please let me know if a good MCP server UI where I get a copy text button",
"number": 16341,
"title": "Copy text button",
"url": "https://github.com/google-gemini/gemini-cli/issues/16341",
"analysis": "Add a 'Copy text' button or hotkey to code blocks and agent responses in the chat history.",
"effort_level": "medium",
"reasoning": "Implementing a copy-to-clipboard feature in a terminal UI (Ink) requires more than a simple UI tweak. It involves managing focus states to determine which message or code block is active, integrating a cross-platform clipboard library, and handling the stripping of ANSI escape sequences from the text before copying. This aligns with the Medium criteria for state management and service integration.",
"recommended_implementation": "In `GeminiMessageContent.tsx`, add a focus-aware key handler (e.g., for the 'c' key) that calls `clipboardy.writeSync()` with the content of the currently focused code block.",
"validated": true
},
{
"body": "Today, we simply print that the operation was successful. We should consider adding more information, to help the user understand the state of things, for example how many agents were loaded or updated. At the very least, we should consider change the message to indicate that the user should run `/agents list` to see the currently loaded agents.",
"number": 16272,
"title": "Improving logging on agents refresh",
"url": "https://github.com/google-gemini/gemini-cli/issues/16272",
"analysis": "Improve the logging and success messaging for the `/agents reload` command to provide more context on what was updated.",
"effort_level": "small",
"reasoning": "This task involves modifying the success message of a specific CLI command. It is a localized change within the command handler to include dynamic data (like the count of agents) or additional instructional text, fitting the criteria for string/content updates and trivial logic adjustments.",
"recommended_implementation": "Update `agentsReloadCommand.action` in `agentsCommand.ts` to return a message containing the number of agents successfully re-hydrated from the registry.",
"validated": true
},
{
"body": "### What happened?\n\nUsers of gemini-cli would naturally expect it to mimic Bash vim mode. \n\nThe matter comes to light in issue: https://github.com/google-gemini/gemini-cli/issues/15530 and fix PR: https://github.com/google-gemini/gemini-cli/pull/15575\n\nIt seems that the gemin-cli implementation is a home-brew solution which no one is familiar with, e.g., ``k, j, dd, etc.`` are not supported and they are what a user of Bash vim mode would expect.\n\nNo one expects Bash vim mode to emulate Bash editor - No one would expect gemini-cli vim mode to emulate Vim editor either. I think they would expect gemini-cli vim mode to emulate Bash's command line vim mode instead.\n\n1. PR: https://github.com/google-gemini/gemini-cli/pull/15575 is one step in that direction: it should be accepted\n2. The entire gemini-cli vim mode implementation should align with Bash vim mode as closely as is practical\n\n### What did you expect to happen?\n\nThe gemini-cli vim mode should mimic Bash vim mode.\n\n### Client information\n\n<details>\n<summary>Client Information</summary>\n\nRun `gemini` to enter the interactive CLI, then run the `/about` command.\n\n```console\nAbout Gemini CLI \u2502 \u2584\n\u2502 \u2502 \u2588\n\u2502 CLI Version 0.22.4 \u2502 \u2588\n\u2502 Git Commit e00bcf520 \u2502 \u2588\n\u2502 Model auto-gemini-3 \u2502 \u2588\n\u2502 Sandbox no sandbox \u2502 \u2588\n\u2502 OS linux \u2502 \u2588\n\u2502 Auth Method OAuth \n```\n\n</details>\n\n### Login information\n\nGoogle Account\n\n### Anything else we need to know?\n\n\n@galz10\n@314clay\n\nThis is the reason given for rejecting https://github.com/google-gemini/gemini-cli/pull/15575 : \n\n\n```\nSince standard Vim always defaults to Normal mode (even when opening a brand new file), we want to\nstick to that behavior to match the muscle memory users expect. We try not to deviate from \nhow Vim works unless absolutely necessary.\n```\n\nThis misses the mark: Vim mode is not a Vim Editor, it is merely an input mode for command line interaction that leverages select vim editing features that are indeed part of muscle memory of regular Vim users.\n\nThe distinction is crucial.\n\nThe impetus for vim mode should be to mimic Bash's implementation of vim mode. Bash vim mode starts in Insert mode for the very reason this fix resolves: More often than not, users will want to type a bash command rather than navigate.\n\nUsers of bash vim mode do not \"expect\" that the mode will mimic Vim, but instead expect it to mimic Bash vim mode: Starting in vim 'Insert' mode is NOT consistent with their Bash vim mode muscle memory.\n\nBash vim mode when in Normal mode enables history navigation, e.g., k, j, which gemini-cli vim mode does not support. It also supports 'dd' for quick erasure. For sure, bash vim mode does not seek to emulate Vim editor and that is clearly stated within the Bash docs.\n\nThis fix partially aligns gemini-cli vim mode with Bash vim mode which I assert is what users of this feature would expect.\n\nIn summary, perhaps the greater issue is to revisit the motivation for gemini-cli vim mode to determine whether it's goal is to emulate Vim editor (No one expects that) or to emulate Bash vim mode.\n```\n",
"number": 15618,
"title": "Vim mode should align with Bash vim mode, NOT Vim editor",
"url": "https://github.com/google-gemini/gemini-cli/issues/15618",
"analysis": "Align the CLI's 'vi mode' implementation with standard Bash/Readline vi-mode behavior, including starting in Insert mode and supporting history navigation.",
"effort_level": "medium",
"reasoning": "Aligning the Vim mode with Bash/Readline behavior requires refactoring the state machine in vim.ts to handle history navigation (k/j) and standard shell-like key mappings. This involves state synchronization between the Vim hook and the CLI's history state, as well as logic tracing for multi-key operators like 'dd'. It fits the Medium criteria for React/Ink state management and UI state synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\n On Windows, the CLI currently defaults to powershell.exe (v5.1) for run_shell_command. This creates a bottleneck\n because:\n 1. Encoding Issues: Native PowerShell defaults to GBK (936), causing encoding mismatches/mojibake when modern tools\n (like eza, lsd, or git) output UTF-8.\n 2. Limited Modern Features: Many users have migrated to pwsh (v7+) or NuShell for better performance and\n cross-platform compatibility.\n 3. Environment Isolation: Users often have their dev environment set up in pwsh, but the CLI executes commands in a\n different, unconfigured environment.\n Desired outcome: Add a setting (e.g., tools.shell.executablePath) to allow users to specify their preferred shell\n executable.\n\n### Why is this needed?\n\nUnlocks Modern Windows Tooling & Fixes Encoding by Design\n1. UTF-8 First: The legacy powershell.exe defaults to legacy encodings (GBK/CP936), causing mojibake with almost\n all modern CLI tools (Rust-based tools like eza, ripgrep, or even Node/Python scripts). Configuring the shell to pwsh\n (which handles UTF-8 correctly by default) fixes this natively without hacky $PROFILE modifications.\n2. User Preference & Consistency: Developers invest time configuring their shell (pwsh, nu, bash) with specific\n aliases, environment variables, and tools. Forcing execution in a raw powershell.exe environment breaks this\n consistency and limits the CLI's potential integration with the user's workflow.\n\n### Additional context\n\n \ud83d\udccb \u539f\u59cb\u6d4b\u8bd5\u65e5\u5fd7 (Raw Test Logs)\n\n >>> TEST 1: PowerShell 7 (pwsh) [Profile Enabled] <<<\n Active code page: 65001\n .\n \u9239\u6ebe\u6522\u9239\u20ac \u9359\u509d\u20ac\u51ad\u796b\u93c2\n \u9239\u6ebe\u6522\u9239\u20ac \u7039\u70b0\u7bc4\u93c2\u56e8\u3002\n \u9239\u6ebe\u6522\u9239\u20ac \u5bb8\u30e7\u25bc\u93c2\u56e6\u6b22\n \u9239\u65ba\u6522\u9239\u20ac \u675e\ue219\u6b22\u5bb8\u30e5\u53ff\n\n >>> TEST 2: Windows PowerShell (powershell) [Profile Enabled] <<<\n Active code page: 65001\n .\n \u9239\u6ebe\u6522\u9239\u20ac \u9359\u509d\u20ac\u51ad\u796b\u93c2\n \u9239\u6ebe\u6522\u9239\u20ac \u7039\u70b0\u7bc4\u93c2\u56e8\u3002\n \u9239\u6ebe\u6522\u9239\u20ac \u5bb8\u30e7\u25bc\u93c2\u56e6\u6b22\n \u9239\u65ba\u6522\u9239\u20ac \u675e\ue219\u6b22\u5bb8\u30e5\u53ff\n\n >>> TEST 3: NuShell (nu) <<<\n .\n \u9239\u6ebe\u6522\u9239\u20ac \u9359\u509d\u20ac\u51ad\u796b\u93c2\n \u9239\u6ebe\u6522\u9239\u20ac \u7039\u70b0\u7bc4\u93c2\u56e8\u3002\n \u9239\u6ebe\u6522\u9239\u20ac \u5bb8\u30e7\u25bc\u93c2\u56e6\u6b22\n \u9239\u65ba\u6522\u9239\u20ac \u675e\ue219\u6b22\u5bb8\u30e5\u53ff\n\n >>> TEST 4: CMD (cmd) <<<\n Active code page: 65001\n .\n \u9239\u6ebe\u6522\u9239\u20ac \u9359\u509d\u20ac\u51ad\u796b\u93c2\n \u9239\u6ebe\u6522\u9239\u20ac \u7039\u70b0\u7bc4\u93c2\u56e8\u3002\n \u9239\u6ebe\u6522\u9239\u20ac \u5bb8\u30e7\u25bc\u93c2\u56e6\u6b22\n \u9239\u65ba\u6522\u9239\u20ac \u675e\ue219\u6b22\u5bb8\u30e5\u53ff\n---\n Technical Observations:\n \n 1. Brittle Encoding Management: As shown in the logs, even after manually forcing the code page to 65001 (UTF-8) via\n $PROFILE modifications, modern tools like eza still produce mojibake (broken characters) when piped through the\n hardcoded powershell.exe session used by the CLI agent. This demonstrates that simply \"patching\" the legacy shell is\n not a robust solution.\n\n 2. Shell Inconsistency: While NuShell (Test 3) handles these characters natively and correctly, it must be manually\n invoked as a sub-process of powershell.exe, leading to unnecessary overhead and potential environment variable loss.\n \n 3. The Hidden Bottleneck: The native powershell.exe (v5.1) is an outdated execution host for AI agents. By\n hardcoding it, the CLI prevents users from leveraging the native UTF-8 handling and modern features of pwsh or nu,\n which are standard in modern Windows development workflows.\n \n Conclusion: Allowing a configurable shell path would allow the CLI to u
"number": 15493,
"title": "\"Feature Request: Allow configuring the default shell execution environment (e.g., pwsh, bash, nu) instead of hardcoded powershell.exe on Windows.\"",
"url": "https://github.com/google-gemini/gemini-cli/issues/15493",
"analysis": "Allow users to configure the default shell executable (e.g., pwsh, bash, nu) used by the `run_shell_command` tool, particularly on Windows where it defaults to legacy PowerShell.",
"effort_level": "medium",
"reasoning": "Implementing this requires modifying the configuration schema (Zod) and propagating the new setting to the ShellExecutionService. Beyond just replacing the executable path, the implementation must handle shell-specific invocation arguments (e.g., 'bash -c' vs 'powershell -Command') and ensure that existing command-wrapping logic (like PID capturing) remains compatible with the user-selected shell. This involves logic tracing and integration across the configuration and service layers.",
"recommended_implementation": "Add `tools.shell.executablePath` to `settingsSchema.ts`. Update the `ShellTool` in `shell.ts` to use `config.getSetting('tools.shell.executablePath')` when spawning the child process.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nAudio notifiction whenever CLI posts a reply.\n\n### Why is this needed?\n\nWhen for example I'm using Gemini CLI to make a browser extension it will often take at least 5 minutes before replying while it's working out the problem. I don't want to sit there watching the window waiting for it to reply. I'd rather just browse the internet and when it's replied CLI can play an audio notificaton sound so I know when it's finished. \n\nI've searched for audio notification methods and extensions but none of them worked. If there's a way to have an audio notification already then please let me know. If not, then please add this feature.\n\n### Additional context\n\n_No response_",
"number": 14643,
"title": "Please add ability to have an Audio Notification whenever the chat replies",
"url": "https://github.com/google-gemini/gemini-cli/issues/14643",
"analysis": "Implement an optional audio notification (system bell or sound file) that triggers whenever the agent completes a response turn.",
"effort_level": "small",
"reasoning": "This is a localized enhancement to the TUI. The turn lifecycle is already managed within the AppContainer, and triggering a terminal bell or a simple audio utility call upon state transition from 'streaming' to 'idle' is a trivial logic addition that fits the criteria for a small effort task.",
"recommended_implementation": "In `packages/cli/src/ui/AppContainer.tsx`, add a `useEffect` that monitors the `turnStatus`. When the state transitions from 'active' to 'idle' and a new response is present, execute `process.stdout.write('\\x07')`.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nhow to attach image in vscode gemini code assist? This feature is basic in all other applications like Cursor, GPT, Claude extension in vscode. But I found no way to attach image conveniently in vscode gemini code assist extension. how could such important feature be ignored?\n\n### Why is this needed?\n\nallowing attach image function\n\n### Additional context\n\n_No response_",
"number": 13860,
"title": "how to attach image in vscode gemini code assist?",
"url": "https://github.com/google-gemini/gemini-cli/issues/13860",
"analysis": "Enable image attachment support within the VSCode integrated terminal for the Gemini Code Assist extension.",
"effort_level": "large",
"reasoning": "Implementing image attachment support requires significant architectural and protocol changes to the Model Context Protocol (MCP) and Agent-to-Agent (A2A) server to handle binary data or file references. It involves building a custom bridge between the VSCode Extension API and the CLI backend, as well as updating the Gemini API integration to support multimodal inputs, which constitutes a major subsystem enhancement.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nHello! I recently moved to gemini CLI from claude code because I like gemini 3 pro and I am in dire need of 1M token context length availability. There is a feature in claude code that I am so used to that I would like to see get implemented in gemini cli. Claude code has a /context command that allows me to exactly look into the amount of tokens that are loaded into my context window and let me see which components consume how many tokens to know whether I need to auto compact my conversation or shrink my CLAUDE.md file. Look at the image included for context.\n\n<img width=\"1030\" height=\"1276\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/d7c000f6-3cb4-4695-8239-e774e147c1b4\" />\n\n### Why is this needed?\n\nHelps a lot with context management.\n\n### Additional context\n\n_No response_",
"number": 13400,
"title": "Request for a /context command.",
"url": "https://github.com/google-gemini/gemini-cli/issues/13400",
"analysis": "Implement a `/context` slash command that displays a detailed breakdown of the current token usage and context window consumption.",
"effort_level": "medium",
"reasoning": "Implementing a /context command requires integrating with the existing token counting logic, aggregating data from the current conversation state (history, attachments, system instructions), and building a new Ink-based UI component to display the breakdown. This involves state management and service integration across the CLI's command handling and display layers, fitting the criteria for logic tracing and UI state synchronization.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI'd like to propose a new command, such as \\gemini-cli usage --daily`, that displays the cumulative usage statistics for the current day, not just for a single executed command.`\n\nThis command should fetch and present the total API usage from the start of the day until the current time, including:\n\nTotal tokens used per model (e.g., input and output tokens for gemini-pro, gemini-1.5-pro, etc.)\n\nThe total number of requests made in the last 24 hours.\n\nInformation on the remaining daily quota, if applicable.\n\nThis would be a significant enhancement over the existing per-command usage info, providing users with a comprehensive overview of their daily consumption.\n\n### Why is this needed?\n\nWhile per-command usage is helpful, it doesn't give a complete picture of a user's overall consumption throughout the day.\n\nDevelopers need to monitor their **cumulative daily usage** to avoid hitting rate limits or exceeding budget quotas. Having to manually track each command's usage is impractical and inefficient.\n\nA daily usage command would provide an immediate and convenient way for users to manage their consumption proactively, ensuring their applications run smoothly without unexpected interruptions due to API limits.\n\n### Additional context\n\n_No response_",
"number": 8474,
"title": "Feature Request: Add a command to view daily cumulative usage statistics",
"url": "https://github.com/google-gemini/gemini-cli/issues/8474",
"analysis": "Add a command to view daily cumulative API usage statistics, including total tokens used across all sessions in the last 24 hours.",
"effort_level": "medium",
"reasoning": "Implementing daily usage statistics requires introducing a persistent storage mechanism (e.g., a local JSON-based telemetry log) to track data across multiple CLI sessions. This involves modifying the core API response handling to log usage data and creating a new command to aggregate and display these stats, which falls under the 'Service Integration' and 'Asynchronous Flow' criteria for Medium effort.",
"validated": true
},
{
"body": "### The Problem\n\nWhen running `gemini-cli` from within a project that has its own `.env` file (e.g., a Python project using `python-dotenv`), the CLI attempts to load that project's `.env` file. This can cause authentication failures if the project's `.env` file does not contain the `GEMINI_API_KEY` or other necessary environment variables for the Gemini CLI.\n\nThis behavior forces users to either:\n\n1. Add their Gemini API key to every project's `.env` file, which is not ideal for security or convenience.\n2. Temporarily rename or move the project's `.env` file, which is disruptive to the project's workflow.\n\n### Proposed Solution\n\nProvide a mechanism to force the Gemini CLI to ignore the local project's `.env` file and instead use the global `~/.gemini/.env` file.\n\nThis could be implemented as:\n\n* **A command-line flag:**\n ```bash\n gemini --use-global-env\n ```\n* **A setting in `~/.gemini/settings.json`:**\n ```json\n {\n \"ignoreLocalEnv\": true\n }\n ```\n\n### Why is this needed?\n\nThis feature would improve the user experience by:\n\n* **Preventing conflicts:** It would prevent conflicts between the Gemini CLI's environment variables and the project's environment variables.\n* **Improving security:** It would avoid the need to store the Gemini API key in multiple project-specific `.env` files.\n* **Increasing convenience:** It would allow users to run the Gemini CLI from any project without having to worry about `.env` file conflicts.",
"number": 2493,
"title": "Isolate Gemini CLI from Project-Specific .env Files",
"url": "https://github.com/google-gemini/gemini-cli/issues/2493",
"analysis": "Provide a mechanism to isolate the Gemini CLI from project-specific `.env` files, preventing credential conflicts with the user's local projects.",
"effort_level": "small",
"reasoning": "The task involves adding a configuration flag and a CLI argument to bypass local environment loading. This is a localized logic change within the settings management and CLI entry point, fitting the criteria for trivial logic/config updates and straightforward CLI flag additions.",
"recommended_implementation": "Add an `ignoreLocalEnv` setting to `settingsSchema.ts`. In `loadEnvironment` (settings.ts), check this setting and skip the `findEnvFile(process.cwd())` step if it is true.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nSpecific tools for diagnostics, code actions, LSP format, code completion, all LSP features.\n\n### Why is this needed?\n\n[LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/) support would improve the Gemini CLI experience by making it more efficiently code in the user's project. These specific features more would have the most impact:\n- Diagnostics: could help the LLM to fix bugs faster, while using less requests and less context.\n- Code completion: having access to a project's types without needing to SearchText is a huge efficiency boost.\n\nI myself had trouble yesterday with the model trying to use variables/object properties in TypeScript that don't exist.\n\n### Additional context\n\n_No response_",
"number": 2465,
"title": "Language Server Protocol support for the Gemini CLI",
"url": "https://github.com/google-gemini/gemini-cli/issues/2465",
"analysis": "Implement support for the Language Server Protocol (LSP) to provide the agent with deep code intelligence, including diagnostics and auto-completion.",
"effort_level": "large",
"reasoning": "Implementing LSP support is a major architectural expansion that requires building a client-side implementation of the Language Server Protocol, managing the lifecycle of external server processes via child process management, and integrating these capabilities into the agent's toolset. This involves complex asynchronous flows, protocol-level changes, and significant new subsystem development, fitting the criteria for a Large effort level.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nTelling me the number of tokens I've used is not helpful without the conversion to cost. Please don't force us to estimate costs in our own head. Not only is it frustrating, but it _feels_ deceptive, like you're trying to hide how expensive Gemini is to interact with. I know this isn't the intent, but it's the perception people will likely have.\n\n### Why is this needed?\n\nPeople want to know a token count because they want to know a cost, so show the cost.\n\n### Additional context\n\n_No response_",
"number": 2094,
"title": "Show costs",
"url": "https://github.com/google-gemini/gemini-cli/issues/2094",
"analysis": "Convert and display the estimated monetary cost of API usage alongside token counts in the CLI statistics.",
"effort_level": "small",
"reasoning": "This is a localized UI and logic update. It involves creating a static pricing lookup table for Gemini models and updating the existing statistics display component to calculate and format the cost. This falls under trivial logic and UI adjustments within the defined criteria.",
"recommended_implementation": "Add a model-to-price mapping in `packages/core/src/config/models.ts`. Update `packages/cli/src/ui/components/StatsDisplay.tsx` to calculate and render the cost string (e.g., '$0.02') based on the current usage counts.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nI would like to request the addition of codebase indexing capabilities to Gemini-CLI. This feature would involve the CLI being able to scan, parse, and create an internal index of the user's local project codebase. This index would include information about file paths, function definitions, class structures, variable declarations, and other relevant code elements.\n\n\n### Why is this needed?\n\nImplementing codebase indexing is crucial for significantly enhancing the utility and efficiency of Gemini-CLI. Here's why it's needed:\n\nMore Relevant and Context-Aware Suggestions: Without an understanding of the user's specific project, Gemini-CLI currently provides general responses. By indexing the local code, the CLI could offer highly accurate and project-specific suggestions for code completion, problem-solving, and general inquiries, moving beyond generic answers to truly context-aware assistance.\n\nImproved Efficiency in Code Generation and Modification: When a user requests code generation or modification, an indexed understanding of existing functions, classes, and variables would allow Gemini-CLI to produce snippets that seamlessly integrate into the user's project's existing architecture, reducing the need for manual adjustments and ensuring consistency.\n\nFaster Navigation and Information Retrieval: Developers frequently need to quickly locate definitions, understand dependencies, or recall specific syntax within their projects. With an indexed codebase, users could ask Gemini-CLI direct questions about their code (e.g., \"Where is functionX defined?\", \"What are the parameters for classY's constructor?\", \"Show me all implementations of interfaceZ?\"), and receive immediate, precise answers without having to manually search files.\n\nEnabling More Sophisticated Refactoring and Debugging Assistance: A comprehensive and up-to-date understanding of the code's structure, relationships, and dependencies would empower Gemini-CLI to suggest more intelligent refactoring options, identify potential issues during debugging (e.g., unused variables, unreachable code, or type mismatches), and even propose solutions that are tailored to the user's specific codebase.\n\nReduced Cognitive Load and Increased Productivity: By offloading the need for developers to constantly remember or manually look up project-specific details, codebase indexing would significantly reduce cognitive load, allowing developers to focus more on problem-solving and innovation rather than repetitive information retrieval.\n\nIn essence, codebase indexing would transform Gemini-CLI from a helpful general assistant into an indispensable, project-aware co-pilot for developers, drastically improving the user experience and overall productivity.\n\n### Additional context\n\nImplementation Considerations: The indexing process could involve an initial comprehensive scan when a project is opened or a new project is initialized, followed by incremental updates (e.g., triggered by file saves or a daemon process) to maintain an up-to-date representation of the codebase.\n\nConfiguration: Users should ideally have control over which directories or file types are indexed to exclude irrelevant files (e.g., node_modules, build directories, .git). A configuration file (e.g., a .geminiignore similar to .gitignore) could be used for this purpose.\n\nPrivacy and Performance: Consideration should be given to ensuring that indexing is performed locally and does not transmit code outside the user's environment. Performance optimization will also be key, especially for large codebases.\n\nIntegration with existing features: The indexed information could be directly leveraged by existing and future Gemini-CLI features that interact with code, such as code generation, code explanation, and error analysis.",
"number": 2065,
"title": "Add Codebase Indexing for Enhanced Context and Efficiency",
"url": "https://github.com/google-gemini/gemini-cli/issues/2065",
"analysis": "Implement codebase indexing capabilities to provide the agent with a global understanding of the project's structure, symbols, and dependencies.",
"effort_level": "large",
"reasoning": "Implementing codebase indexing is a major subsystem addition that involves recursive filesystem scanning, multi-language parsing (AST or symbol extraction), persistent storage (SQLite or vector store), and the creation of new retrieval tools for the agent. This falls under the 'Major Subsystems' and 'Architectural Changes' criteria, requiring significant effort for performance optimization and integration.",
"validated": true
},
{
"body": "### What would you like to be added?\n\nGemini should reply in the same language as the question just like Claude Code does.\n\n### Why is this needed?\n\nPeople may use different language.\n\n\n\n### Additional context\n\n_No response_",
"number": 1871,
"title": "Should reply in the same language as the question",
"url": "https://github.com/google-gemini/gemini-cli/issues/1871",
"analysis": "Update the agent to automatically detect the user's language and respond in the same language.",
"effort_level": "small",
"reasoning": "This task primarily involves updating the system instructions or base prompt templates to include a directive for language consistency. It is a localized string-based adjustment to the agent's configuration and does not require complex logic, external libraries, or architectural changes.",
"recommended_implementation": "In `packages/core/src/core/geminiChat.ts`, add a lightweight language detection call on the user's first prompt and append a 'Respond in [Language]' instruction to the system prompt.",
"validated": true
}
]
Reference in New Issue Copy Permalink