Add Docker Sandboxes integration guide

[AnnaXWang]

Description

Adds an integration guide for running Kernel inside Docker Sandboxes with the Kernel kit (docker.io/sbx/kernel-kit).

• integrations/docker-sandboxes.mdx covers:
  • storing the API key with sbx secret set kernel
  • launching Claude Code with --kit and approving the credential request
  • verifying the setup and what the kit installs
  • how the host proxy keeps the key out of the sandbox, including pre-approval for non-interactive runs
  • adding the SDK (TypeScript and Python)
  • the kit's network rules and v2 kit compatibility
  • troubleshooting and cleanup
• images/integration-icons/docker.svg is the black Docker mark from Docker's official logo kit, unmodified. The sidebar's dark-mode invert(1) rule renders it white, which is also an approved Docker logo color.
• Lists the page in the Integrations nav (docs.json) and in integrations/overview.mdx.

Implementation Checklist

• N/A: no sample app or CLI changes

Testing

• mint dev renders the page, and the sidebar icon shows correctly in light and dark mode
• mint broken-links passes
• The network rules and pinned tag match the published kit. docker.io/sbx/kernel-kit:latest and 20260928-7da9425e640d172e36abe6de3499a1c75d416c0f have the same digest, and the kit's spec allows **.onkernel.com and *.kernel.sh for browser connections.
• Not yet run end to end against a real Docker Sandboxes install. Before merging, verify:
  • the quickstart: sbx secret set kernel, then sbx run claude --name kernel-demo --kit docker.io/sbx/kernel-kit:latest, the approval prompt, and a browser task
  • the three sbx exec checks under "Verify the setup", which run without a login shell. The second prints proxy-managed, the placeholder Docker's kit-author guide documents for proxy-managed credentials.
  • a browser connection (connectOverCDP) under the Balanced or Locked Down network policy, which exercises the **.onkernel.com and *.kernel.sh rules. docs.docker.com still lists multi-label **. wildcards in kits as "parsed; enforcement pending", while Docker's kit-author guide says they're enforced.
  • sbx skills add kernel/skills --skill kernel-cli makes the skill available in new sandboxes. The command is experimental; cut that section if it doesn't work.

Visual Proof

Checked locally with mint dev in light and dark mode. Screenshots aren't attached.

Additional Notes

• The kit is published from docker/sbx-kits-contrib/kernel, which the page links as the kit's source.
• "Kit versions and compatibility" describes the current v2 kit. It needs an update when a v3 version of the kit ships.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation and navigation only; no product code, APIs, or runtime behavior changes.

Overview
Adds documentation for using Kernel cloud browsers inside Docker Sandboxes via the docker.io/sbx/kernel-kit kit.

The new integrations/docker-sandboxes page walks through sbx secret set kernel, launching an agent with --kit, credential approval, verification commands, what the kit installs, host-side API key proxying (including CI pre-approval), optional SDK setup, network policy rules, kit versioning, troubleshooting, and cleanup. A Docker sidebar icon (images/integration-icons/docker.svg) is included, and the page is linked from docs.json Integrations nav and integrations/overview.mdx.

^{Reviewed by Cursor Bugbot for commit de7862a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Oct 6, 2026, 3:21 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cursor]

Risk level: Very Low. Approving.

The diff is documentation for the Mintlify site only:

• integrations/docker-sandboxes.mdx — new integration guide (user-facing docs, not a model instruction file)
• integrations/overview.mdx — one overview link
• docs.json — one Integrations nav entry
• images/integration-icons/docker.svg — static Docker mark (paths and fills only; no scripts or external references)

No application logic, auth, permissions, infrastructure, or shared runtime code is changed. Blast radius is the docs site navigation and one new page. No CODEOWNERS file is present, and this PR has no existing approval.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk level: Very Low. Existing approval stands.

Re-checked after 78a5b248 (“Narrow the CLI install troubleshooting hint to release downloads”). The only change since the prior approval is one sentence in integrations/docker-sandboxes.mdx: “blocked npm or GitHub requests” became “blocked npm or GitHub release downloads.” Risk did not increase, so this approval is not dismissed and is not repeated.

Full diff remains documentation for the Mintlify site:

