MCP Enablement Dialog Bypassed in Bypass Permission Mode

Resolved 💬 3 comments Opened Aug 7, 2025 by notdp Closed Aug 15, 2025

Bug Description

Bug Report: Critical MCP enablement dialog is bypassed with byPassPermission mode

Description

The critical trust dialog that allows users to enable project-level MCP servers is completely bypassed when using defaultMode: byPassPermission. This dialog is essential for activating MCP servers defined in .mcp.json, but there's no way to access it without overriding the global permission mode.

The Critical Dialog Being Bypassed

 Do you trust the files in this folder?                                   
                                                                        
 /Users/notdp/Developer/work/xxxxxx-xxxxx                             
                                                                       
 This project also contains MCP servers defined in .mcp.json that can    
 execute code on your machine if enabled.                                
                                                                        
 This project also contains hooks...                                      
                                                                           
 ❯ 1. Yes, proceed with MCP servers and hooks enabled    ← NEED THIS!    
   2. Yes, proceed with MCP servers and hooks disabled                    
   3. No, exit                                                           

This dialog is CRUCIAL because:

  • Option 1 is the ONLY way to enable project-level MCP servers
  • Without selecting Option 1, MCP servers remain inactive
  • It provides granular control over MCP and hooks activation

The Problem

With defaultMode: byPassPermission:

  • ❌ This essential dialog never appears
  • ❌ MCP servers are silently disabled
  • ❌ No alternative way to enable them
  • ❌ Users lose the ability to make this important security decision

Current Broken Workflow

# This SHOULD show the dialog but doesn't:
claude  # Dialog bypassed, MCP disabled 😞

# Must use workaround every time:
claude --permission-mode plan  # Forces dialog to appear

Expected Behavior

byPassPermission should either:

  1. Still show this specific dialog for MCP/hooks decisions (recommended)
  2. Auto-select Option 1 (trust everything including MCP)
  3. Provide a dedicated MCP enablement mechanism

Suggested Fix

Best solution: Treat MCP enablement as a separate concern from file permissions

  • byPassPermission → bypasses file read/write permissions
  • Still shows dialog when .mcp.json or hooks are detected
  • Or add autoEnableMCP: true/false/ask setting

Impact

This breaks the entire MCP workflow for users who want to:

  • Skip routine file permission checks (convenience)
  • But still make conscious decisions about MCP servers (security)

The current implementation treats all permissions as equal, but MCP enablement is a special security decision that deserves its own consideration.

Environment

  • Claude Code version: v1.0.70
  • OS: macOS
  • Settings: defaultMode: byPassPermission
  • Project contains: .mcp.json file and hooks
  • MCP servers configured: playwright, context7
  • IDE: Cursor extension (connected)

Steps to Reproduce

  1. Set default permission mode in settings:

``json
{
"defaultMode": "byPassPermission"
}
``

  1. Create a project with .mcp.json file containing MCP server definitions
  2. Run claude in the project directory
  3. Problem: Permission prompt is bypassed, MCP servers are NOT activated
  4. Workaround needed: Run claude --permission-mode plan to see the dialog

Additional Context

The permission dialog serves two distinct purposes:

  1. File access permissions (reading/writing files)
  2. MCP/hooks activation (executing external code)

These should be treated as separate security decisions. Many users want to bypass routine file permissions for convenience but still want explicit control over MCP server activation for security reasons.

Environment Info

  • Platform: darwin
  • Terminal: cursor
  • Version: 1.0.70
  • Feedback ID: f87bcd2e-2838-4581-a11e-3017b6166cea

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