From 9a2ed3d25e5e0ffd9c064a29e613c4703a6e10ff Mon Sep 17 00:00:00 2001 From: dprevoznik <58714078+dprevoznik@users.noreply.github.com> Date: Mon, 14 Sep 2026 13:52:28 +0000 Subject: [PATCH 1/2] docs: stop treating playwright as the only way to control the page process-execution.mdx over-indexed on playwright specifically, when kernel actually exposes four ways to drive a session (computer use, playwright execution, CDP, WebDriver BiDi). Generalize the framing to point at /introduction/control and only name playwright where it's the actual product feature. --- browsers/process-execution.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/browsers/process-execution.mdx b/browsers/process-execution.mdx index a556cb8..df9e75e 100644 --- a/browsers/process-execution.mdx +++ b/browsers/process-execution.mdx @@ -3,17 +3,17 @@ title: "Process Execution" description: "Run commands and manage processes alongside the browser" --- -every KERNEL browser runs in a full linux environment. playwright controls what happens in the page; process execution lets you run commands, scripts, and binaries alongside the browser. +every KERNEL browser runs in a full linux environment. [browser control](/introduction/control) handles what happens in the page; process execution lets you run commands, scripts, and binaries alongside the browser. -use process execution when your browser automation needs software or system access outside a playwright callback. code running alongside the browser can access the same files and local browser services, so you can process downloads without transferring them to your application first, run existing command-line tools, or keep a high-frequency agent loop close to the browser. +use process execution when your browser automation needs software or system access outside your page-control calls. code running alongside the browser can access the same files and local browser services, so you can process downloads without transferring them to your application first, run existing command-line tools, or keep a high-frequency agent loop close to the browser. use `process.exec` for bounded commands where you need the result before continuing. use `process.spawn` for agents, servers, watchers, interactive shells, and other long-running processes. after spawning a process, you can inspect its status, stream its output, send input, resize its pty, or terminate it. -if your task only needs the `page`, `context`, and `browser` objects, use [playwright execution](/browsers/playwright-execution). use process execution when you need an executable, operating-system tools, a long-running process, or direct filesystem access. for workloads that need their own deployment and invocation lifecycle, use [KERNEL apps](/apps). +if your task only needs to control the page itself, use one of Kernel's [browser control](/introduction/control) options instead — [playwright execution](/browsers/playwright-execution), computer use, CDP, or WebDriver BiDi. use process execution when you need an executable, operating-system tools, a long-running process, or direct filesystem access. for workloads that need their own deployment and invocation lifecycle, use [KERNEL apps](/apps). ## common production patterns -- **co-locate an agent with its browser.** browser agents often make many small tool calls. upload an agent binary with [file i/o](/browsers/file-io), run it alongside chromium, and point it at the local playwright endpoint to remove a round trip through KERNEL's public api from each call. see the [fx co-located agent cookbook](https://github.com/kernel/cookbooks/tree/main/integrations/fx-colocated-agent) for an end-to-end example. +- **co-locate an agent with its browser.** browser agents often make many small tool calls. upload an agent binary with [file i/o](/browsers/file-io), run it alongside chromium, and connect it to the browser's local control endpoint to remove a round trip through KERNEL's public api from each call. see the [fx co-located agent cookbook](https://github.com/kernel/cookbooks/tree/main/integrations/fx-colocated-agent) for an end-to-end example. - **process downloads before retrieving them.** unpack archives, extract text from documents, resize images, or compress a directory while the files are still alongside the browser, then retrieve only the final artifacts with file i/o. - **run existing command-line tools.** upload a pinned binary or script and call it from the same workflow instead of rewriting it as browser automation code. - **start a session-local helper.** run a local server, callback handler, or file watcher for as long as the browser task needs it. @@ -67,7 +67,7 @@ Use `cwd` to set a working directory, `env` to pass environment variables, `as_u `process.spawn` starts a command without waiting for it to finish, returning a `process_id` you use to manage it afterward. This is the right call for long-running processes — a server, a watcher script, an interactive shell. -If your long-running process is a server, pick a port yourself and don't assume it's free — the VM's own infrastructure (live view, CDP, the playwright daemon) already listens on several, including `8080`, `9222`–`9225`, `8888`, `10001`, and `10002`. +If your long-running process is a server, pick a port yourself and don't assume it's free — the VM's own infrastructure (live view, CDP, the execution API) already listens on several, including `8080`, `9222`–`9225`, `8888`, `10001`, and `10002`. From 8e9f3d9659ac517f27566b6ea976df7fd8b469ec Mon Sep 17 00:00:00 2001 From: dprevoznik <58714078+dprevoznik@users.noreply.github.com> Date: Mon, 14 Sep 2026 13:58:50 +0000 Subject: [PATCH 2/2] docs: keep the playwright daemon reference for the fx co-located agent example That example specifically points at the local playwright daemon, so name it directly instead of the generic control-endpoint phrasing. --- browsers/process-execution.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/browsers/process-execution.mdx b/browsers/process-execution.mdx index df9e75e..f82cc55 100644 --- a/browsers/process-execution.mdx +++ b/browsers/process-execution.mdx @@ -13,7 +13,7 @@ if your task only needs to control the page itself, use one of Kernel's [browser ## common production patterns -- **co-locate an agent with its browser.** browser agents often make many small tool calls. upload an agent binary with [file i/o](/browsers/file-io), run it alongside chromium, and connect it to the browser's local control endpoint to remove a round trip through KERNEL's public api from each call. see the [fx co-located agent cookbook](https://github.com/kernel/cookbooks/tree/main/integrations/fx-colocated-agent) for an end-to-end example. +- **co-locate an agent with its browser.** browser agents often make many small tool calls. upload an agent binary with [file i/o](/browsers/file-io), run it alongside chromium, and point it at the local playwright daemon to remove a round trip through KERNEL's public api from each call. see the [fx co-located agent cookbook](https://github.com/kernel/cookbooks/tree/main/integrations/fx-colocated-agent) for an end-to-end example. - **process downloads before retrieving them.** unpack archives, extract text from documents, resize images, or compress a directory while the files are still alongside the browser, then retrieve only the final artifacts with file i/o. - **run existing command-line tools.** upload a pinned binary or script and call it from the same workflow instead of rewriting it as browser automation code. - **start a session-local helper.** run a local server, callback handler, or file watcher for as long as the browser task needs it.