• integrations/docker-sandboxes.mdx — new user-facing integration guide (not a model instruction file)
• integrations/overview.mdx — one overview link
• docs.json — one Integrations nav entry
• images/integration-icons/docker.svg — static Docker mark (paths and fills only)

No application logic, auth, permissions, infrastructure, or shared runtime code changed. No CODEOWNERS file is present. Blast radius is the docs site navigation and one new page.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[rgarcia]

reviewed — looks good, approving. a couple of things worth fixing before merge, mainly the stale network rules:

Bugs

• integrations/docker-sandboxes.mdx:196 — network table is stale: the current kit (docker/sbx-kits-contrib#335, 2026-09-28) allows **.onkernel.com and *.kernel.sh ("Direct CDP endpoints are served from hosts under kernel.sh"). sbx kit inspect docker.io/sbx/kernel-kit:latest shows 9 allow rules. consider adding a *.kernel.sh row — this also answers the open *.kernel.sh question in the PR description. same applies to :107 and :217, which only mention *.onkernel.com
• integrations/docker-sandboxes.mdx:211 — the pinned-tag example 20260924-d058… predates that fix (8 allow rules, no *.kernel.sh), so anyone pinning it gets the old kit. consider 20260928-7da9425e640d172e36abe6de3499a1c75d416c0f, which latest currently points to
• integrations/docker-sandboxes.mdx:105 — "it never has your key, so it can't leak it" overclaims a bit: the agent can't read the key, but anything in the sandbox can still make authenticated Kernel API calls through the proxy while it runs. maybe "your agent can't read or exfiltrate the key, though anything in the sandbox can make authenticated Kernel API calls while it runs"

Questions

• integrations/docker-sandboxes.mdx:63-70 — checks 1–2 wrap in sh -lc but check 3 calls kernel directly. if the login shell is needed for PATH/env, check 3 can fail for the wrong reason; if not, consider dropping it from check 1 (check 2 still needs sh -c for the $KERNEL_API_KEY expansion)
• integrations/docker-sandboxes.mdx:73 — is the placeholder literally proxy-managed? worth confirming in the e2e pass, or soften to "prints a placeholder"

Nits

• integrations/docker-sandboxes.mdx:15-17 — the upstream kit README says it works with any agent that ships npm, which might be worth saying here. "This guide covers local sandboxes." reads a little cut off — maybe say cloud sandboxes are untested, or drop it
• integrations/docker-sandboxes.mdx:29 — on headless Linux with no Secret Service, sbx falls back to a 0700 file under ~/.config/com.docker.sandboxes; maybe "usually your OS keychain"

[AnnaXWang]

Thanks Raf, addressed in 9ed63f8.

Bugs

• Network rules: the table now lists **.onkernel.com (API and browser connections) plus a *.kernel.sh row. The key section drops the wss://proxy.<region>… example and says browser connections go to other hosts under onkernel.com and kernel.sh. Troubleshooting now points at blocked requests to onkernel.com or kernel.sh hosts. I took the *.kernel.sh question out of the PR description.
• Pinned tag: now 20260928-7da9425e…, which has the same digest as latest.
• Key wording: went with your suggestion. It now says the agent can't read or exfiltrate the key, but anything in the sandbox can make authenticated Kernel API calls while the sandbox runs.

Questions

• Login shell: not needed. sbx exec follows docker exec, Docker's e2e harness (tck/e2e.go) checks kit env vars with a plain sbx exec <name> -- env, and their kit-author guide verifies installs with sbx exec <name> -- <binary> --version. Check 1 is now kernel --version and check 2 is printenv KERNEL_API_KEY, so none of the three need a shell.
• Placeholder: yes, it's literally proxy-managed. Docker's kit-author guide says the engine sets apiKey.name to the literal proxy-managed when proxyManaged: true. Kept it, and it's on the e2e list.

Nits

• Added that the kit works with any agent whose sandbox has npm. Dropped "This guide covers local sandboxes." rather than calling cloud sandboxes untested on a public page.
• Now "usually in your OS keychain".

Still open for the e2e pass: a real CDP connect under Balanced or Locked Down. docs.docker.com still lists **. in kits as "parsed; enforcement pending" (the kit-author guide says enforced), and since the kit replaced *.onkernel.com, api.onkernel.com depends on **. too.