Invalid notification of "Unsaved Changes"

[dgm816]

App Version

v3.25.23

API Provider

Not Applicable / Other

Model Used

N/A

Roo Code Task Links (Optional)

When a user changes the mode or API configuration (under the input field on the main interface), the next time the 'Settings' dialog is entered and then exited the user will be prompted if they wish to discard changes when no changes were made within the 'Settings' dialog.

🔁 Steps to Reproduce

1. Open Roo code.
2. Change mode or API under the input field.
3. Open settings.
4. Click 'Done' button.
5. The warning about unsaved changes will appear although no settings were altered.

💥 Outcome Summary

Expected when no changes were altered inside of 'Settings' dialog, there would not be a prompt to save/discard changes.

📄 Relevant Logs or Errors (Optional)

[roomote]

I'm exploring a potential fix for the invalid "Unsaved Changes" notification issue. I'll investigate why changing mode or API configuration triggers the unsaved changes prompt when the Settings dialog is opened and closed without modifications.

[roomote]

I've opened PR #7418 with a fix for this issue: #7418

The fix adds logic to detect and handle external changes (mode/API config changes from the main interface) separately from internal settings changes, preventing the false positive unsaved changes warning.

The implementation has been tested and all existing tests pass. CI checks are currently running on the PR.

[dgm816]

@roomote-agent

I've been able to test some more with the v3.26.0 release. This appears to only be happening when the API configuration (under the input field on the main interface) is set to an OpenRouter type API.

1. If I switch to a mode with an OpenRouter API and then open settings it is triggered.
2. If I leave the mode alone and switch only the API to an OpenRouter API and then open settings it is triggered.
3. If I switch to a new mode and switch the API to a non-OpenRouter API (tested Gemini/Roo Code APIs) it's not triggered.

It seems to trigger when the API is configured to an OpenRouter type (I have multiple configured; they all seem to trigger it), and then the settings dialog is opened.

[daniel-lxs]

After reviewing the attempted fix in PR #7418, I've closed it as it only addresses the symptoms rather than the root cause.

The issue seems to be that something within the API configuration object is changing unexpectedly or not being saved properly when using OpenRouter APIs. When the Settings dialog opens, it detects a difference in the configuration even though nothing was actually changed by the user.

We should look into the config object to see what's changing. It could be:

• Some OpenRouter-specific fields that get auto-populated or modified when the configuration loads
• Fields that aren't properly serialized/deserialized
• Timing issues where the API configuration is still being validated when the Settings dialog opens
• Certain fields that maybe shouldn't trigger the dirty state (like timestamps or auto-refreshing tokens)

Next steps would be to add some logging to identify which specific fields in the OpenRouter configuration are changing, then fix the actual issue rather than trying to ignore the changes.