Docker MCP Toolkit inside Docker Sandbox

I’ve been trying to get the MCP toolkit up and running within a Docker Sandbox. I’ve created a Custom Template for the sandbox and installed the Docker MCP Plugin. Within Claude, the /mcp servers all have a checkmark, indicating that they’ve loaded correctly. Example below

"aws-documentation": {
	"command": "docker",
	"args": [
		"run",
		"-i",
		"--rm",
		"mcp/aws-documentation"
	]
},

When using that MCP server within the sandbox, I’m getting this error:

aws-documentation - search_documentation (MCP)(search_phrase: "durable lambda invocations",
                                                search_intent: "Learn about durable Lambda invocations in
                                                 AWS")
  ⎿  {
       "search_results": [
         {
           "rank_order": 1,
           "url": "",
           "title": "Error searching AWS docs: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
     failed: self-signed certificate in certificate chain (_ssl.c:1032)",
           "context": null
         }
       ],
       "facets": null,
       "query_id": ""
     }

● aws-documentation - search_documentation (MCP)(search_phrase: "AWS Lambda durable execution",
                                                search_intent: "Understand durable execution patterns for
                                                 AWS Lambda")
  ⎿  {
       "search_results": [
         {
           "rank_order": 1,
           "url": "",
           "title": "Error searching AWS docs: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
     failed: self-signed certificate in certificate chain (_ssl.c:1032)",
           "context": null
         }
       ],
       "facets": null,
       "query_id": ""
     }

 The MCP documentation search is hitting an SSL error. Let me try fetching AWS documentation directly.

● Web Search("AWS Lambda durable invocations site:docs.aws.amazon.com 2025")

● Web Search("AWS Lambda durable execution invocation patterns site:aws.amazon.com")

The Web Search tool runs fine, so I know the network policy I’ve attached to the sandbox is working. How do I get the containers to trust the certificate of the proxy that controls the egress?

Please share the output of docker info so we know which exact version of the sandbox plugin is used on your system.

Client: Docker Engine - Community
 Version:    29.2.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.39.0
    Path:     /home/agent/.docker/cli-plugins/docker-mcp

Server:
 Containers: 8
  Running: 8
  Paused: 0
  Stopped: 0
 Images: 9
 Server Version: 29.2.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker. com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.67-linuxkit
 Operating System: Container Platform
 OSType: linux
 Architecture: x86_64
 CPUs: 32
 Total Memory: 3.813GiB
 Name: docker-desktop
 ID: 051f9b5b-3ccd-411a-9fec-210b4dade128
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http:// host.docker.internal:3128
 HTTPS Proxy: http:// host.docker.internal:3128
 No Proxy: localhost,127.0.0.1,::1
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

We need this information from the host.

If you switched the context with docker context use <context name>, please witch it back to desktop-linux and execute docker info again.

I did edit your post and wrapped the output in a code block. You can use the markdown syntax for code blocks or the </> icon in the editor navigation.

Thanks for helping me along the way.

docker context ls # from Host not sandbox

claude-test                                                       npipe:////./pipe/claude-test-docker-public
default                   Current DOCKER_HOST based configuration   npipe:////./pipe/docker_engine
desktop-linux *           Docker Desktop                            npipe:////./pipe/dockerDesktopLinuxEngine

docker info # from Host not sandbox

Client:
 Version:    29.2.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.17.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.3.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.38.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.8
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.42
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.24
    Path:     C:\Program Files\Docker\cli-plugins\docker-pass.exe
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.11.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.19.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 4
  Running: 1
  Paused: 0
  Stopped: 3
 Images: 14
 Server Version: 29.2.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 30.94GiB
 Name: docker-desktop
 ID: e426322f-4a78-4737-97c5-2a831cc28a19
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Thank you for sharing the output! It helps to understand which version of sandboxes is used.

You are spot on: the outgoing web proxy is responsible for the behavior. It indeed terminates the tls connection and establishes a new one. This is used to inject provider credentials into calls to the llm providers. I don’t know if it does the same for mcp servers. Sandboxes are still in an early stage and things progress pretty fast in this area.

And it looks like the bypass mode for HTTPS Tunneling could be the solution for your problem:

1 Like

Thank you so much for solving my issue!

● aws-documentation - search_documentation (MCP)(search_phrase: "durable lambdas AWS Lambda", search_intent: "Learn about durable
                                                lambdas in AWS")
  ⎿  {
       "search_results": [
         {
     … +37 lines (ctrl+o to expand)

● aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html",
                                              max_length: 8000)
  ⎿  {
       "result": "AWS Documentation from https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html:\n\n# Lambda durabl
     e functions\n\nLambda durable functions enable you to build resilient multi-step applications and AI workflows that can exe
     … +54 lines (ctrl+o to expand)

● aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html",
                                              max_length: 8000)
  ⎿  {
       "result": "AWS Documentation from https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html:\n\n# Creatin
     g Lambda durable functions\n\nTo get started with Lambda durable functions, use the Lambda console to create a durable func
     … +66 lines (ctrl+o to expand)

● aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html",
                                              max_length: 8000, start_index: 8000)
  ⎿  {
       "result": "AWS Documentation from https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html:\n\n tab, rep
     lacing the code that Lambda created.\n\n       ```\n       import {\n         DurableContext,\n         withDurableExecutio
     … +66 lines (ctrl+o to expand)

I am glad it’s solved now!

I may have spoken too soon… :laughing:

● aws-documentation - search_documentation (MCP)(search_phrase: "VPC networking overview", search_intent: "Learn about AWS VPC
                                                networking concepts, features, and architecture", product_types: ["Amazon Virtual
                                                Private Cloud"], guide_types: ["User Guide"], limit: 5)
  ⎿  {
       "search_results": [
         {
           "rank_order": 1,
           "url": "",
           "title": "Error searching AWS docs: All connection attempts failed",
           "context": null
         }
       ],
       "facets": null,
       "query_id": ""
     }

● aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html",
                                              max_length: 8000)
  ⎿  {
       "result": "Failed to fetch https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html: All connection
     attempts failed"
     }

∴ Thinking…

  The AWS documentation MCP server doesn't seem to be working. Let me try the WebFetch tool to access AWS documentation directly.

● Fetch(url: "https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html", prompt: "Summarize the key concepts of
       Amazon VPC including what it is, its main components, and core networking features")
  ⎿  Received 22.6KB (200 OK)
# Amazon VPC Summary

Here’s the network policy command I’ve ran from the Host and confirmed to be in the ~/.docker/sandboxes/vm/claude-test/proxy-config.json

docker sandbox network proxy claude-test --policy allow --block-cidr 10.0.0.0/8 --block-cidr 172.16.0.0/12 --block-cidr 192.168.0.0/16 --block-cidr 127.0.0.0/8 --debug --bypass-host aws.amazon.com:443 --bypass-host *.aws.amazon.com:443 --bypass-host awsdocs-content.s3.amazonaws.com:443 --bypass-host *.amazonaws.com:443 --bypass-host youtube.com:443 --allow-host npmjs.com:443

I did update my Host Docker version, so I’ll provide the same details you needed before.

docker context ls # From Host

claude-test                                                       npipe:////./pipe/claude-test-docker-public
default                   Current DOCKER_HOST based configuration   npipe:////./pipe/docker_engine
desktop-linux *           Docker Desktop                            npipe:////./pipe/dockerDesktopLinuxEngine

docker info # From Host

Client:
 Version:    29.2.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.18.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.3.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.39.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.8
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.45
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.24
    Path:     C:\Program Files\Docker\cli-plugins\docker-pass.exe
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.12.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.19.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 4
  Running: 0
  Paused: 0
  Stopped: 4
 Images: 16
 Server Version: 29.2.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 30.94GiB
 Name: docker-desktop
 ID: e426322f-4a78-4737-97c5-2a831cc28a19
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

I changed the MCP server config as a test and the SSL Error came back:

		"aws-documentation": {
			"command": "docker",
			"args": [
				"run",
				"-i",
				"--rm",
				"-e",
				"HTTP_PROXY=http://host.docker.internal:3128",
				"-e",
				"HTTPS_PROXY=http://host.docker.internal:3128",
				"-e",
				"NO_PROXY=localhost,127.0.0.1",
				"mcp/aws-documentation"
			]
		},
● aws-documentation - search_documentation (MCP)(search_phrase: "Amazon VPC Virtual Private Cloud overview", search_intent: "Learn
                                                about AWS VPC fundamentals, features, and concepts", product_types: ["Amazon VPC"],
                                                guide_types: ["User Guide"], limit: 5)
  ⎿  {
       "search_results": [
         {
           "rank_order": 1,
           "url": "",
           "title": "Error searching AWS docs: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed
     certificate in certificate chain (_ssl.c:1032)",
           "context": null
         }
       ],
       "facets": null,
       "query_id": ""
     }

● aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html",
                                              max_length: 8000)
  ⎿  {
       "result": "Failed to fetch https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html: [SSL:
     CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1032)"
     }

Is it safe to assume that you check the required domains with docker sandbox network log <sandbox> and used those as arguments in docker sandbox network proxy?

Hmm, I would have expected that the pass-through mode works for the mcp server container as well. After all, they run on the same Docker Engine inside the MicroVM, which is also used by the claude sandbox container.

Here’s the output of docker sandbox network log. I don’t think I missed any (sub)domains.

Blocked requests:
SANDBOX                      HOST                 RULE                 LAST SEEN         COUNT
claude-test                143.204.204.61:443   <tcp proxy policy>   11:03:58 21-Feb   11
claude-test                143.204.204.44:443   <tcp proxy policy>   11:03:58 21-Feb   11
claude-test                143.204.204.12:443   <tcp proxy policy>   11:03:58 21-Feb   11
claude-test                143.204.204.75:443   <tcp proxy policy>   11:03:58 21-Feb   11
claude-test                44.253.232.210:443   <tcp proxy policy>   11:03:55 21-Feb   1
claude-test                35.160.204.74:443    <tcp proxy policy>   11:03:55 21-Feb   1
claude-test                35.85.133.136:443    <tcp proxy policy>   11:03:55 21-Feb   1
claude-test                255.255.255.255:68   <udp proxy policy>   10:50:25 21-Feb   10
claude-test                44.255.228.28:443    <tcp proxy policy>   09:49:38 21-Feb   3
claude-test                52.25.247.119:443    <tcp proxy policy>   09:49:38 21-Feb   3
claude-test                35.80.151.227:443    <tcp proxy policy>   09:49:38 21-Feb   3

Allowed requests:
SANDBOX                      HOST                                                                               RULE                            LAST SEEN         COUNT
sbox1                       http-intake.logs.us5.datadoghq.com:443                                             <default policy>                12:02:55 21-Feb   6
sbox1                       api.anthropic.com:443                                                              api.anthropic.com:443           12:02:50 21-Feb   50
sbox1                       production.cloudflare.docker.com:443                                               *.docker.com:443                12:01:06 21-Feb   85
sbox1                       registry-1.docker.io:443                                                           *.docker.io:443                 12:01:06 21-Feb   138
sbox1                       auth.docker.io:443                                                                 *.docker.io:443                 12:01:04 21-Feb   10
sbox1                       storage.googleapis.com:443                                                         *.googleapis.com:443            12:00:47 21-Feb   10
sbox1                       docs.aws.amazon.com:443                                                            docs.aws.amazon.com:443         12:00:46 21-Feb   3
sbox1                       github.com:443                                                                     github.com:443                  12:00:36 21-Feb   5
sbox1                       raw.githubusercontent.com:443                                                      raw.githubusercontent.com:443   12:00:02 21-Feb   3
sbox1                       platform.claude.com:443                                                            <default policy>                11:59:58 21-Feb   2
sbox1                       download.docker.com:443                                                            *.docker.com:443                11:59:30 21-Feb   2
sbox1                       archive.ubuntu.com:80                                                              <default policy>                11:59:26 21-Feb   24
sbox1                       security.ubuntu.com:80                                                             <default policy>                11:59:24 21-Feb   9
claude-test                 api.anthropic.com:443                                                              api.anthropic.com:443           11:55:46 21-Feb   722
claude-test                 http-intake.logs.us5.datadoghq.com:443                                             <default policy>                11:55:46 21-Feb   72
claude-test                 storage.googleapis.com:443                                                         *.googleapis.com:443            11:49:53 21-Feb   160
claude-test                 github.com:443                                                                     github.com:443                  11:13:08 21-Feb   38
claude-test                 docs.aws.amazon.com:443                                                            docs.aws.amazon.com:443         11:04:15 21-Feb   31
claude-test                 registry-1.docker.io:443                                                           *.docker.io:443                 10:53:44 21-Feb   150
claude-test                 auth.docker.io:443                                                                 *.docker.io:443                 10:53:44 21-Feb   18
claude-test                 production.cloudflare.docker.com:443                                               *.docker.com:443                10:49:35 21-Feb   76
claude-test                 desktop.docker.com:443                                                             *.docker.com:443                10:49:15 21-Feb   4
claude-test                 raw.githubusercontent.com:443                                                      raw.githubusercontent.com:443   10:39:42 21-Feb   6
claude-test                 platform.claude.com:443                                                            <default policy>                10:39:37 21-Feb   3
claude-test                 download.docker.com:443                                                            *.docker.com:443                10:38:26 21-Feb   2
claude-test                 security.ubuntu.com:80                                                             <default policy>                10:38:20 21-Feb   9
claude-test                 archive.ubuntu.com:80                                                              <default policy>                10:38:20 21-Feb   24
claude-test                 www.youtube.com:443                                                                <default policy>                10:05:08 21-Feb   4
claude-test                 docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com:443   <default policy>                10:04:26 21-Feb   5

It’s not clear where the googleapis.com request is coming from, but that might be from claude.

I just played around with it, but used the shell sandbox and tested it with an alpine container (shouldn’t make a difference):

  • the sandbox specific proxy config can be found on the host in %USERPROFILE%\.docker\sandboxes\vm\<sandbox>\proxy-config
  • the docker sandbox network proxy rules are additive. No need to specify exist rules if you want to add a rule (you can verify it in the file mentioned above)
  • If you start a container, use the args -e http_proxy -e https_proxy -e no_proxy -e HTTP_PROXY -e HTTPS_PROXY -e NO_PROXY in order to make the container use the proxy. Since the variable exists in the sandbox container, there is no need to specify the value again.
  • the started (mcp server) container is still not be able to verify tls chains, as the proxies certificate is not available inside the (mcp server) container → add domain with --bypass-host to bypass the proxies MITM behavior.
  • --bypass-host with the wildcard star, only seem to replace a single subdomain level (adding *:443 did nothing for me).
  • the sandbox container itself, has no problem with HTTPS traffic, as it knows the ca of the proxy and can verify the certificate chain.

I recreated the sandbox from scratch. There must be something wrong with that specific MCP server because the mcp/aws-cdk works. I’m still getting this error from mcp/aws-documentation.

Here’s my MCP config:

		"aws-documentation": {
			"command": "docker",
			"args": [
				"run",
				"-i",
				"--rm",
				"-e",
				"http_proxy",
				"-e",
				"https_proxy",
				"-e",
				"no_proxy",
				"-e",
				"HTTP_PROXY",
				"-e",
				"HTTPS_PROXY",
				"-e",
				"NO_PROXY",
				"mcp/aws-documentation"
			]
		},
		"aws-cdk": {
			"command": "docker",
			"args": [
				"run",
				"-i",
				"--rm",
				"-e",
				"http_proxy",
				"-e",
				"https_proxy",
				"-e",
				"no_proxy",
				"-e",
				"HTTP_PROXY",
				"-e",
				"HTTPS_PROXY",
				"-e",
				"NO_PROXY",
				"mcp/aws-cdk-mcp-server"
			]
		},

Here is the output:

 aws-documentation - read_documentation (MCP)(url: "https://docs.aws.amazon.com/lambda/latest/dg/welcome.html", max_length: 8000)
  ⎿  {
       "result": "Failed to fetch https://docs.aws.amazon.com/lambda/latest/dg/welcome.html: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.
     c:1032)"
     }

● Fetch(https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
  ⎿  Received 18.3KB (200 OK)
mcp__aws-cdk__CDKGeneralGuidance lambda patterns, what are they

● aws-cdk - CDKGeneralGuidance (MCP)
  ⎿  {
       "result": "# AWS CDK General Guidance\n\nThis guide provides essential guidance for AWS CDK development, focusing on when to use specific constructs and tools.\n\n## Getting Started with
     CDK\n\nAlways initialize CDK projects properly using the CDK CLI:\n\n```bash\n# For TypeScript projects\ncdk init app --language typescript\n\n# For Python projects\ncdk init app --language

The url docs.aws.amazon.comshould be covered by your rule --bypass-host *.aws.amazon.com:443. Did you add the rule for the particular sandbox?

You get an TLS chain verification error, which indicates the mcp server can reach the target server, so it must be honoring the proxy variables. If it wouldn’t honor the proxy variables, you would get a network unreachable error, since egress traffic is not possible without the proxy.

This is the proxy-config.json located at "$HOME/.docker/sandboxes/vm/claude-test"

{
  "policy": {
    "default": "allow",
    "logBlocked": false,
    "logAllowed": false
  },
  "network": {
    "allowedDomains": [
      "docs.aws.amazon.com:443",
      "s3.amazonaws.com:443",
      "*.s3.amazonaws.com:443",
      "api.anthropic.com:443",
      "statsig.anthropic.com:443",
      "hub.docker.com:443",
      "*.docker.com:443",
      "api.github.com:443",
      "gist.github.com:443",
      "github.com:443",
      "*.github.com:443",
      "raw.githubusercontent.com:443",
      "aiplatform.googleapis.com:443",
      "generativelanguage.googleapis.com:443",
      "oauth2.googleapis.com:443",
      "vertexai.googleapis.com:443",
      "*.googleapis.com:443",
      "npmjs.com:443",
      "api.openai.com:443",
      "ports.ubuntu.com:443",
      "ports.ubuntu.com:80",
      "go.dev:443",
      "*.go.dev:443",
      "registry.docker.io:443",
      "*.docker.io:443",
      "*.golang.org:443",
      "registry.npmjs.org:443",
      "*.npmjs.org:443",
      "pypi.org:443",
      "*.pypi.org:443",
      "rubygems.org:443"
    ],
    "blockedDomains": [
      "metadata.azure.internal",
      "metadata.google.internal",
      "kube-dns.kube-system.svc.cluster.local"
    ],
    "blockedCIDRs": [
      "10.0.0.0/8",
      "127.0.0.0/8",
      "169.254.0.0/16",
      "172.16.0.0/12",
      "192.168.0.0/16",
      "::1/128",
      "fc00::/7",
      "fe80::/10"
    ],
    "bypassDomains": [
      "aws.amazon.com:443",
      "*.aws.amazon.com:443",
      "awsdocs-content.s3.amazonaws.com:443",
      "*.amazonaws.com:443",
      "youtube.com:443"
    ],
    "bypassCIDRs": []
  }
}

I also want to note, there are no Blocked Requests for claude-test from today.

Looks good to me. It should work. The whole intention of “bypassDomains” is to prevent the proxy to play MITM. What you see is that it plays MITM.

Looks like a bug to me. You can try if creating a new sandbox, and only add -bypass-host *.aws.amazon.com:443 to see whether the problem exists then as well.

Since Sandbox does not have a public Github project, you can register an issue in this Github project:

1 Like

Tried a trimmed version of the network proxy policy… I filed a bug. :slight_smile:

I assume this means that it didn’t work with the trimmed down set of rules in the network proxy policy?

Thank you for filling the bug!

Correct… Interestingly, the aws-cdk MCP server does work. It’s the only one that consistently works. There are MCP servers not listed in our troubleshooting that fail with SSL issues as well.

Hopefully, I’ve provided enough information for it to be tracked down. It’ll be nice to be able to mock my setup, but within a sandbox. :slight_smile: :flexed_biceps:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.