MCP settings changes in second Roo tab do not persist (multi-tab state sync bug)

[roomote]

Summary
A multi-tab persistence bug was discovered while testing PR #8633. When two Roo tabs are open in the same workspace, changes made to MCP tool permissions or MCP Servers from the second tab do not persist and appear to be applied to the original tab.

Reproduction steps

1. Open Roo in a workspace
2. Open a second Roo tab in the same workspace
3. In the newly opened Roo tab, instruct Roo to call an MCP tool
4. Toggle the "always allow" checkbox for the MCP tool
5. Make changes in the "MCP Servers" menu from the second tab
6. Observe: changes from the second tab are not recognized/persisted and appear applied to the first tab

Expected behavior

• Changes made from any tab persist and are reflected across all open Roo tabs.
• The tab that initiated the change immediately reflects the new state.

Actual behavior

• Changes from the second tab do not persist locally in that tab.
• Changes seem to be applied to the original tab instance instead.

Environment

• VS Code + Roo-Code extension
• Reported by @heyseth in PR fix: prevent MCP server restart when toggling tool permissions #8633
• Comment: fix: prevent MCP server restart when toggling tool permissions #8633 (comment)

Notes / suspected cause

• Likely cross-tab state synchronization issue between multiple Roo webviews sharing a single extension host process.
• Programmatic config writes/read consistency might be scoped to one McpHub instance; other webviews may not receive/broadcast updates.
• Needs explicit cross-webview broadcasting (postMessage) and/or subscription to config file changes, with fresh reads from disk.

Related PR

• PR fix: prevent MCP server restart when toggling tool permissions #8633: fix: prevent MCP server restart when toggling tool permissions #8633

Acceptance criteria

• Toggling "always allow" or MCP Server settings in any Roo tab persists and is reflected in all tabs within the same workspace.
• No unintended server restarts or reconnections when toggling.
• Add tests or instrumentation to cover multi-tab scenarios where feasible.

Linked PR

• fix: prevent MCP server restart when toggling tool permissions #8633

[roomote]

I'm exploring a potential fix for the multi-tab MCP settings synchronization issue and will open a PR to share progress.

[roomote]

I've investigated the multi-tab MCP settings synchronization issue and implemented a potential fix. However, during review, some questions arose about the requirements:

Current Implementation

I've modified McpHub.notifyWebviewOfServerChanges() to use McpServerManager.notifyProviders() instead of only notifying the current provider. This ensures all open tabs receive updates when MCP settings change.

Questions Before Creating PR

1. Persistence Mechanism: The issue mentions changes from Tab 2 don't persist. However, I see that McpHub already has file watchers (watchMcpSettingsFile and watchProjectMcpFile) that should detect config file changes. Could you clarify if the issue is:

   • Settings not being written to disk from Tab 2?
   • Settings being written but not being picked up by other tabs?
   • Something else?

2. Scope of Changes: The current fix ensures all tabs are notified when server changes occur. Should this also handle:

   • Tool permission toggles (alwaysAllow)?
   • Server enable/disable state changes?
   • MCP timeout settings?

3. Testing Requirements: The acceptance criteria mention tests for multi-tab scenarios. Given the nature of this issue, would integration tests that mock multiple provider instances be sufficient, or are you looking for E2E tests?

I want to ensure the fix fully addresses the issue before submitting a PR. Could you provide clarification on these points so I can ensure the implementation meets your expectations?

[roomote]

I have opened PR #8635 to address this issue: #8635

The fix modifies the McpHub notification mechanism to broadcast MCP settings changes to all open tabs rather than just the current one. All CI checks are passing.

As noted in my earlier comment and the PR description, this addresses the notification aspect of the issue. If there are additional persistence problems related to file writes or race conditions, those may require further investigation.