Open Interpreter 在 Windows 上的安装与运行指南：原生 PowerShell 与 WSL 双工作流实战

Open Interpreter 是一款面向本地与开放模型的终端编码代理（项目自身定位为 "A coding agent for open models like Kimi K3 and GLM 5.3"），能够在检查代码库、编辑文件、运行命令后继续工作。本文聚焦 docs/zh/windows.md 中 Windows 平台的使用要点，系统讲解「原生 Windows + PowerShell」与「WSL 类 Linux」两条安装路径、路径与 Shell 的选择准则，以及 Windows 原生沙箱的行为边界与安全建议。读完本文，你将掌握 interpreter（及简写 i）在 Windows 上的安装、验证、升级、定制与沙箱策略配置，并理解这些操作背后的仓库实现原理。

两种 Windows 工作流：先选对运行环境

Open Interpreter 的命令行界面（CLI）与本地沙箱架构同时支持两种 Windows 形态，官方推荐按项目自身的工具链习惯来选择：

工作流	适用场景	Shell 与路径风格	沙箱模型
原生 Windows	项目全部使用 Windows 生态工具	PowerShell、C:\... Windows 路径	原生 Windows 沙箱（OS 强制细节与 macOS/Linux 不同）
WSL	项目已使用 Linux 工具链、脚本、路径习惯	Bash、/home/... Linux 路径	与 Linux 一致的 Bubblewrap/seccomp 模型

如果项目中的命令、构建脚本、依赖都以 Linux 约定编写，那么在 WSL 中运行 Open Interpreter 通常更省事——它能直接调用 Linux 原生命令；反之，原生 Windows 项目则应坚持 PowerShell 与 Windows 路径。这一判断直接决定了下方两条安装路线，也对应 docs/zh/windows.md 中「Paths and Shells」一节的结论。

原生 Windows：PowerShell 一行命令安装

在 PowerShell（建议以普通用户身份，无需管理员权限）中执行官方安装命令：

irm https://www.openinterpreter.com/install.ps1 | iex

命令由两部分组成：irm（Invoke-RestMethod）把远程安装脚本拉取下来，iex（Invoke-Expression）在当前会话中执行它。

安装器做了什么

这个远程脚本对应仓库中的 scripts/install/install-open-interpreter.ps1：它先根据环境变量把 CODEX_GITHUB_REPO、CODEX_INSTALL_PRODUCT_NAME、CODEX_PACKAGE_ASSET_STEM、CODEX_COMMAND_NAME、CODEX_HOME、CODEX_INSTALL_DIR、CODEX_RELEASE 等内部参数预置好（默认产品名 "Open Interpreter"、命令名 interpreter、别名 i），然后下载真正的安装逻辑脚本并执行。

真正干活的是 scripts/install/install.ps1，其核心流程：

1. 环境前置校验：仅支持 Windows_NT（install.ps1），并要求 64 位系统；
2. 架构识别：检测运行时架构，将 arm64 映射为目标 aarch64-pc-windows-msvc、x64 映射为 x86_64-pc-windows-msvc，不支持其他架构会直接报错；
3. 版本解析：默认解析最新发布版（latest），校验版本号格式 x.y.z[-alpha[.N]|-beta[.N]]；已安装旧版本时自动输出升级提示；
4. 下载与完整性校验：从 GitHub Release 下载与平台、版本匹配的 open-interpreter-package-<target>.tar.gz 压缩包及 SHA256SUMS 清单，下载后校验 SHA-256 摘要，防止损坏或不一致；
5. 受管目录布局：安装到用户目录（默认 $env:USERPROFILE\.openinterpreter\packages\standalone\releases\<版本>-<目标>），用 Windows Junction（目录联接）把 current 与对外可见的 bin 目录指向当前版本，便于后续自更新原子切换；
6. PATH 配置：默认把 $env:LOCALAPPDATA\Programs\Open Interpreter\bin 写入用户级环境变量 Path，供后续 PowerShell 会话使用；
7. 自检与启动：对 interpreter.exe 及其别名执行 --version 验证，最后询问是否立即启动。

重启终端并验证

安装脚本只更新了用户级 PATH，当前已打开的终端不会感知，因此文档要求重启终端：

interpreter --version

首次安装成功后，可运行 i（interpreter 的简写别名）进入交互式 TUI，或用带提示的命令直接启动（详见 docs/zh/quickstart.md）：

i
interpreter "explain this repo"
interpreter exec "summarize the current diff"

可定制的环境变量

从 scripts/install/install.ps1 的参数定义（第 2-8 行）与 scripts/install/install-open-interpreter.ps1 的默认值映射可以看出，安装行为可通过以下环境变量定制（均为可选）：

