Clarify sandbox networking, env sourcing, and approval defaults (#24745)

## Summary

- Clarify that `/etc/sandbox-persistent.sh` is sourced when bash runs
inside
  the sandbox, but not when `sbx exec <name> <command>` runs a command
  directly without a shell. Add a `bash -c` workaround.
  (Related: docker/sbx-releases#53)
- Add FAQ entry explaining why agents run without approval prompts (the
  sandbox is the safety boundary) and how to re-enable them: change the
  permission mode inside the session, or build a custom template.
  (Related: docker/sbx-releases#47)
- Add a note to the network policy page and a troubleshooting entry
making
  it explicit that SSH and other non-HTTP protocols are always blocked,
  regardless of allow rules. (Related: docker/sbx-releases#46)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: dvdksn

content/manuals/ai/sandboxes/faq.md

@@ -65,13 +65,38 @@ 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
 $ 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.

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:
 

content/manuals/ai/sandboxes/troubleshooting.md

@@ -51,6 +51,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"