Make confirm_ask behavior consistent with explicit confirmation handling

[DhivakarK-git]

This PR refactors the confirm_ask function to ensure consistent behavior when handling the explicit_yes_required parameter. The changes include:

Improved Logic: The function now handles cases where self.yes is True, False, or None more predictably, ensuring that user confirmation is appropriately prompted or bypassed based on the context.
Removed Unused Code: The unused valid_responses logic has been removed, simplifying the code and improving maintainability.
Enhanced Use Case Support: This update is particularly useful in scenarios where commands suggested by an LLM require manual confirmation even when --yes-always flag is set. It ensures that users are prompted for confirmation when necessary, rather than skipping the confirmation step unintentionally.
These changes improve the clarity, reliability, and usability of the confirm_ask function.

[paul-gauthier]

Thanks for your interest in aider and for taking the time to make this PR.

It sounds like you are fixing a bug? If so, can you add a test case which triggers the bug? The test should fail in the current code base and pass in the new code base.

[DhivakarK-git]

Hi @paul-gauthier,
Based on the documentation and previous discussions, the confirm_ask function is intended to prompt the user for explicit confirmation—especially when explicit confirmation is required for potentially destructive actions. Currently, when both self.yes and explicit_yes_required are true, the function neither presents the prompt nor executes the action; it behaves as if the user had effectively declined (or given a “no”) automatically.

With the updated changes, even if self.yes is true, specifying explicit_yes_required forces the prompt to appear, allowing the user to manually confirm or deny the action. This adjustment ensures that critical commands (like those involving shell commands) are not executed without a deliberate user decision.

I’ve also updated/modified the unit tests to expose this behavior. The tests, which initially failed by demonstrating the lack of proper prompting and action execution, now pass under the corrected logic.

Results from v0.81.2.dev

Would you like me to add these tests to the main branch before merging the PR?

Thanks for your guidance, and I look forward to your feedback.

[paul-gauthier]

The intended behavior is to ignore/deny confirmations in that situation. If the user has specified --yes, they often intend to operate without supervising aider.

[DhivakarK-git]

@paul-gauthier, thanks for clarifying. I now understand that the intention with –-yes-always is to operate fully non-interactively and ignore confirmations. With that in mind, would it make sense to have an optional parameter (for example, –-ask-for-explicit-yes) that forces the prompt for waiting/dangerous actions even when –-yes-always is active? Or should we keep the current behavior as it is?

Let me know what you think but I think this pr is good to be closed.

Thanks Again 🥇