Decouple Checkpointing from Manual Approval to Allow Safe Auto-Approval Workflows

[Enlight432]

1. The Goal: The Ideal Workflow

As a user, I want to configure a workflow that achieves three simultaneous objectives to balance convenience and safety:

1. Automatic Approval for File Tools: Tools that modify files within the project workspace (write_file, replace, save_memory) should be executed automatically without requiring a manual confirmation prompt.
2. Manual Approval for Shell Tools: The run_shell_command tool, due to its potential for high-impact changes, should always require explicit manual approval from the user.
3. Reliable Automatic Checkpointing: A recovery checkpoint should be automatically and reliably created before any file system modification occurs, regardless of whether the tool was approved manually or automatically.

Currently, it is not possible to achieve all three objectives simultaneously.

2. The Core Problem: A Conflict in Design

The core issue is a design conflict between the auto-approval mechanisms and the checkpointing trigger. The checkpointing feature appears to be tightly coupled to the manual user approval event, rather than the impending file modification event itself.

As a result, any feature that bypasses the manual approval prompt (like tools.allowed or approval-mode=auto_edit) also bypasses the trigger for creating a checkpoint. This forces users into an undesirable trade-off: choose convenience and sacrifice the safety of checkpoints, or choose safety and sacrifice the convenience of auto-approval.

3. What We've Tried: A Log of Unsuccessful Attempts

To solve this, we have systematically tested every available mechanism, all of which have failed to meet the three core objectives.

Attempt # 1: Using tools.allowed

• Configuration: We added write_file, replace, and save_memory to the tools.allowed array in settings.json.
• Result:
  • ✅ File tools were auto-approved.
  • ✅ Shell tools still required manual approval.
  • ❌ Failure: No checkpoints were created for the auto-approved actions. The /restore command remained empty.
• Reference: This aligns with the checkpointing.md documentation, which states checkpoints are created "When you approve a tool...". Bypassing the prompt means no approval event occurs.

Attempt # 2: Using --approval-mode=auto_edit

• Configuration: We removed the tools.allowed setting and launched the CLI with the --approval-mode=auto_edit flag.
• Result:
  • ✅ File tools were auto-approved.
  • ✅ Shell tools still required manual approval.
  • ❌ Failure: The outcome was identical to Attempt docs: Add setup instructions for API key to README #1. No checkpoints were created for the auto-approved actions.

Attempt # 3: Manually Triggering Checkpoints with run_shell_command

• Idea: Can we manually create a checkpoint by forcing a manually-approved, safe shell command (e.g., run_shell_command(command='true')) before running the main prompt?
• Result:
  • ❌ Failure: Even when run_shell_command is manually approved, it does not trigger the checkpointing mechanism. It seems the trigger is specific to tools explicitly classified as file-modifying.

Attempt # 4: The Only "Working" (but flawed) Workaround

• Idea: Manually trigger a checkpoint using a file-modifying tool that is not in the tools.allowed list.
• Workflow:
  1. Remove all file-modifying tools from tools.allowed.
  2. Before the main task, issue a prompt to create a temporary file (e.g., /checkpoint custom command).
  3. Manually approve this action, which successfully creates a checkpoint.
  4. Issue the main prompt.
  5. Manually approve the actual file modification again.
• Result:
  • ✅ Checkpoints are created reliably.
  • ❌ Failure: This defeats the primary goal of auto-approving file tools and makes the workflow extremely cumbersome.

4. Proposed Solution: Decouple the Checkpointing Trigger

To resolve this conflict, we propose that the checkpointing mechanism be decoupled from the manual approval UI event.

Instead, the trigger for creating a checkpoint should be moved deeper into the execution pipeline. It should be activated whenever the system is about to execute any tool that has been tagged or classified internally as "file-system-modifying," regardless of how that tool's execution was authorized (manually, tools.allowed, or auto_edit).

This change would make the features orthogonal and allow for the ideal, safe, and convenient workflow that users expect. Thank you for considering this improvement.

[gemini-cli]

This is a well-defined enhancement request to improve a core safety feature. The user is proposing to decouple checkpointing from manual UI approval, which affects the core tool execution logic. The impact is moderate as it affects advanced users trying to create safe, automated workflows, making it a P2 priority.

[mdunker]

This is a great enhancement request. The third attempt failure listed above (run_shell_command approvals do not cause a checkpoint to be created) is a reason that checkpointing seems like a broken feature.

I was having Gemini CLI create a file with a specified number of random alphanumeric characters. The first time the model decided to use a python script to create the file, and the second time it generated its own characters and used write_file to create the file. I approved each one. The write_file causes a checkpoint to be created, but the run_shell_command does not -- this is not intuitive when the whole feature is about reverting to a particular point in time (especially when you know the file contents are being tracked by a shadow git repository).

The docs definitely don't specify that a shell command won't be checkpointed. The first sentence of the checkpointing docs page is "The Gemini CLI includes a Checkpointing feature that automatically saves a snapshot of your project’s state before any file modifications are made by AI-powered tools."

[pascalhuszar]

+1 for this proposal. In its current state, it does not reliably create checkpoints

@Enlight432 maybe edit you description so that your numbering, '#n', doesn't mention an existing issue in this repo

[gemini-cli]

Hello! As part of our effort to keep our backlog manageable and focus on the most active issues, we are tidying up older reports.

It looks like this issue hasn't been active for a while, so we are closing it for now. However, if you are still experiencing this bug on the latest stable build, please feel free to comment on this issue or create a new one with updated details.

Thank you for your contribution!