From b59f731df3b38aa7651fa9df43687cbd6852290f Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Tue, 4 Aug 2026 15:23:04 +0000 Subject: [PATCH 1/3] docs: remove SSH env forwarding (fixes sandboxes#4743) The integrations page still documented SendEnv and ssh.acceptEnv after client environment forwarding was removed from Docker Sandboxes. Remove the managed SSH directive and describe how the daemon discards client environment requests. Co-Authored-By: Codex --- content/manuals/ai/sandboxes/integrations/_index.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/content/manuals/ai/sandboxes/integrations/_index.md b/content/manuals/ai/sandboxes/integrations/_index.md index 77265d27193..6a4d3aed2f1 100644 --- a/content/manuals/ai/sandboxes/integrations/_index.md +++ b/content/manuals/ai/sandboxes/integrations/_index.md @@ -97,7 +97,6 @@ Host *.sbx UserKnownHostsFile "~/.ssh/sbx_known_hosts" KnownHostsCommand "sbx" ssh known-hosts %H StrictHostKeyChecking yes - SendEnv * # <<< docker sandboxes (managed) <<< ``` @@ -105,11 +104,9 @@ You don't edit this block by hand. The `User _default_user_` sentinel tells the daemon to log you in as the sandbox image's default user, so your host username is never sent. -`SendEnv *` offers host environment variables to the daemon, but the daemon -accepts only variables in its `ssh.acceptEnv` allowlist. Execution-sensitive -variables such as `PATH`, `LD_*`, and `NODE_OPTIONS` are always blocked, even -if added to the allowlist. Accepted values apply only to the SSH session and -aren't stored in the sandbox configuration. +SSH connections don't forward client environment variables into the sandbox. +The daemon acknowledges SSH environment requests for compatibility but ignores +their names and values. The `*.sbx` wildcard maps sandbox hostnames to the sandbox daemon, but it doesn't add individual sandbox names to application host pickers. Enter the From 55caba86db6ddfce433890f26240a4eaa1369ba9 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Wed, 5 Aug 2026 07:26:03 +0000 Subject: [PATCH 2/3] docs: clarify SSH port forwarding SSH clients can expose sandbox-local development services on a host port without Docker port publishing. Document the loopback-only sandbox target restriction and the client-controlled host bind address. --- content/manuals/ai/sandboxes/integrations/_index.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/content/manuals/ai/sandboxes/integrations/_index.md b/content/manuals/ai/sandboxes/integrations/_index.md index 6a4d3aed2f1..ba018512d10 100644 --- a/content/manuals/ai/sandboxes/integrations/_index.md +++ b/content/manuals/ai/sandboxes/integrations/_index.md @@ -122,6 +122,19 @@ Connections don't use a network port or an SSH key: - The host key is verified on every connection, so a rotated daemon key never triggers a host-key mismatch. +SSH clients can use local port forwarding to make a service listening on the +sandbox's loopback interface available on the host. For example, a remote +development client can map `127.0.0.1:4321` in the sandbox to +`127.0.0.1:55565` on the host, choosing an available host port automatically. +Traffic passes through the SSH connection instead of a published Docker port. + +The sandbox daemon accepts forwarded connections only to loopback addresses in +the sandbox, including `localhost`, `127.0.0.0/8`, and `::1`. The SSH client +chooses the bind address for the listener on the host. A listener bound to +`127.0.0.1` or `::1` is reachable only from the host. A client configured to +bind to a non-loopback address can make the forwarded service reachable from +other machines, subject to the host's network and firewall configuration. + Because SSH terminates at the daemon, no SSH server runs inside the sandbox. The sandbox must already be created. If it is stopped, connecting to `.sbx` starts it automatically. From 0b5c81aa7526dd5b4966eb5b19c0b3f0af98169c Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Wed, 5 Aug 2026 07:31:53 +0000 Subject: [PATCH 3/3] docs: structure SSH connection details The SSH implementation details were presented as unrelated paragraphs, making configuration, transport, environment handling, and forwarding hard to distinguish. Group the details under descriptive headings and organize the managed configuration entries as a list. --- .../ai/sandboxes/integrations/_index.md | 35 +++++++++++-------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/content/manuals/ai/sandboxes/integrations/_index.md b/content/manuals/ai/sandboxes/integrations/_index.md index ba018512d10..11ff270af19 100644 --- a/content/manuals/ai/sandboxes/integrations/_index.md +++ b/content/manuals/ai/sandboxes/integrations/_index.md @@ -80,6 +80,8 @@ For example, if you mount `/Users/bob/src/my-project`, select ## How SSH connections work +### Managed SSH configuration + `sbx setup ssh` writes a managed block to your SSH config: `~/.ssh/config` on macOS and Linux, or `%USERPROFILE%\.ssh\config` on Windows. The block is similar to the following: @@ -100,18 +102,15 @@ Host *.sbx # <<< docker sandboxes (managed) <<< ``` -You don't edit this block by hand. The `User _default_user_` sentinel tells the -daemon to log you in as the sandbox image's default user, so your host username -is never sent. +You don't edit this block by hand. Its key entries work as follows: -SSH connections don't forward client environment variables into the sandbox. -The daemon acknowledges SSH environment requests for compatibility but ignores -their names and values. +- `Host *.sbx` maps sandbox hostnames to the sandbox daemon. Application host + pickers don't discover individual sandbox names from this wildcard, so enter + the hostname, such as `demo.sbx`, manually when you configure an integration. +- `User _default_user_` tells the daemon to use the sandbox image's default + user, so your host username is never sent. -The `*.sbx` wildcard maps sandbox hostnames to the sandbox daemon, but it -doesn't add individual sandbox names to application host pickers. Enter the -sandbox hostname, such as `demo.sbx`, manually when you configure an -integration. +### Connection and authentication Connections don't use a network port or an SSH key: @@ -122,6 +121,18 @@ Connections don't use a network port or an SSH key: - The host key is verified on every connection, so a rotated daemon key never triggers a host-key mismatch. +Because SSH terminates at the daemon, no SSH server runs inside the sandbox. +The sandbox must already be created. If it is stopped, connecting to +`.sbx` starts it automatically. + +### Environment variables + +SSH connections don't forward client environment variables into the sandbox. +The daemon acknowledges SSH environment requests for compatibility but ignores +their names and values. + +### Port forwarding + SSH clients can use local port forwarding to make a service listening on the sandbox's loopback interface available on the host. For example, a remote development client can map `127.0.0.1:4321` in the sandbox to @@ -134,7 +145,3 @@ chooses the bind address for the listener on the host. A listener bound to `127.0.0.1` or `::1` is reachable only from the host. A client configured to bind to a non-loopback address can make the forwarded service reachable from other machines, subject to the host's network and firewall configuration. - -Because SSH terminates at the daemon, no SSH server runs inside the sandbox. -The sandbox must already be created. If it is stopped, connecting to -`.sbx` starts it automatically.