diff --git a/content/manuals/ai/sandboxes/faq.md b/content/manuals/ai/sandboxes/faq.md
index 5c500c2095f..ca6917b1438 100644
--- a/content/manuals/ai/sandboxes/faq.md
+++ b/content/manuals/ai/sandboxes/faq.md
@@ -65,6 +65,17 @@ sandbox instead of on your host.
 > the sandbox. The agent process can read it directly. Only use this for
 > credentials where proxy-based injection isn't available.
 
+Variables in `/etc/sandbox-persistent.sh` are sourced automatically when
+bash runs inside the sandbox, including interactive sessions and agents
+started with `sbx run`. If you run a command directly with
+`sbx exec <name> <command>`, the command runs without a shell, so the
+persistent environment file is not sourced. Wrap the command in `bash -c`
+to load the environment:
+
+```console
+$ sbx exec <sandbox-name> bash -c "your-command"
+```
+
 To verify the variable is set, open a shell in the sandbox:
 
 ```console
@@ -72,6 +83,20 @@ $ sbx exec -it <sandbox-name> bash
 $ echo $BRAVE_API_KEY
 ```
 
+## Why do agents run without approval prompts?
+
+The sandbox itself is the safety boundary. Because agents run inside an
+isolated microVM with [network policies](security/policy.md),
+[credential isolation](security/credentials.md), and no access to your host
+system outside the workspace, the usual reasons for approval prompts (preventing
+destructive commands, network access, file modifications) are handled by the
+sandbox isolation layers instead.
+
+If you prefer to re-enable approval prompts, change the permission mode
+inside the session. Most agents let you switch permission modes after
+startup. In Claude Code, use the `/permissions` command to change the mode
+interactively.
+
 ## How do I know if my agent is running in a sandbox?
 
 Ask the agent. The agent can see whether or not it's running inside a sandbox.
diff --git a/content/manuals/ai/sandboxes/security/policy.md b/content/manuals/ai/sandboxes/security/policy.md
index 18d4d38d47e..40060b61ab0 100644
--- a/content/manuals/ai/sandboxes/security/policy.md
+++ b/content/manuals/ai/sandboxes/security/policy.md
@@ -17,6 +17,11 @@ to all sandboxes on the machine.
 The only way traffic can leave a sandbox is through an HTTP/HTTPS proxy on
 your host, which enforces access rules on every outbound request.
 
+Non-HTTP TCP traffic, including SSH, can be allowed by adding a policy rule
+for the destination IP address and port (for example,
+`sbx policy allow network "10.1.2.3:22"`). UDP and ICMP traffic is blocked
+at the network layer and can't be unblocked with policy rules.
+
 ### Initial policy selection
 
 On first start, and after running `sbx policy reset`, the daemon prompts you to
@@ -171,11 +176,11 @@ my-sandbox   network  registry.npmjs.org     transparent  policykit  10:15:20 29
 
 The **PROXY** column shows how the request left the sandbox:
 
-| Value         | Description                                                                                         |
-| ------------- | --------------------------------------------------------------------------------------------------- |
-| `forward`     | Routed through the forward proxy. Supports [credential injection](credentials.md).                  |
-| `transparent` | Intercepted by the transparent proxy. Policy is enforced but credential injection is not available. |
-| `network`     | Non-HTTP traffic (raw TCP, UDP, ICMP). Always blocked.                                              |
+| Value         | Description                                                                                                    |
+| ------------- | -------------------------------------------------------------------------------------------------------------- |
+| `forward`     | Routed through the forward proxy. Supports [credential injection](credentials.md).                             |
+| `transparent` | Intercepted by the transparent proxy. Policy is enforced but credential injection is not available.            |
+| `network`     | Non-HTTP traffic (raw TCP, UDP, ICMP). TCP can be allowed with a policy rule; UDP and ICMP are always blocked. |
 
 Filter by sandbox name by passing it as an argument:
 
diff --git a/content/manuals/ai/sandboxes/troubleshooting.md b/content/manuals/ai/sandboxes/troubleshooting.md
index 493a640dcaa..54b0e32f7b7 100644
--- a/content/manuals/ai/sandboxes/troubleshooting.md
+++ b/content/manuals/ai/sandboxes/troubleshooting.md
@@ -34,6 +34,30 @@ To allow all outbound traffic instead:
 $ sbx policy allow network "**"
 ```
 
+## SSH and other non-HTTP connections fail
+
+Non-HTTP TCP connections like SSH can be allowed by adding a policy rule for
+the destination IP address and port. For example, to allow SSH to a specific
+host:
+
+```console
+$ sbx policy allow network "10.1.2.3:22"
+```
+
+Hostname-based rules (for example, `myhost:22`) don't work for non-HTTP
+connections because the proxy can't resolve the hostname to an IP address in
+this context. Use the IP address directly.
+
+UDP and ICMP traffic is blocked at the network layer and can't be unblocked
+with policy rules.
+
+For Git operations over SSH, you can either add an allow rule for the Git
+server's IP address or use HTTPS URLs instead:
+
+```console
+$ git clone https://github.com/owner/repo.git
+```
+
 ## Can't reach a service running on the host
 
 If a request to `127.0.0.1` or a local network IP returns "connection refused"