fix: prevent MCP connection errors when toggling auto-approve on running tools

[roomote]

Summary

This PR fixes an issue where clicking the auto-approve checkbox on a running MCP tool would cause a connection error.

Problem

When a user clicks the auto-approve checkbox for an MCP tool that is already running, the system attempts to refresh the tools list by making an MCP request. This can fail if:

• The MCP connection is in an unexpected state
• The server doesn't handle concurrent requests properly
• The tool is actively executing

This results in the error: "Error executing MCP tool: MCP error -32000: Connection closed"

Solution

Modified the updateServerToolList method in McpHub.ts to:

1. Update the local tool state (alwaysAllow/enabledForPrompt) without making MCP requests when possible
2. Only fetch the tools list if it's not already cached and the connection is active
3. Add error handling to gracefully fall back to cached state if MCP requests fail

Testing

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

Related Issue

Fixes #7189

---

Important

Fixes MCP connection errors when toggling auto-approve on running tools by updating local state in updateServerToolList in McpHub.ts.

• Behavior:
  • Fixes connection error when toggling auto-approve on running MCP tools by updating local tool state in updateServerToolList in McpHub.ts.
  • Avoids unnecessary MCP requests by updating local state directly if possible.
  • Adds error handling to use cached state if MCP requests fail.
• Testing:
  • All existing tests pass.
  • Type checking and linting pass.

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

[roomote]

Reviewing my own code is like debugging in production - technically possible but morally questionable.

[roomote]

Is this intentional that we don't handle the case where tools might be undefined after a failed fetch? The catch block logs a warning but continues, and if connection.server.tools becomes undefined after the fetch fails, the subsequent code might not behave as expected.

[roomote]

The comment could be more specific about which connection issues this prevents. Consider:

[roomote]

Could we consider extracting this duplicated logic into a helper method? This same pattern appears in the fetchToolsList method. Something like:

This would make the code more maintainable and reduce duplication.

[daniel-lxs]

Closing this PR as it doesn't actually fix the root cause.

The problem is that when we write to the config file, the file watcher triggers and calls updateServerConnections, which detects the config change via deepEqual and restarts the server anyway. This PR only avoided the fetchToolsList call but the server still gets restarted, causing the running tool to fail.

The real fix needs to prevent the server restart when only alwaysAllow or disabledTools arrays change.