Merge pull request #24591 from dvdksn/sbx-follow-up-fixes

sandboxes: follow-up fixes and clarifications from sbx docs rewrite

.agents/skills/check-pr/SKILL.md

@@ -36,7 +36,9 @@ action.
 
 ## 2. If merged
 
-Report the final state. No further action needed.
+Report the final state. Then check for any unanswered review comments (both
+top-level and inline) and reply to each one explaining what was done or that
+the issue was addressed in a follow-up. Skip to step 6 after.
 
 ## 3. If closed without merge
 
@@ -75,7 +77,27 @@ another PR, closed by automation.
     --field in_reply_to=<comment-id> \
     --field body="<response>"
   ```
-- End every comment with a `Generated by [Claude Code](https://claude.com/claude-code)` footer
+- End every comment reply with a `Generated by [Claude Code](https://claude.com/claude-code)` footer
+- Resolve each thread via GraphQL after replying:
+  ```bash
+  # Get thread IDs
+  gh api graphql -f query='
+    query($owner:String!, $repo:String!, $pr:Int!) {
+      repository(owner:$owner, name:$repo) {
+        pullRequest(number:$pr) {
+          reviewThreads(first:50) {
+            nodes { id isResolved comments(first:1) { nodes { path } } }
+          }
+        }
+      }
+    }' -f owner=docker -f repo=docs -F pr=$ARGUMENTS \
+    --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | {id, path: .comments.nodes[0].path}'
+
+  # Resolve a thread
+  gh api graphql -f query='
+    mutation($id:ID!) { resolveReviewThread(input:{threadId:$id}) { thread { isResolved } } }
+  ' -f id=<thread-id>
+  ```
 - Re-request review if changes were requested
 
 ## 6. Report

content/manuals/ai/sandboxes/agents/custom-environments.md

@@ -86,9 +86,11 @@ CLI, and common development tools like Node.js, Python, Go, and Java.
 
 Each variant also has a `-docker` version (for example,
 `claude-code-docker`) that includes a full Docker Engine running inside the
-sandbox. The `-docker` variants are the defaults used by `sbx run` on macOS
-and Linux. They run in privileged mode with a dedicated block volume at
-`/var/lib/docker`, and `dockerd` starts automatically.
+sandbox — no local Docker daemon required. The `-docker` variants are the
+defaults used by `sbx run` on macOS and Linux. These variants run in
+privileged mode inside the microVM (not on your host), with a dedicated block
+volume at `/var/lib/docker`, and `dockerd` starts automatically inside the
+sandbox.
 
 The block volume defaults to 50 GB and uses a sparse file, so it only
 consumes disk space as Docker writes to it. On Windows, the volume is not

content/manuals/ai/sandboxes/docker-desktop.md

@@ -9,8 +9,8 @@ weight: 80
 
 Docker Desktop includes a built-in sandbox feature for running AI coding
 agents in isolated microVMs using the `docker sandbox` command. This is a
-convenience integration with limited features compared to the standalone
-sandbox CLI.
+convenience integration. For full functionality, use the standalone `sbx`
+CLI instead.
 
 > [!NOTE]
 > The standalone `sbx` CLI provides more features, more flexibility, and doesn't
@@ -112,10 +112,7 @@ $ docker sandbox run <name> -- --continue
 Each sandbox is a lightweight microVM with its own kernel, using your system's
 native virtualization (macOS virtualization.framework, Windows Hyper-V). The
 default agent templates include a private Docker daemon, so `docker build` and
-`docker compose up` run inside the sandbox without affecting your host. On
-Windows, the Docker daemon is not included by default. See
-[Troubleshooting](troubleshooting.md#docker-not-available-inside-the-sandbox-on-windows)
-for a workaround.
+`docker compose up` run inside the sandbox without affecting your host.
 
 ```plaintext
 Host system

content/manuals/ai/sandboxes/get-started.md

@@ -15,8 +15,8 @@ system.
 ## Prerequisites
 
 - macOS (Apple silicon) or Windows (x86_64, Windows 11 required)
-- If you're on Windows, enable Windows Hypervisor Platform (requires
-  elevated permissions):
+- If you're on Windows, enable Windows Hypervisor Platform. Open an elevated
+  PowerShell prompt (Run as Administrator) and run:
   ```powershell
   Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All
   ```

content/manuals/ai/sandboxes/troubleshooting.md

@@ -56,7 +56,7 @@ If credentials are configured correctly but API calls still fail, check
 the `transparent` proxy don't get credential injection. This can happen when a
 client inside the sandbox (such as a process in a Docker container) isn't
 configured to use the forward proxy. See
-[Monitoring network activity](security/policy.md#monitoring-network-activity)
+[Monitoring network activity](security/policy.md#monitoring)
 for details.
 
 ## Docker not available inside the sandbox on Windows
@@ -83,6 +83,7 @@ an unprivileged user without `CAP_CHOWN`, so the operation is denied.
 Use the tar exporter and extract the archive instead:
 
 ```console
+$ mkdir -p ./result
 $ docker build --output type=tar,dest=- . | tar xf - -C ./result
 ```