dreampiler/kandev
1
0
Fork 0
Code Issues 43 Pull Requests Actions 6 Packages Projects Releases Wiki Activity

docs: simplify public documentation for scanning (#2139)

Browse Source
This commit is contained in:
Carlos Florêncio
2026-08-01 22:02:54 +01:00
committed by GitHub
parent 3b91515f8f
commit 72f01e6c35
42 changed files with 753 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/public/windows-support.md
+12
View File
@@ -7,6 +7,13 @@ description: "Run Kandev on Windows through native and WSL workflows."
Kandev has native Windows x64 desktop and npm/npx releases. WSL 2 remains useful when repositories, agents, or setup scripts assume a Linux environment. Choose one execution environment per Kandev installation; a native process and a WSL process use different filesystems, tools, Docker endpoints, and credential stores even when they can reach each other over localhost.
## Quick path
1. Choose Desktop or the native npm/npx CLI for normal Windows use.
2. Use WSL 2 only when Linux tools or scripts are required.
3. Keep repositories, agents, Docker, and credentials in the same environment as Kandev.
4. Use the troubleshooting section for path, shell, and browser differences.
| Path | Best for | Main limitations |
|---|---|---|
| [Desktop app](./desktop-app.md) | Normal interactive use, native menus/notifications/updates | Windows x64 and WebView2; no service/background mode |
@@ -125,6 +132,9 @@ docker info
The local Docker executor creates its client lazily, so Kandev can start even when Docker Desktop is stopped; the executor fails when first used and retries on a later attempt. Windows drive sharing, bind mounts, corporate Docker policies, and WSL-backed Docker Desktop are external dependencies. Do not expose an unauthenticated Docker TCP endpoint. See [Docker](./docker.md).
<details>
<summary>Run Kandev in WSL 2</summary>
## Run in WSL 2
WSL is the better choice when the repository's commands and agent CLI are Linux-native.
@@ -170,6 +180,8 @@ Keep Linux worktrees in the WSL filesystem (for example under `~/src` or the def
When Docker Desktop WSL integration is enabled for the distribution, verify `docker info` inside WSL. Otherwise install/configure a Linux Docker daemon inside WSL according to your platform policy. Native Windows named-pipe settings do not apply inside WSL; its default endpoint is the Unix socket.
</details>
## Remote executor limitation
The release bundle carries remote `agentctl` helpers for Linux `amd64`/`arm64` and macOS `amd64`/`arm64`. It does not carry a Windows remote helper. Consequently, a Windows desktop/CLI host can control supported Linux/macOS SSH targets, but a Windows machine is not a supported destination for the SSH executor. Remote Docker behavior depends on the target daemon and configured Linux container image; it does not add a Windows `agentctl` remote target.