Proposal: Persistent and Resettable Tool Approvals

[varshneydevansh]

Issue

• Unclear how to disable or reset auto-approval for tools #3009

Linked PR

• feat(cli, core): Implement persistent tool approvals and refactor to fix build #3201

---

1. The Core Problem: A "Write-Only" Permission

A user (@imadraude) on the Gemini CLI GitHub filed Issue #3009 because they found a major usability problem.

• What they did: During an interactive session, the CLI asked for permission to run a tool (e.g., the shell). The user chose the "Yes, allow always..." option.
• What they expected: They expected an easy, documented way to later revoke this "always allow" permission. For example, a command like gemini config --reset-approvals or an entry they could remove from the ~/.gemini/config.yaml file.
• What actually happened: The "always allow" choice was saved to a hidden, internal configuration file (configstore), not the user-facing config.yaml. There was no command and no documented method to find and edit this file to undo the permission. The user was permanently stuck with the auto-approval.

This created a poor user experience where a permission, once granted, could not be easily revoked.

2. The Proposed Solution: A Multi-Phase Fix

I thought took on this issue and created Pull Request #3201. My plan was comprehensive and addressed the user's problem directly, while also improving the feature's behavior.

Phase 1: The Emergency Reset (--reset-tool-approvals)

The first and most crucial part was to give users an "escape hatch." This was a new command-line flag to solve the immediate problem.

• How it works: When a user runs gemini --reset-tool-approvals, the CLI finds the settings.json file and clears the list of auto-approved tools.

• Code Example (from integration-tests/reset_tool_approval.test.ts):
  This new test file perfectly demonstrates the intended functionality.

  // 1. Setup: Create a settings file with pre-approved tools
  const testSettings = {
    theme: 'Default',
    selectedAuthType: 'oauth-personal',
    autoApprovedTools: ['shell', 'git'], // Tools are currently approved
  };
  await fs.writeFile(
    USER_SETTINGS_PATH,
    JSON.stringify(testSettings, null, 2),
    'utf-8',
  );
  
  // 2. Action: Run the new CLI command
  const command = `node ${cliPath} --reset-tool-approvals`;
  await execAsync(command);
  
  // 3. Verification: Check that the list of approved tools is now empty
  const updatedSettingsContent = await fs.readFile(USER_SETTINGS_PATH, 'utf-8');
  const updatedSettings = JSON.parse(updatedSettingsContent);
  expect(updatedSettings.autoApprovedTools).to.deep.equal([]); // The list is now empty

Phase 2: Making "Allow Always" Persistent and Transparent

I also realized the original "always" was misleading—it only applied to the current session. The plan was to make it truly persistent.

• How it works: When a user selects "Yes, allow always," the tool's name is saved to the autoApprovedTools array in the user-visible ~/.gemini/settings.json file. On all future runs, the CLI checks this list and will bypass the confirmation prompt if the tool is present.

• Code Example (from packages/cli/src/gemini.tsx):
  This code captures the user's choice in the UI and saves it.

  // This callback is passed down to the UI components
  const onToolAutoApproved = async (toolName: string) => {
    const currentAutoApprovedTools =
      settings.user.settings.autoApprovedTools || [];
    if (!currentAutoApprovedTools.includes(toolName)) {
      const newAutoApprovedTools = [...currentAutoApprovedTools, toolName];
      // Here it is: writing the new list back to the settings file
      await settings.setValue(
        SettingScope.User,
        'autoApprovedTools',
        newAutoApprovedTools,
      );
    }
  };
  
  // ... later, the callback is passed to the main App component
  render(
    <AppWrapper
      config={config}
      settings={settings}
      onToolAutoApproved={onToolAutoApproved}
    />
  );

3. The Hidden Dragon: The Circular Dependency

Implementing this feature revealed a major architectural flaw in the codebase: a circular dependency. This is where the real complexity of the pull request came from.

• The Conflict:

  1. The UI/CLI logic (packages/cli) naturally depends on the application's core logic (packages/core).
  2. To implement persistent approvals, the CoreToolScheduler (in packages/core) needed to know which tools were already approved. This meant it needed access to the settings.
  3. However, the settings logic (settings.ts, which loads and saves settings.json) was located in packages/cli.
  4. This created a loop: cli depends on core, and now core needs to depend on cli. The build system cannot resolve this: cli -> core -> cli.

• The Refactor:
  The only way to fix this was to move the shared dependency to the more fundamental layer. The contributor correctly identified that all settings logic should live in core.

  This is what the file changes in your screenshot show.

  • DELETED: packages/cli/src/config/settings.ts and settings.test.ts.
  • MODIFIED/UNTRACKED: packages/core/src/config/settings.ts and settings.test.ts are now the new home for this logic.

  This refactoring required changing import paths in over 50 files, which is why the pull request became so large (+1,016 −5,820 lines).

4. The Outcome: A Rejected (but valuable) Pull Request

A project collaborator (NTaylorMullen) reviewed the pull request and closed it. This was not because the code was bad, but for two key process-related reasons:

1. PR was too large: A PR that changes 57 files and refactors the core architecture is extremely difficult and risky to review. It's hard to be sure that it doesn't introduce subtle bugs.
2. Unapproved Behavioral Change: The decision to make tool approvals persistent is a significant change to how the CLI behaves. Such a change needs to be discussed with the project maintainers and agreed upon before being implemented. It wasn't on the official roadmap.

5. "What Shall We Do?" - The Path Forward

The maintainer's feedback provides a clear roadmap for how to proceed successfully.

1. Start a Discussion First: Before writing any more code, open a new GitHub "Discussion" or a feature-request "Issue".

   • Title: "Proposal: Persistent and Resettable Tool Approvals"
   • Content: Clearly lay out the problem (Issue Unclear how to disable or reset auto-approval for tools #3009) and the proposed solution. Ask for feedback on the desired behavior:
     • "Should 'allow always' be persistent across sessions?"
     • "Do we agree that a --reset-tool-approvals command is the right solution for the immediate problem?"
   • This gets buy-in from the maintainers before investing time in coding.

2. Break the PR into Smaller, Focused Changes: Do not submit one giant PR. Create a series of small, logical PRs that can be reviewed and merged independently.

   • PR #ONE: The Simple Fix. Create a PR that only adds the --reset-tool-approvals flag. It should not include the logic for persistent approvals. This directly fixes the original bug report, is a small change, and is highly likely to be accepted.

   • PR #TWO: The Architectural Refactor. If the circular dependency must be fixed even for the simple reset command, submit that as a separate PR.

     • Title: "refactor(core): Move settings management from CLI to Core to break circular dependency"
     • Description: Explain why this is necessary, referencing the circular dependency issue. This allows maintainers to review the architectural change on its own merits.

   • PR #THREE: The New Feature. Once the previous PRs are merged and the feature has been approved in the discussion, submit a final, small PR that introduces the persistent "Allow Always" logic.

This step-by-step approach is much safer, easier to review, and far more likely to be successfully merged into the project.