Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Aug 20, 2025

Problem

When the auto-approve checkbox is clicked for an MCP tool:

  1. updateServerToolList writes the config file with updated alwaysAllow or disabledTools arrays
  2. The file watcher detects the change and triggers handleConfigFileChange
  3. This calls updateServerConnections which uses deepEqual to compare configs
  4. Since the arrays changed, it detects a difference and restarts the server
  5. The running tool execution fails

Solution

Modified updateServerConnections in McpHub.ts to be smarter about when to restart servers:

  1. Added a new helper method configsEqualExcludingToolSettings that compares configs while excluding alwaysAllow and disabledTools arrays
  2. Only restart the server if other config properties (like command, args, url, etc.) have changed
  3. If only alwaysAllow or disabledTools changed, just update the local state and refresh the tools list without restarting

This way, toggling auto-approve won't restart the server and interrupt running tools.

Testing

  • All existing tests pass
  • Type checking passes
  • Linting passes

Fixes #7189


Important

Prevents unnecessary MCP server restarts when only tool settings change by updating updateServerConnections in McpHub.ts.

  • Behavior:
    • Prevents server restart when only alwaysAllow or disabledTools change in updateServerConnections in McpHub.ts.
    • Introduces configsEqualExcludingToolSettings to compare configs excluding alwaysAllow and disabledTools.
    • Updates local state and refreshes tools list without restart if only tool settings change.
  • Testing:
    • All existing tests pass.
    • Type checking and linting pass.

This description was created by Ellipsis for 04d29fa. You can customize this summary. It will automatically update as commits are pushed.

- Added configsEqualExcludingToolSettings helper to compare configs without alwaysAllow and disabledTools
- Modified updateServerConnections to use smart comparison that only restarts servers when essential config changes
- When only tool settings change, update config and refresh tools list without restarting the server
- Fixes #7189 where MCP connections were closing when clicking auto-approve checkbox
@roomote roomote bot requested review from cte, jr and mrubens as code owners August 20, 2025 18:40
@dosubot dosubot bot added size:M This PR changes 30-99 lines, ignoring generated files. bug Something isn't working labels Aug 20, 2025
this.setupFileWatcher(name, validatedConfig, source)
} else {
// Use smart comparison that excludes alwaysAllow and disabledTools
const currentConfig = JSON.parse(currentConnection.server.config)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider wrapping the JSON.parse of the stored config in a try/catch block to defensively handle any unexpected parsing issues, even though the config is expected to be valid.

This comment was generated because it violated a code review rule: irule_PTI8rjtnhwrWq6jS.

Copy link
Contributor Author

@roomote roomote bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

* @param config2 Second configuration to compare
* @returns true if configurations are equal (no restart needed), false otherwise
*/
private configsEqualExcludingToolSettings(config1: any, config2: any): boolean {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function looks good, but it's missing test coverage. Since this is critical functionality that prevents unnecessary server restarts, could we add tests to verify:

  • Configs are considered equal when only alwaysAllow/disabledTools differ
  • Configs trigger restart when other properties change
  • Edge cases like undefined or null configs are handled

currentConnection.server.config = JSON.stringify(config)

// Refresh the tools list to reflect the new settings
if (currentConnection.server.status === "connected") {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentional that we only refresh tools when status is 'connected'? What happens if the server is in 'connecting' state when tool settings change? Should we queue the refresh or handle other states?


// Refresh the tools list to reflect the new settings
if (currentConnection.server.status === "connected") {
currentConnection.server.tools = await this.fetchToolsList(name, source)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If fetchToolsList fails here, the error will be silently swallowed. Should we add error handling to notify the user that the tools list couldn't be refreshed? Something like:
Failed to refresh tools list for

*/
private configsEqualExcludingToolSettings(config1: any, config2: any): boolean {
// Create copies of the configs without alwaysAllow and disabledTools
const config1Copy = { ...config1 }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding defensive programming here. What if config1 or config2 are null/undefined? The spread operator would throw. Maybe add:

const config2Copy = { ...config2 }

// Remove fields that don't require server restart
delete config1Copy.alwaysAllow
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestion: These magic strings ('alwaysAllow', 'disabledTools') appear in multiple places. Consider extracting them as constants at the top of the file for maintainability:

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Aug 20, 2025
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Aug 20, 2025
@hannesrudolph hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Aug 20, 2025
@daniel-lxs
Copy link
Member

After reviewing this PR, I've identified a simpler and more robust solution:

Instead of comparing configs and excluding specific fields, we should prevent server restarts entirely when any MCP tools are currently running. Since we already track tool execution status in the UI (showing "Running"), we can use this information to block restarts during active tool calls.

This approach:

  • Directly addresses the root cause (server restarts interrupting running tools)
  • Eliminates complex config comparison logic
  • Prevents ALL config changes from causing restarts during tool execution, not just permission changes
  • Is simpler to implement and maintain

Closing this PR to implement the cleaner solution. Will update the issue with proper scoping.

@daniel-lxs daniel-lxs closed this Aug 22, 2025
@github-project-automation github-project-automation bot moved this from PR [Needs Prelim Review] to Done in Roo Code Roadmap Aug 22, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Aug 22, 2025
@daniel-lxs daniel-lxs deleted the feature/fix-mcp-server-restart-on-tool-settings branch August 22, 2025 00:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working PR - Needs Preliminary Review size:M This PR changes 30-99 lines, ignoring generated files.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

MCP Server connection closes when clicking to Auto-Approve a MCP tool

4 participants