环境变量	作用	默认值
OPEN_INTERPRETER_RELEASE	指定要安装的版本（如 0.1.0）	latest
OPEN_INTERPRETER_GITHUB_REPO	发布资产所在的 GitHub 仓库	openinterpreter/openinterpreter
OPEN_INTERPRETER_INSTALL_DIR	bin 命令所在目录（覆盖默认安装位置）	%LOCALAPPDATA%\Programs\Open Interpreter\bin
INTERPRETER_HOME	用户数据/standalone 根目录（覆盖默认 home）	%USERPROFILE%\.openinterpreter
OPEN_INTERPRETER_NONINTERACTIVE	设为 1/true/yes 跳过交互提示	未设置（交互式）

例如指定版本并跳过交互提示：

$env:OPEN_INTERPRETER_RELEASE = "0.1.0"
irm https://www.openinterpreter.com/install.ps1 | iex

注意：若设置了自定义安装位置，后续更新、卸载也要使用同一组变量，否则脚本找不到既有受管安装。

更新与卸载

独立安装会在正常交互式启动时检查更新，也可手动执行更新或重新运行安装命令：

interpreter update

卸载时仅需移除受管 junction 与 standalone 目录。官方推荐的卸载逻辑（详见 docs/zh/install.md）会保留位于 %USERPROFILE%\.openinterpreter 下的配置、会话、日志与凭据：

$binDir = Join-Path $env:LOCALAPPDATA "Programs\Open Interpreter\bin"
$interpreterHome = Join-Path $env:USERPROFILE ".openinterpreter"
$standaloneRoot = Join-Path $interpreterHome "packages\standalone"

if (Test-Path -LiteralPath $binDir) {
    $binItem = Get-Item -LiteralPath $binDir -Force
    $binTarget = [string]$binItem.Target
    $isManagedJunction =
        ($binItem.Attributes -band [IO.FileAttributes]::ReparsePoint) -and
        $binTarget.StartsWith($standaloneRoot, [StringComparison]::OrdinalIgnoreCase)
    if (-not $isManagedJunction) {
        throw "Refusing to remove $binDir because it is not an Open Interpreter managed junction."
    }
    Remove-Item -LiteralPath $binDir -Recurse -Force
}
Remove-Item -LiteralPath $standaloneRoot -Recurse -Force -ErrorAction SilentlyContinue

卸载脚本刻意先校验 bin 目录确实是受管的 Junction，避免误删用户自建目录；若需要连用户数据一并清除，则需在备份后删除整个 %USERPROFILE%\.openinterpreter（不可撤销，且不影响密钥环或环境变量中的凭据）。

WSL：Linux 工具链项目的首选

如果你的项目已经围绕 Linux 工具链构建（bash 脚本、Makefile、Linux 沙箱预期等），直接在 WSL 发行版内使用与 macOS/Linux 相同的安装命令：

curl -fsSL https://www.openinterpreter.com/install | sh

该命令对应 scripts/install/install.sh，其职责与 Windows 版对仗：校验 OS/架构（x86_64 或 aarch64），解析并校验版本，下载压缩包并校验 SHA-256，将 interpreter（别名 i）及 codex-code-mode-host 以符号链接方式放进 ~/.local/bin，并依据 shell 类型（.bashrc/.zshrc/.profile 等）写入 PATH 导出块。它同样支持通过环境变量指定版本与安装目录（OPEN_INTERPRETER_RELEASE、OPEN_INTERPRETER_INSTALL_DIR 等）以及 --release VERSION 参数。安装后新开终端验证：

interpreter --version

注意：由于 WSL 中运行的是 Linux 二进制与 Linux 沙箱模型，docs/zh/sandbox.md 中「操作系统强制执行」一节明确将 WSL 与 Linux 归为同一行——使用 Bubblewrap、seccomp 及可用的相关内核沙箱；这意味着对需要严格 Linux 风格隔离的场景，WSL 能提供比原生 Windows 更接近 Linux 的强制语义。

路径与 Shell：保持风格一致

项目对路径与 Shell 的约定来自两个层面：

• 运行层面：原生 Windows 安装把 interpreter 放到 Windows 目录并通过 PowerShell 调用，天然遵循 Windows 路径分隔符与命令语法；WSL 安装则把可执行文件放入 Linux PATH。
• 会话层面：Open Interpreter 在会话内执行命令时使用活动 shell。原生 Windows 项目应始终使用 Windows 路径与 PowerShell 约定传参、引用文件；WSL 项目应使用 /home/... Linux 路径与 bash 工具。混用两种风格（例如在 PowerShell 会话里传入 Linux 路径）会导致命令无法按预期解析。

该约定同样影响沙箱路径判定：可写工作区根目录、--add-dir 附加目录等均按当前运行环境的路径体系解释。

