[Bug]: Remote HTTPS servers skip Docker security scanners because isolation resolves to none

[srqfab-pd]

What happened?

Scanning the remote Notion MCP server skips all three installed Docker scanners, although Docker is running and global Docker isolation and deep scanning are enabled. The error recommends a per-server Docker setting that cannot fix an HTTP server.

Environment: MCPProxy v0.66.1 (personal), darwin/arm64; Docker daemon 29.8.0 (docker info succeeds). Endpoint: https://mcp.notion.com/mcp, protocol http, no per-server isolation override. Installed scanners: mcp-ai-scanner, nova-proximity, ramparts.

The built-in scanner completes: 45 tool definitions exported, 21 low-severity warnings. This report concerns scanner execution, not the validity of those warnings.

Code trace and regression history

The release history points to commit 72a51c1e36293b1809f2595878a650fe56b87c63, merged in #781.

• First stable tag containing the change: v0.47.0.
• First release candidate: v0.47.0-rc.1.
• v0.46.0 does not contain this scanner isolation-mode check.
• The same blocking logic is present in the v0.67.0 source. Runtime reproduction was on v0.66.1; the other versions were checked through source history.

Call path:

1. internal/server/server.go sets SetIsolationModeResolver to call IsolationManager.ResolveMode for the scanned server.
2. In v0.66.1, internal/config/isolation_resolve.go forces mode none when ServerConfig.Command is empty. This includes remote HTTP servers, even with an explicit per-server Docker mode.
3. internal/security/scanner/engine.go rejects Docker scanners when that resolved mode is none or sandbox.

The original resolver in v0.47.0 has the same empty-command check in internal/upstream/core/isolation.go.

Temporary alternative

mcpproxy security scan notion --scanners tpa-descriptions completes with zero failed scanners. It runs only the built-in scanner and does not restore Docker scan coverage.

Expected behavior

Docker scanners that support captured tool definitions should run in local containers when Docker is available and deep scanning is enabled. A remote server does not need local process isolation for its captured metadata to be scanned.

If a scanner requires unavailable source code, report that specific limitation. Do not suggest an isolation override that the resolver ignores.

Suggested fix: separate permission and availability checks for Docker scanner execution from the target server’s effective process isolation. Preserve explicit scanner security policy. Add regression coverage for a remote HTTP server with no command, working Docker, and deep scanning enabled. Test the error guidance for remote servers as well.

Steps to reproduce

1. Start Docker and confirm that docker info succeeds.
2. Enable deep scanning and install mcp-ai-scanner, nova-proximity, and ramparts.
3. Configure and authenticate the remote Notion MCP server with the relevant settings below.
4. Run mcpproxy security scan notion, or start the scan from the UI.
5. Observe that all three Docker scanners are marked failed and skipped with isolation mode none.

Relevant configuration (authentication omitted):

{
  "docker_isolation": { "enabled": true },
  "security": { "deep_scan": { "enabled": true } },
  "mcpServers": [
    {
      "name": "notion",
      "url": "https://mcp.notion.com/mcp",
      "protocol": "http",
      "enabled": true
    }
  ]
}

MCPProxy version

MCPProxy v0.66.1 (personal) darwin/arm64

Operating system

macOS

Relevant logs

Docker-based scanner mcp-ai-scanner skipped: isolation mode "none" runs no Docker containers, so Docker scanner plugins cannot run for this server. In-process scanners still ran. To run Docker scanners, set isolation.mode to "docker" for this server on a host with a working Docker daemon. See docs/errors/MCPX_DOCKER_SNAP_APPARMOR.md.

The same error occurs for nova-proximity and ramparts.

tpa-descriptions: completed
in-process tool-description scan: 21 finding(s)

Pre-submission checklist

• I searched existing issues and did not find a duplicate
• I ran mcpproxy doctor and reviewed the output

[Dumbris]

Fixed by #1315 (merged 2026-09-20, commit 4ed5072), which separated the scanner-isolation decision from the process-isolation gates. Previously both questions ("how do we spawn this server's own process?" and "may the scanner run its own Docker containers against this server's captured tool definitions?") were resolved by the same gate set, so a remote HTTP/HTTPS server — which has no local command to spawn — silently forced scanner mode to none, skipping every Docker-based scanner regardless of global settings.

ResolveScannerIsolationMode now skips the spawn-only gates ("no local command", "already dockerising"), so remote servers like the Notion example in this issue get scanned normally.

🤖 Generated with Claude Code

[srqfab-pd]

Thank you @Dumbris!