Option for Automatic "Proceed Anyways" on Error Dialog

[anojndr]

What specific problem does this solve?

Currently, when Roo encounters an issue and displays the "Roo is having trouble..." dialog, it requires a manual click on "Proceed Anyways" to continue. This can be a minor inconvenience for users who are momentarily away from their keyboard or running tasks that are expected to proceed without constant supervision. The interruption means a task might pause, waiting for user input, which could delay its completion.

• Who is affected? Users who might step away from their computer while Roo is running, or those who prefer a more hands-off experience for certain tasks.
• When does this happen? When Roo displays the "Roo is having trouble..." dialog, which currently requires a manual interaction to dismiss and continue.
• What's the current behaviour vs expected behaviour?
  • Current: Task execution pauses, awaiting a manual click on "Proceed Anyways."
  • Expected: An optional setting would allow the system to automatically click "Proceed Anyways" after a short delay, or immediately, enabling the task to continue without user intervention.
• What's the impact? It can lead to slight delays in task completion if a user is not immediately available to click the button, potentially requiring them to return to their screen to resume progress.

Additional context (optional)

The attached screenshot shows the specific dialog in question. Often, clicking "Proceed Anyways" allows the task to resolve itself and continue, so an automatic option could streamline the workflow for users who trust Roo to handle these minor hiccups.

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

No response

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

No response

Technical considerations (REQUIRED if contributing, optional otherwise)

No response

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

No response

[omagoduck]

Proceed Anyways should not be automatic; it is introduced to catch erroneous or unsuccessful attempts, or stuck in a loop, or similar situations, where it can cause waste of time, money, and literally mess up the codebase. So it's actually like Human in Loop to prevent fatal errors. So this PR is useless. @hannesrudolph

[anojndr]

Proceed Anyways should not be automatic; it is introduced to catch erroneous or unsuccessful attempts, or stuck in a loop, or similar situations, where it can cause waste of time, money, and literally mess up the codebase. So it's actually like Human in Loop to prevent fatal errors. So this PR is useless. @hannesrudolph

That's why it is an "option," because enabling it comes with a risk. You can either disable or enable it. When I click Proceed Anyways, it usually sorts itself out, so it would be a nice QOL to automate that.

[daniel-lxs]

Here's how this could work:

Right now, the limit is hardcoded to 3 in Task.ts, which is what triggers the "Roo is having trouble..." dialog. The nice part is the system already supports making this configurable — it just needs to be wired up.

To make this happen, we'd need to:

1. Add consecutiveMistakeLimit to the baseProviderSettingsSchema in provider-settings.ts so it becomes available to all providers.
2. Pass that setting through the ClineProvider when creating tasks, just like we do for fuzzyMatchThreshold and other provider settings.
3. Handle the case where it's set to 0 by treating it as unlimited. We'd probably just pass Infinity to the Task constructor in that case.
4. Add a migration step so existing provider profiles get the default value of 3, like we did for rateLimitSeconds in ProviderSettingsManager.ts.

This way, the setting stays tied to each provider profile (as requested), keeps the current default behavior, and lets users increase or remove the limit as needed.

One thing to keep in mind: setting the limit to 0 (unlimited) means the model could keep retrying forever if it's stuck in a mistake loop. That could rack up API usage quickly, so users should be aware of the tradeoff.

Once this is in, the setting would show up in the Providers section of the UI alongside the other provider options.