fix: allow clearing Max Count and Max Cost in Auto-Approve settings

[roomote]

Fixes the issue where clearing the "Max Count" or "Max Cost" fields in Auto-Approve settings would not persist after saving and navigating away.

Problem

When users cleared the Max Count or Max Cost input fields to return to "Unlimited" auto-approvals, the Save button would enable, but after clicking Save and navigating away from settings, the old value would still be present.

Root Cause

The MaxRequestsInput and MaxCostInput components were sending vscode.postMessage immediately on value change (in the handleValueChange callback). This created a race condition where:

1. User clears the field → undefined is sent via postMessage
2. User navigates away → field loses focus
3. FormattedTextField blur handler reformats the display value
4. The cached state still had the old value, causing it to reappear

Solution

Removed the immediate vscode.postMessage calls from both components. The parent SettingsView component already handles sending all settings via postMessage when the Save button is clicked (line 338-339 in SettingsView.tsx). This ensures:

• Changes are only persisted when explicitly saved
• The cached state is the single source of truth until save
• No race conditions between immediate postMessage and blur handlers

Changes

• Removed vscode.postMessage from MaxRequestsInput.handleValueChange
• Removed vscode.postMessage from MaxCostInput.handleValueChange
• Removed unused vscode import from both files

Testing

• Existing tests pass (MaxRequestsInput.spec.tsx)
• Manual testing confirms clearing values now persists correctly

---

Important

Fixes persistence issue for cleared "Max Count" and "Max Cost" fields in Auto-Approve settings by removing immediate vscode.postMessage calls.

• Behavior:
  • Fixes issue where clearing "Max Count" or "Max Cost" fields in Auto-Approve settings did not persist after saving.
  • Ensures changes are only sent when Save button is clicked, preventing race conditions.
• Components:
  • Removed vscode.postMessage from handleValueChange in MaxRequestsInput and MaxCostInput.
  • Removed unused vscode import from both components.
• Testing:
  • Existing tests pass (MaxRequestsInput.spec.tsx).
  • Manual testing confirms clearing values now persists correctly.

^{This description was created by for cae5bc2. You can customize this summary. It will automatically update as commits are pushed.}

---

Note

Removes vscode.postMessage side-effects from Max Cost/Requests inputs so cleared values persist until explicitly saved.

• Settings UI:
  • Remove immediate vscode.postMessage calls from handleValueChange in webview-ui/src/components/settings/MaxCostInput.tsx and MaxRequestsInput.tsx.
  • Drop unused vscode imports in both files.
  • Inputs now solely call onValueChange, deferring persistence to the parent save flow.

^{Written by Cursor Bugbot for commit ceaa3b7. This will update automatically on new commits. Configure here.}

[roomote]

Rooviewer   See task on Roo Cloud

Re-review completed. No new issues found.

The merge from main includes a significant refactoring of auto-approval logic (moved from ChatView to backend) and improved command parsing. The original fix for clearing Max Count/Max Cost fields remains intact and unaffected.

Previous reviews

• cae5bc2: Review #1

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}