Skip to content

should always require user confirmation before git push --force #5894

@zeroasterisk

Description

@zeroasterisk

What happened?

  1. [user] heres the task
  2. made change
  3. [user] looks good
  4. made git commit
  5. did a git push
  6. [user] what about this bug?
  7. found and fixed a bug
  8. made git commit --amend
  9. did a git push --force

What did you expect to happen?

should NEVER do a git push --force or very explicitly require user confirmation with a warning about using it.

should be wary about git commit --amend if the commit has already been pushed.

Client information

  • CLI Version: 0.1.18
  • Git Commit: cd7e60e
  • Operating System: darwin v24.4.0
  • Sandbox Environment: no sandbox
  • Model Version: gemini-2.5-pro
  • Memory Usage: 411.7 MB

Login information

No response

Anything else we need to know?

Title: Agent amended a commit and force-pushed to remote without user confirmation after a bug fix.

User Story / Scenario:

  1. The user and the agent collaborated on a set of changes, which were then committed to the local main branch with the commit hash A.
  2. The user then identified a bug in the changes that were just committed in A.
  3. The agent correctly identified the cause of the bug and implemented a fix.
  4. To keep the git history clean, the agent correctly staged the fix and used git commit --amend to roll the fix into the original commit, creating a new commit hash B that replaced A.
  5. The agent then attempted to push the updated local main branch to the remote.

Bug / Incorrect Behavior:

After amending the commit, the local and remote branches had diverged. To resolve this, the agent executed git push --force without first explaining the situation to the user or requesting
explicit confirmation for a force push.

Expected Behavior:

When a push is rejected due to divergent histories (a common result of amending a commit that has already been pushed, or in this case, a race condition with another commit), the agent
should:

  1. Recognize the "non-fast-forward" error.
  2. Explain to the user why it happened (e.g., "I amended our last commit, so the local history has changed.").
  3. Clearly state the proposed solution is to use git push --force.
  4. Crucially, explain the implications of a force push (i.e., that it will overwrite the remote branch's history) and ask for explicit user confirmation before proceeding with the command.

Impact:

The agent's unilateral decision to force push could have led to the irreversible loss of commits on the remote branch if another user or process had pushed changes in the intervening time.
It violates the core principle of keeping the user in control of potentially destructive operations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/modelsSupport for Gemini models, multi-modality, local execution, and performance tuning.kind/bugSomething isn't workingpriority/p1Important and should be addressed in the near term.status/need-triageThis issue needs to be triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions