From 7e66c0578f8321207af7b2a1ac9d6b51681cdee0 Mon Sep 17 00:00:00 2001
From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com>
Date: Sat, 30 May 2026 20:41:23 +0000
Subject: [PATCH 1/3] docs: clarify that denied TCP connections can appear
 successful inside the sandbox

---
 docs/sandbox/internet-access.mdx | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/sandbox/internet-access.mdx b/docs/sandbox/internet-access.mdx
index 1f9f1ee5..cf22d02e 100644
--- a/docs/sandbox/internet-access.mdx
+++ b/docs/sandbox/internet-access.mdx
@@ -173,6 +173,16 @@ sandbox = Sandbox.create(
 Domain-based filtering only works for HTTP traffic on port 80 (via Host header inspection) and TLS traffic on port 443 (via SNI inspection). Traffic on other ports uses CIDR-based filtering only. UDP-based protocols like QUIC/HTTP3 are not supported for domain filtering.
 </Note>
 
+<Warning>
+**Blocked connections may appear successful from inside the sandbox.**
+
+For TCP traffic, the firewall has to accept the connection on the sandbox-side proxy first and then use a syscall to retrieve the original destination IP before it can decide whether the destination is allowed. This means that, from inside the sandbox, a TCP connection (e.g. a `connect()` call or a check like `bash -c '</dev/tcp/host/port'`) can succeed and report the socket as open even when the destination is denied by your `denyOut` rules — no packets actually reach the destination.
+
+To verify that traffic is reaching its destination, check for an application-level response (e.g. an HTTP status code, a TLS handshake, or expected protocol bytes) rather than relying on the TCP connection succeeding.
+
+This is a limitation of how outbound traffic is currently routed from the sandbox to our firewall and may change in the future.
+</Warning>
+
 ### Priority rules
 
 When both `allow out` and `deny out` are specified, **allow rules always take precedence** over deny rules. This means if an IP address is in both lists, it will be allowed.

From f9ed5feade5de471da6bd51f64b433aad3f2611c Mon Sep 17 00:00:00 2001
From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com>
Date: Mon, 1 Jun 2026 06:56:05 +0000
Subject: [PATCH 2/3] docs: use Note callout with reviewer-approved wording

---
 docs/sandbox/internet-access.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/sandbox/internet-access.mdx b/docs/sandbox/internet-access.mdx
index cf22d02e..af1e5dd9 100644
--- a/docs/sandbox/internet-access.mdx
+++ b/docs/sandbox/internet-access.mdx
@@ -173,15 +173,15 @@ sandbox = Sandbox.create(
 Domain-based filtering only works for HTTP traffic on port 80 (via Host header inspection) and TLS traffic on port 443 (via SNI inspection). Traffic on other ports uses CIDR-based filtering only. UDP-based protocols like QUIC/HTTP3 are not supported for domain filtering.
 </Note>
 
-<Warning>
-**Blocked connections may appear successful from inside the sandbox.**
+<Note>
+Due to firewall design, blocked connections may appear successful from inside the sandbox.
 
-For TCP traffic, the firewall has to accept the connection on the sandbox-side proxy first and then use a syscall to retrieve the original destination IP before it can decide whether the destination is allowed. This means that, from inside the sandbox, a TCP connection (e.g. a `connect()` call or a check like `bash -c '</dev/tcp/host/port'`) can succeed and report the socket as open even when the destination is denied by your `denyOut` rules — no packets actually reach the destination.
+The firewall has to accept the connection first before it can decide whether the destination is allowed. This means that, from inside the sandbox, a TCP connection can succeed and report the socket as open even when the destination is denied - no packets actually reach the destination.
 
 To verify that traffic is reaching its destination, check for an application-level response (e.g. an HTTP status code, a TLS handshake, or expected protocol bytes) rather than relying on the TCP connection succeeding.
 
 This is a limitation of how outbound traffic is currently routed from the sandbox to our firewall and may change in the future.
-</Warning>
+</Note>
 
 ### Priority rules
 

From b8d718d28c5acc6bee02e09732f9628202c0ea87 Mon Sep 17 00:00:00 2001
From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com>
Date: Mon, 1 Jun 2026 07:02:36 +0000
Subject: [PATCH 3/3] docs: promote firewall TCP behavior note to its own
 section

---
 docs/sandbox/internet-access.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/sandbox/internet-access.mdx b/docs/sandbox/internet-access.mdx
index af1e5dd9..2f827d56 100644
--- a/docs/sandbox/internet-access.mdx
+++ b/docs/sandbox/internet-access.mdx
@@ -173,7 +173,8 @@ sandbox = Sandbox.create(
 Domain-based filtering only works for HTTP traffic on port 80 (via Host header inspection) and TLS traffic on port 443 (via SNI inspection). Traffic on other ports uses CIDR-based filtering only. UDP-based protocols like QUIC/HTTP3 are not supported for domain filtering.
 </Note>
 
-<Note>
+### Behavior of blocked TCP connections
+
 Due to firewall design, blocked connections may appear successful from inside the sandbox.
 
 The firewall has to accept the connection first before it can decide whether the destination is allowed. This means that, from inside the sandbox, a TCP connection can succeed and report the socket as open even when the destination is denied - no packets actually reach the destination.
@@ -181,7 +182,6 @@ The firewall has to accept the connection first before it can decide whether the
 To verify that traffic is reaching its destination, check for an application-level response (e.g. an HTTP status code, a TLS handshake, or expected protocol bytes) rather than relying on the TCP connection succeeding.
 
 This is a limitation of how outbound traffic is currently routed from the sandbox to our firewall and may change in the future.
-</Note>
 
 ### Priority rules