Built-in Slack MCP integration requests full scope superset even when only read tools are exposed

Look for the Slack MCP server implementation in the copilot-cli codebase, likely under a directory like 'mcp' or 'servers'. Find where the OAuth authorization URL is constructed, particularly the scope parameter. The fix involves dynamically generating the scope list based on the exposed tools (slack_read_channel, slack_read_thread, slack_list_channel_members, slack_search_public) or adding a configuration option in mcp-config.json. Test by triggering the OAuth flow locally and verifying the generated URL's scope parameter.

Describe the bug

When authenticating the built-in Slack MCP server ( mcp.slack.com ) via Copilot CLI, the generated OAuth consent URL requests the full superset of Slack scopes — including write scopes ( chat:write ,  files:write ,  channels:write ,  canvases:write ,  lists:write ,  reactions:write ,  im:write ,  mpim:write ,  groups:write ) — even though the session only exposes a small set of read-only tools:

•  slack_read_channel 
•  slack_read_thread 
•  slack_list_channel_members 
•  slack_search_public 

Example generated authorize URL (redacted):

https://slack.com/oauth/v2_user/authorize?response_type=code&client_id=REDACTED&state=REDACTED&code_challenge=REDACTED&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A58672%2F&scope=canvases%3Aread+canvases%3Awrite+channels%3Ahistory+channels%3Aread+channels%3Awrite+chat%3Awrite+emoji%3Aread+files%3Aread+files%3Awrite+groups%3Ahistory+groups%3Aread+groups%3Awrite+im%3Ahistory+im%3Aread+im%3Awrite+lists%3Aread+lists%3Awrite+mpim%3Ahistory+mpim%3Aread+mpim%3Awrite+reactions%3Aread+reactions%3Awrite+search%3Aread.files+search%3Aread.im+search%3Aread.mpim+search%3Aread.private+search%3Aread.public+search%3Aread.users+users%3Aread+users%3Aread.email&resource=https%3A%2F%2Fmcp.slack.com%2F&prompt=select_account

Expected behavior

Actual behavior
Users are asked to grant far broader permissions (including message sending, file uploads, channel creation, list/canvas writes) than the tool set they can actually use, violating least-privilege expectations.

Suggested fix

• Scope the OAuth request dynamically to the active/allowed tool set, or
• Provide a config option (e.g. in  mcp-config.json ) to restrict which scopes are requested for the built-in Slack MCP connection.

Affected version

1.0.87-0

Steps to reproduce the behavior

1. Ensure the built-in Slack MCP server ( mcp.slack.com ) is available in Copilot CLI (no custom config needed — it's a first-party integration).
2. In an interactive Copilot CLI session, run  /mcp  (or trigger any Slack-related request) so Copilot needs to authenticate with Slack.
3. Confirm only a subset of read tools are currently exposed for the session, e.g.  slack_read_channel ,  slack_read_thread ,  slack_list_channel_members ,  slack_search_public  (visible via the tool list /  <tools_changed_notice>  or  /mcp  output).
4. Trigger the OAuth flow (Copilot opens/prints an authorization URL and starts a local loopback listener, e.g.  http://127.0.0.1:PORT/ ).
5. Inspect the generated  https://slack.com/oauth/v2_user/authorize?...  URL's  scope=  query parameter.
6. Observe: the  scope  parameter includes the full superset of Slack scopes — including write scopes ( chat:write ,  files:write ,  channels:write ,  canvases:write ,  lists:write ,  reactions:write ,  im:write ,  mpim:write ,  groups:write ) and additional read scopes ( users:read ,  users:read.email ,  emoji:read ,  search:read.private/mpim/im/files/users ) — none of which are required by the 4 tools actually exposed.

Expected behavior

The requested  scope  list should match only the tools actually enabled/exposed for the current session (or at minimum, be configurable), rather than always requesting the full write+read superset.