From 9c31d51fd3203ca5296722b53089474d84f9103b Mon Sep 17 00:00:00 2001 From: guergabo <65991626+guergabo@users.noreply.github.com> Date: Wed, 6 May 2026 19:41:24 +0000 Subject: [PATCH 1/6] Add Docker Sandboxes integration page Documents the kernel/docker-sbx-kit mixin: how to install, what it provides (CLI, skills, proxy-managed Kernel API auth), how to load the kit, troubleshooting, and how it relies on the sbx proxy to keep KERNEL_API_KEY off the sandbox VM. --- docs.json | 1 + integrations/docker-sandboxes.mdx | 193 ++++++++++++++++++++++++++++++ integrations/overview.mdx | 1 + 3 files changed, 195 insertions(+) create mode 100644 integrations/docker-sandboxes.mdx diff --git a/docs.json b/docs.json index 2788c0f..a933800 100644 --- a/docs.json +++ b/docs.json @@ -194,6 +194,7 @@ "integrations/computer-use/yutori" ] }, + "integrations/docker-sandboxes", "integrations/laminar", "integrations/magnitude", "integrations/notte", diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx new file mode 100644 index 0000000..e19d1fe --- /dev/null +++ b/integrations/docker-sandboxes.mdx @@ -0,0 +1,193 @@ +--- +title: "Docker Sandboxes" +description: "Add Kernel tooling and proxy-managed Kernel API auth to Docker Sandboxes via the Kernel kit" +--- + +[Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) (`sbx`) run AI agents in isolated, throwaway VMs. The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [mixin kit](https://docs.docker.com/ai/sandboxes/customize/kits/) that drops Kernel's CLI, agent skills, and proxy-managed API authentication into any Docker sandbox — so an agent inside the sandbox can spin up cloud browsers without ever seeing your real `KERNEL_API_KEY`. + +## Why use the Kernel kit + +- **Authenticated without exposure** — your `KERNEL_API_KEY` stays on the host. The `sbx` proxy injects it as a `Bearer` header on requests to `api.onkernel.com`. The agent inside the sandbox cannot read the key. +- **Pre-installed tooling** — the [Kernel CLI](/info/cli) (`@onkernel/cli`) is installed at sandbox creation, so an agent can run `kernel browsers create`, `kernel invoke`, etc. immediately. +- **Pre-installed skills** — every skill from [`kernel/skills`](https://github.com/kernel/skills) is installed for Claude Code (and copied to `~/.agents/skills` for other agent runners). Claude knows how to use Kernel out of the box. +- **Network-locked** — the kit's allow-list grants only the domains needed for `npm`, GitHub, the skills registry, and `api.onkernel.com`. + +## Prerequisites + +- `sbx` installed and signed in. Follow the [Docker Sandboxes getting started guide](https://docs.docker.com/ai/sandboxes/get-started/). +- A Kernel API key from the [Kernel Dashboard](https://dashboard.onkernel.com/api-keys). +- An Anthropic API key from the [Anthropic Console](https://console.anthropic.com/) if you're using the built-in `claude` agent. + +## Quickstart + + + + ```bash + git clone https://github.com/kernel/docker-sbx-kit.git + cd docker-sbx-kit + ``` + + You can also load it directly from Git without cloning — see [Loading the kit](#loading-the-kit) below. + + + ```bash + export KERNEL_API_KEY=sk-kernel-... + export ANTHROPIC_API_KEY=sk-ant-... + ``` + + The real `KERNEL_API_KEY` stays on the host. The kit declares it as a `proxyManaged` credential, so the sandbox sees a sentinel value — the proxy substitutes the real key on outbound requests. + + + ```bash + sbx run --name kernel-demo --kit . claude -- \ + "Using the Kernel CLI, create a browser and navigate to news.ycombinator.com. Tell me the top five articles." + ``` + + Claude calls the Kernel CLI inside the sandbox, the CLI talks to `api.onkernel.com`, the `sbx` proxy attaches `Authorization: Bearer $KERNEL_API_KEY`, and the request lands on Kernel's API authenticated as you. + + + +## Loading the kit + +The kit can be loaded from a local path, a Git ref, or an OCI registry. All three forms work with `sbx run` and `sbx create`: + +```bash +# Local path +sbx run --kit ./docker-sbx-kit claude + +# Git ref +sbx run --kit "git+https://github.com/kernel/docker-sbx-kit.git" claude + +# Stack with other kits +sbx run --kit ./docker-sbx-kit --kit ./your-other-kit claude +``` + + +`--kit` only takes effect when the sandbox is created. To add the kit to a running sandbox, use `sbx kit add` instead. + + +## What the kit installs + +The kit is a `mixin` — it layers on top of an existing agent (the built-in `claude` agent in the examples above, but any agent works). Its [`spec.yaml`](https://github.com/kernel/docker-sbx-kit/blob/main/spec.yaml) declares: + +### Install commands + +```yaml +commands: + install: + - command: "npm install -g @onkernel/cli" + description: Install Kernel tooling + - command: "npx -y skills add kernel/skills --skill '*' --agent claude-code --global --copy --yes && cp -a \"$HOME/.claude/skills\" \"$HOME/.agents/skills\"" + user: "1000" + description: Install Kernel skills for Claude Code +``` + +The first command installs the [Kernel CLI](/info/cli) globally. The second installs every skill from [`kernel/skills`](https://github.com/kernel/skills) into `~/.claude/skills` for Claude Code, then copies them to `~/.agents/skills` so other agent runners (Codex, Cursor, custom loops) can find them at the standard skills path. + +### Network allow-list + +```yaml +network: + allowedDomains: + - "registry.npmjs.org:443" + - "github.com:443" + - "api.github.com:443" + - "raw.githubusercontent.com:443" + - "release-assets.githubusercontent.com:443" + - "add-skill.vercel.sh:443" + - "skills.sh:443" + - "api.onkernel.com:443" +``` + +If your agent needs to reach additional domains (your own API, a customer site, a CDN), stack a second mixin with the extra `allowedDomains` rather than forking this kit. + +### Proxy-managed credential + +```yaml +credentials: + sources: + kernel: + env: + - KERNEL_API_KEY + +network: + serviceDomains: + api.onkernel.com: kernel + serviceAuth: + kernel: + headerName: Authorization + valueFormat: "Bearer %s" + +environment: + proxyManaged: + - KERNEL_API_KEY +``` + +The `KERNEL_API_KEY` is bound to the `kernel` credential source on the host. The `serviceDomains` map routes outbound traffic to `api.onkernel.com` through that source. The `serviceAuth` rule formats the header. `proxyManaged` ensures the sandbox-side env var is a sentinel — the agent can read it, but it isn't the real secret. + +## Using a different agent + +The Kernel kit is a mixin, so it works with any `sbx` agent — not just `claude`. Replace the agent name in `sbx run`: + +```bash +# Built-in Claude agent +sbx run --kit . claude + +# Your own agent kit +sbx run --kit . --kit ./my-agent-kit my-agent +``` + +See [Docker's kit reference](https://docs.docker.com/ai/sandboxes/customize/kits/) for building agent kits. + +## Validating the kit + +Before running, you can validate the kit and inspect its metadata: + +```bash +sbx kit validate ./docker-sbx-kit +sbx kit inspect ./docker-sbx-kit +``` + +The repo also includes a [smoke script](https://github.com/kernel/docker-sbx-kit/blob/main/scripts/smoke.sh) that creates a sandbox, checks that the CLI and skills are present, and verifies that Kernel API requests succeed through the proxy: + +```bash +KERNEL_API_KEY=sk-kernel-... ./scripts/smoke.sh --create +``` + +## Troubleshooting + +### Sandbox can't reach `api.onkernel.com` + +Check the proxy log to see how outbound requests are being matched: + +```bash +sbx policy log | grep api.onkernel.com +``` + +If requests aren't matching the `kernel` service, confirm `KERNEL_API_KEY` is exported in the host shell that ran `sbx run` or `sbx create`. The `sbx` proxy reads the credential from the host environment at the time of the API call. + +### `kernel` command not found inside the sandbox + +Install commands only run during `sbx run` or `sbx create` — not on subsequent `sbx exec` calls. Confirm install succeeded by recreating the sandbox and watching the install output: + +```bash +sbx rm --force kernel-demo +sbx run --name kernel-demo --kit ./docker-sbx-kit claude +``` + +### Authentication errors from Kernel API + +Verify your host-side key works directly: + +```bash +curl -H "Authorization: Bearer $KERNEL_API_KEY" https://api.onkernel.com/browsers +``` + +If that fails, generate a new key in the [Kernel Dashboard](https://dashboard.onkernel.com/api-keys). + +## Next steps + +- Browse the [Kernel skills repo](https://github.com/kernel/skills) to see what Claude can do out of the box +- Read the [Kernel CLI reference](/info/cli) for commands available inside the sandbox +- Learn about [browser creation](/browsers/create-a-browser) for what the agent can build with Kernel +- Explore [stealth mode](/browsers/bot-detection/stealth) and [Profiles](/auth/profiles) for harder automation targets diff --git a/integrations/overview.mdx b/integrations/overview.mdx index ca7e727..20aab48 100644 --- a/integrations/overview.mdx +++ b/integrations/overview.mdx @@ -30,6 +30,7 @@ Kernel provides detailed guides for popular agent frameworks: - **[Agent Browser](/integrations/agent-browser)** - Browser automation CLI for AI agents - **[Browser Use](/integrations/browser-use)** - AI browser agent framework - **[Claude Agent SDK](/integrations/claude-agent-sdk)** - Run Claude Agent SDK automations in cloud browsers +- **[Docker Sandboxes](/integrations/docker-sandboxes)** - Add Kernel tooling and proxy-managed auth to Docker sandboxes via the Kernel kit - **[Stagehand](/integrations/stagehand)** - AI browser automation with natural language - **[Computer Use (Anthropic)](/integrations/computer-use/anthropic)** - Claude's computer use capability - **[Computer Use (OpenAI)](/integrations/computer-use/openai)** - OpenAI's computer use capability From 5ff388e9bf14152745ae32ca488268469eaa1ad2 Mon Sep 17 00:00:00 2001 From: guergabo <65991626+guergabo@users.noreply.github.com> Date: Wed, 6 May 2026 20:04:55 +0000 Subject: [PATCH 2/6] Trim Docker Sandboxes page to Kernel-unique content Strip duplicated kit/sbx mechanics (loading methods, spec breakdown, generic troubleshooting, validation commands) and route those to Docker's docs and the kit README. Keeps only what's unique to the Kernel integration: the kit's value prop, proxy-managed KERNEL_API_KEY, and the quickstart command. Reduces drift risk as Docker evolves sbx. --- integrations/docker-sandboxes.mdx | 193 ++++-------------------------- 1 file changed, 22 insertions(+), 171 deletions(-) diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx index e19d1fe..6450f04 100644 --- a/integrations/docker-sandboxes.mdx +++ b/integrations/docker-sandboxes.mdx @@ -1,193 +1,44 @@ --- title: "Docker Sandboxes" -description: "Add Kernel tooling and proxy-managed Kernel API auth to Docker Sandboxes via the Kernel kit" +description: "Run agents inside Docker Sandboxes with Kernel tooling and proxy-managed API auth" --- -[Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) (`sbx`) run AI agents in isolated, throwaway VMs. The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [mixin kit](https://docs.docker.com/ai/sandboxes/customize/kits/) that drops Kernel's CLI, agent skills, and proxy-managed API authentication into any Docker sandbox — so an agent inside the sandbox can spin up cloud browsers without ever seeing your real `KERNEL_API_KEY`. +The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) [mixin](https://docs.docker.com/ai/sandboxes/customize/kits/) that gives any `sbx` agent: -## Why use the Kernel kit +- **Kernel CLI** (`@onkernel/cli`) installed at sandbox creation +- **Kernel agent skills** from [`kernel/skills`](https://github.com/kernel/skills), so Claude Code (and any agent that reads `~/.agents/skills`) can drive Kernel without prompting +- **Proxy-managed `KERNEL_API_KEY`** — your real key stays on the host. The `sbx` proxy injects it as `Authorization: Bearer …` on requests to `api.onkernel.com`. The agent inside the sandbox never sees the secret. -- **Authenticated without exposure** — your `KERNEL_API_KEY` stays on the host. The `sbx` proxy injects it as a `Bearer` header on requests to `api.onkernel.com`. The agent inside the sandbox cannot read the key. -- **Pre-installed tooling** — the [Kernel CLI](/info/cli) (`@onkernel/cli`) is installed at sandbox creation, so an agent can run `kernel browsers create`, `kernel invoke`, etc. immediately. -- **Pre-installed skills** — every skill from [`kernel/skills`](https://github.com/kernel/skills) is installed for Claude Code (and copied to `~/.agents/skills` for other agent runners). Claude knows how to use Kernel out of the box. -- **Network-locked** — the kit's allow-list grants only the domains needed for `npm`, GitHub, the skills registry, and `api.onkernel.com`. - -## Prerequisites - -- `sbx` installed and signed in. Follow the [Docker Sandboxes getting started guide](https://docs.docker.com/ai/sandboxes/get-started/). -- A Kernel API key from the [Kernel Dashboard](https://dashboard.onkernel.com/api-keys). -- An Anthropic API key from the [Anthropic Console](https://console.anthropic.com/) if you're using the built-in `claude` agent. +The last point is what makes this integration worth using over `npm install -g @onkernel/cli` inside a custom kit. ## Quickstart - - - ```bash - git clone https://github.com/kernel/docker-sbx-kit.git - cd docker-sbx-kit - ``` - - You can also load it directly from Git without cloning — see [Loading the kit](#loading-the-kit) below. - - - ```bash - export KERNEL_API_KEY=sk-kernel-... - export ANTHROPIC_API_KEY=sk-ant-... - ``` - - The real `KERNEL_API_KEY` stays on the host. The kit declares it as a `proxyManaged` credential, so the sandbox sees a sentinel value — the proxy substitutes the real key on outbound requests. - - - ```bash - sbx run --name kernel-demo --kit . claude -- \ - "Using the Kernel CLI, create a browser and navigate to news.ycombinator.com. Tell me the top five articles." - ``` - - Claude calls the Kernel CLI inside the sandbox, the CLI talks to `api.onkernel.com`, the `sbx` proxy attaches `Authorization: Bearer $KERNEL_API_KEY`, and the request lands on Kernel's API authenticated as you. - - - -## Loading the kit - -The kit can be loaded from a local path, a Git ref, or an OCI registry. All three forms work with `sbx run` and `sbx create`: - -```bash -# Local path -sbx run --kit ./docker-sbx-kit claude - -# Git ref -sbx run --kit "git+https://github.com/kernel/docker-sbx-kit.git" claude - -# Stack with other kits -sbx run --kit ./docker-sbx-kit --kit ./your-other-kit claude -``` - - -`--kit` only takes effect when the sandbox is created. To add the kit to a running sandbox, use `sbx kit add` instead. - - -## What the kit installs - -The kit is a `mixin` — it layers on top of an existing agent (the built-in `claude` agent in the examples above, but any agent works). Its [`spec.yaml`](https://github.com/kernel/docker-sbx-kit/blob/main/spec.yaml) declares: - -### Install commands - -```yaml -commands: - install: - - command: "npm install -g @onkernel/cli" - description: Install Kernel tooling - - command: "npx -y skills add kernel/skills --skill '*' --agent claude-code --global --copy --yes && cp -a \"$HOME/.claude/skills\" \"$HOME/.agents/skills\"" - user: "1000" - description: Install Kernel skills for Claude Code -``` - -The first command installs the [Kernel CLI](/info/cli) globally. The second installs every skill from [`kernel/skills`](https://github.com/kernel/skills) into `~/.claude/skills` for Claude Code, then copies them to `~/.agents/skills` so other agent runners (Codex, Cursor, custom loops) can find them at the standard skills path. - -### Network allow-list - -```yaml -network: - allowedDomains: - - "registry.npmjs.org:443" - - "github.com:443" - - "api.github.com:443" - - "raw.githubusercontent.com:443" - - "release-assets.githubusercontent.com:443" - - "add-skill.vercel.sh:443" - - "skills.sh:443" - - "api.onkernel.com:443" -``` - -If your agent needs to reach additional domains (your own API, a customer site, a CDN), stack a second mixin with the extra `allowedDomains` rather than forking this kit. - -### Proxy-managed credential - -```yaml -credentials: - sources: - kernel: - env: - - KERNEL_API_KEY - -network: - serviceDomains: - api.onkernel.com: kernel - serviceAuth: - kernel: - headerName: Authorization - valueFormat: "Bearer %s" - -environment: - proxyManaged: - - KERNEL_API_KEY -``` - -The `KERNEL_API_KEY` is bound to the `kernel` credential source on the host. The `serviceDomains` map routes outbound traffic to `api.onkernel.com` through that source. The `serviceAuth` rule formats the header. `proxyManaged` ensures the sandbox-side env var is a sentinel — the agent can read it, but it isn't the real secret. - -## Using a different agent - -The Kernel kit is a mixin, so it works with any `sbx` agent — not just `claude`. Replace the agent name in `sbx run`: - -```bash -# Built-in Claude agent -sbx run --kit . claude - -# Your own agent kit -sbx run --kit . --kit ./my-agent-kit my-agent -``` - -See [Docker's kit reference](https://docs.docker.com/ai/sandboxes/customize/kits/) for building agent kits. - -## Validating the kit - -Before running, you can validate the kit and inspect its metadata: - -```bash -sbx kit validate ./docker-sbx-kit -sbx kit inspect ./docker-sbx-kit -``` - -The repo also includes a [smoke script](https://github.com/kernel/docker-sbx-kit/blob/main/scripts/smoke.sh) that creates a sandbox, checks that the CLI and skills are present, and verifies that Kernel API requests succeed through the proxy: - ```bash -KERNEL_API_KEY=sk-kernel-... ./scripts/smoke.sh --create -``` - -## Troubleshooting +export KERNEL_API_KEY=sk-kernel-... +export ANTHROPIC_API_KEY=sk-ant-... -### Sandbox can't reach `api.onkernel.com` - -Check the proxy log to see how outbound requests are being matched: - -```bash -sbx policy log | grep api.onkernel.com +sbx run --name kernel-demo \ + --kit "git+https://github.com/kernel/docker-sbx-kit.git" \ + claude -- \ + "Using the Kernel CLI, create a browser and navigate to news.ycombinator.com. Tell me the top five articles." ``` -If requests aren't matching the `kernel` service, confirm `KERNEL_API_KEY` is exported in the host shell that ran `sbx run` or `sbx create`. The `sbx` proxy reads the credential from the host environment at the time of the API call. +Claude calls `kernel` inside the sandbox → CLI hits `api.onkernel.com` → the `sbx` proxy attaches your `KERNEL_API_KEY` → the request authenticates as you. -### `kernel` command not found inside the sandbox +The kit's full `spec.yaml`, install commands, and allowed domains live in the [repo README](https://github.com/kernel/docker-sbx-kit#readme). -Install commands only run during `sbx run` or `sbx create` — not on subsequent `sbx exec` calls. Confirm install succeeded by recreating the sandbox and watching the install output: - -```bash -sbx rm --force kernel-demo -sbx run --name kernel-demo --kit ./docker-sbx-kit claude -``` - -### Authentication errors from Kernel API +## Prerequisites -Verify your host-side key works directly: +- `sbx` installed and signed in — see [Docker's getting started guide](https://docs.docker.com/ai/sandboxes/get-started/) +- A Kernel API key from the [Kernel Dashboard](https://dashboard.onkernel.com/api-keys) +- An Anthropic API key from the [Anthropic Console](https://console.anthropic.com/) if you're using the built-in `claude` agent -```bash -curl -H "Authorization: Bearer $KERNEL_API_KEY" https://api.onkernel.com/browsers -``` +## Customizing or extending -If that fails, generate a new key in the [Kernel Dashboard](https://dashboard.onkernel.com/api-keys). +For everything not specific to Kernel — loading kits from local paths or OCI registries, stacking multiple mixins, building your own agent kit, debugging the proxy, `sbx kit add` for running sandboxes — see [Docker's kit reference](https://docs.docker.com/ai/sandboxes/customize/kits/). The Kernel kit is a standard mixin and composes with anything else you put on top. ## Next steps -- Browse the [Kernel skills repo](https://github.com/kernel/skills) to see what Claude can do out of the box +- Browse [`kernel/skills`](https://github.com/kernel/skills) to see what Claude can do out of the box - Read the [Kernel CLI reference](/info/cli) for commands available inside the sandbox -- Learn about [browser creation](/browsers/create-a-browser) for what the agent can build with Kernel -- Explore [stealth mode](/browsers/bot-detection/stealth) and [Profiles](/auth/profiles) for harder automation targets +- Learn about [browser creation](/browsers/create-a-browser), [stealth mode](/browsers/bot-detection/stealth), and [Profiles](/auth/profiles) for harder automation targets From 20375b79dfbf23a1793598427ab64564531720b0 Mon Sep 17 00:00:00 2001 From: guergabo <65991626+guergabo@users.noreply.github.com> Date: Wed, 6 May 2026 20:07:21 +0000 Subject: [PATCH 3/6] Simplify page description --- integrations/docker-sandboxes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx index 6450f04..b77a338 100644 --- a/integrations/docker-sandboxes.mdx +++ b/integrations/docker-sandboxes.mdx @@ -1,6 +1,6 @@ --- title: "Docker Sandboxes" -description: "Run agents inside Docker Sandboxes with Kernel tooling and proxy-managed API auth" +description: "Run agents inside Docker Sandboxes with Kernel" --- The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) [mixin](https://docs.docker.com/ai/sandboxes/customize/kits/) that gives any `sbx` agent: From fe7a62446ee4ac161e1230e4dfa576a9084c67fa Mon Sep 17 00:00:00 2001 From: guergabo <65991626+guergabo@users.noreply.github.com> Date: Wed, 6 May 2026 13:37:31 -0700 Subject: [PATCH 4/6] Update docker-sandboxes.mdx --- integrations/docker-sandboxes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx index b77a338..986883f 100644 --- a/integrations/docker-sandboxes.mdx +++ b/integrations/docker-sandboxes.mdx @@ -1,6 +1,6 @@ --- title: "Docker Sandboxes" -description: "Run agents inside Docker Sandboxes with Kernel" +description: "Run agents inside Docker Sandboxes with access to Kernel" --- The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) [mixin](https://docs.docker.com/ai/sandboxes/customize/kits/) that gives any `sbx` agent: From 2be5cdfa560550a99a1308d21dd948c5accdf1cf Mon Sep 17 00:00:00 2001 From: dprevoznik <58714078+dprevoznik@users.noreply.github.com> Date: Tue, 12 May 2026 01:34:40 +0000 Subject: [PATCH 5/6] fix(integrations): correct Kernel CLI reference link Co-Authored-By: Claude Opus 4.7 --- integrations/docker-sandboxes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx index 986883f..d1ed388 100644 --- a/integrations/docker-sandboxes.mdx +++ b/integrations/docker-sandboxes.mdx @@ -40,5 +40,5 @@ For everything not specific to Kernel — loading kits from local paths or OCI r ## Next steps - Browse [`kernel/skills`](https://github.com/kernel/skills) to see what Claude can do out of the box -- Read the [Kernel CLI reference](/info/cli) for commands available inside the sandbox +- Read the [Kernel CLI reference](/reference/cli) for commands available inside the sandbox - Learn about [browser creation](/browsers/create-a-browser), [stealth mode](/browsers/bot-detection/stealth), and [Profiles](/auth/profiles) for harder automation targets From 90857c636922c8d4149701a43f42aae1aa62702e Mon Sep 17 00:00:00 2001 From: dprevoznik <58714078+dprevoznik@users.noreply.github.com> Date: Tue, 12 May 2026 01:39:06 +0000 Subject: [PATCH 6/6] docs(integrations): soften kit-vs-manual-install phrasing Co-Authored-By: Claude Opus 4.7 --- integrations/docker-sandboxes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/integrations/docker-sandboxes.mdx b/integrations/docker-sandboxes.mdx index d1ed388..f2dcd6b 100644 --- a/integrations/docker-sandboxes.mdx +++ b/integrations/docker-sandboxes.mdx @@ -9,7 +9,7 @@ The [Kernel kit](https://github.com/kernel/docker-sbx-kit) is a [Docker Sandboxe - **Kernel agent skills** from [`kernel/skills`](https://github.com/kernel/skills), so Claude Code (and any agent that reads `~/.agents/skills`) can drive Kernel without prompting - **Proxy-managed `KERNEL_API_KEY`** — your real key stays on the host. The `sbx` proxy injects it as `Authorization: Bearer …` on requests to `api.onkernel.com`. The agent inside the sandbox never sees the secret. -The last point is what makes this integration worth using over `npm install -g @onkernel/cli` inside a custom kit. +The last point is the main reason to use this kit over installing `@onkernel/cli` yourself inside a custom kit. ## Quickstart