Windows 沙箱说明：强制边界与平台差异

沙箱模式与批准策略

Open Interpreter 将本地命令安全控制拆成两套正交机制（详见 docs/zh/sandbox.md）：

• 沙箱模式决定技术边界；
• 批准策略决定代理何时暂停询问。

沙箱模式三档：

模式	行为
read-only	命令可检查允许的文件，但不能写入。
workspace-write	命令可在活动工作区根目录内写入；网络默认关闭（除非显式启用）。
danger-full-access	无本地沙箱边界，仅在有意信任的环境中使用。

批准策略三档：

策略	行为
untrusted	在可能更改状态的操作之前询问。
on-request	在沙盒内运行，升级权限前询问。
never	不询问，沙盒是唯一防护。

按官方推荐，拿不准时从 workspace-write + on-request 起步；审查不熟悉代码用 read-only + on-request。也可在 TUI 会话中用 /permissions 查看或动态调整，或用命令行参数做一次性覆盖：

interpreter --sandbox read-only "audit the auth flow"

原生 Windows 沙箱的强制细节差异

docs/zh/windows.md 明确指出：原生 Windows 沙箱的强制细节与 macOS 和 Linux 不同。结合仓库源码可以印证这一差异的具体来源：

• macOS 侧使用 Seatbelt 配置文件约束进程；
• Linux/WSL 侧使用 Bubblewrap + seccomp 等内核沙箱机制；
• 原生 Windows 则依赖 Windows 自身的 OS 原语。仓库中 codex-rs/windows-sandbox-rs 子 crate 即该沙箱的 Rust 实现，从源码结构看，其通过受限身份与令牌（identity.rs、token.rs）、ACL 文件/读取控制（acl.rs、workspace_acl.rs、deny_read_acl.rs）、能力裁剪（cap.rs）、网络过滤（wfp.rs、wfp_setup.rs，基于 Windows Filtering Platform）以及独立桌面（desktop.rs）、进程启动包装（wrapper.rs、spawn_prep.rs）等组合手段完成边界强制。

也就是说，Windows 原生沙箱的"能做什么、不能做什么"在 ACL、令牌/能力、WFP 网络层等处落地，而 Linux 侧则体现在 namespace/bubblewrap/seccomp 上——两者的失败模式与可强制粒度天然不同。因此文档给出明确建议：若需要 Linux 风格的沙箱行为，请使用 WSL。当请求的策略在当前平台无法被强制执行时，产品应关闭失败（fail closed），而不是静默地在无沙盒环境下运行（见 docs/zh/sandbox.md）。

受信任本地仓库的最小权限原则

对受信任的本地仓库，docs/zh/windows.md 给出的安全基线是：先使用默认权限，仅在任务确实需要时才放宽。这与 docs/zh/sandbox.md 中「受保护路径」的告诫一致——即使在可写根目录内，诸如 .git/ 与代理配置目录等敏感控制目录也应视为受保护，若代理需要改动它们应仔细审查。放宽到无边界模式（--yolo 或 --dangerously-bypass-approvals-and-sandbox）只应出现在一次性虚拟机或隔离容器等外部沙箱场景中，而不应作为日常本地工作流的默认配置。

常见问题与排障

• 提示 interpreter 不是可识别命令：多为当前终端未重启、PATH 尚未刷新；新开 PowerShell 窗口即可。若自定义了 OPEN_INTERPRETER_INSTALL_DIR，请确认该目录已被加入用户 PATH。
• 安装报错 "requires a 64-bit version of Windows"：安装器只支持 64 位系统（install.ps1）；32 位环境无法安装。
• 架构不支持：仅支持 x64（x86_64-pc-windows-msvc）与 ARM64（aarch64-pc-windows-msvc），其他架构会被拒绝。
• 需要 Linux 风格沙箱但不想放弃 Windows 体验：改用 WSL 安装路线，获得 Bubblewrap/seccomp 的 Linux 强制模型。
• 需要查阅更多平台能力：安装/更新/卸载细节见 docs/zh/install.md，沙箱与批准策略完整说明见 docs/zh/sandbox.md，会话级命令与常见首命令速查见 docs/zh/quickstart.md。

小结

在 Windows 上运行 Open Interpreter 的核心决策是：项目以 Windows 生态为主就选择原生 PowerShell 工作流（irm ... | iex 安装、Windows 路径、原生 Windows 沙箱）；项目以 Linux 工具链为主就选择 WSL 工作流（curl ... | sh 安装、Linux 路径、Bubblewrap/seccomp 沙箱）。两条路径都遵循「先默认权限、按需放宽」的安全基线，并注意原生 Windows 沙箱的强制细节与 macOS/Linux 存在本质差异——需要严格 Linux 风格隔离时，WSL 是更稳妥的选择。