Repository navigation
[bug] StepPage 插件在 Windows 上无法自动安装，也没有原生入口 #219
Description
内置 StepPage 插件在 Windows 上无法自动安装，也没有原生入口。这是桌面端接入时定位到的，按维护者建议单独开一帖。
现象
Step-Code 自带的 steppage 预安装在 Windows 上不生效，而插件声明要求裸命令 steppage-mcp
可解析，MCP 因此连不上。
定位（当前 main 519e4de）
packages/coding-agent/src/step/plugins.ts 的 provisionBuiltinPlugin()，第 583 行：
if (provision.command !== "steppage-mcp" || process.platform === "win32") {
return undefined;
}
win32 直接跳过。provisionInstallCommand()（第 578 行）只提供一条安装命令，且它是 Unix 管道：
return `curl -fsSL ${shellQuote(resolveProvisionInstallerUrl(env))} | sh`;
#160 加的预安装走的是同一个 provisionBuiltinPlugin()，其行为说明里写明了 skipped on Windows。
本机实测佐证
- 本机 Windows PATH 38 个条目中没有 steppage，~/.local/bin 也不在 PATH 上
- Get-Command steppage-mcp 解析不到
- ~/.steppage-mcp 下只有 bin/steppage-mcp.mjs，没有 .cmd / .ps1 / .exe
- 直接对该 bundle 发 MCP initialize 能正常返回，说明 bundle 本身在 Windows 上是健康的， 缺的只是安装与 PATH 注册
影响
上游 #190、#151、#137 都指向 Windows 侧问题，说明这个平台的用户在增长；#155 有四位用户追问桌面版。桌面端目前靠自己的注册逻辑用绝对路径绕过 provision 机制补上这个平台，但每个下游都要各自补一遍。
需要上游判断的
是否为 win32 提供一条原生安装途径（例如随 Node 发行版分发的 npm 包装，或安装脚本的PowerShell 版本），以及 provisionBuiltinPlugin 的 win32 分支是否保留。
我们可以在 Windows 上提供实测协助，包括验证任何候选方案。
Activity
1239636986-create commentedon Oct 10, 2026
我们已对 StepPage 插件的安装体验进行了优化，现已支持启动时自动预安装 StepPage 插件，无需再手动执行
/plugin install steppage命令。相关改动已合并至 PR #160，感谢你的反馈与支持！fix(steppage): provision Windows and harden session cleanup (#5)
li-xiu-qi commentedon Oct 24, 2026
I reproduced this on native Windows against current main with an isolated HOME. The
step mcp preparepath still returns the macOS/Linux-only error.@Hylouis233, do you plan to bring your fork’s Windows provisioning change upstream? I can help validate it on native Windows. If you are not continuing with it, I would like to coordinate a focused upstream PR using the published bundle and a
.cmdwrapper, rather than duplicate your work.Hylouis233 commentedon Oct 24, 2026
Thanks for the native Windows reproduction and the offer to validate.
We plan to bring the fork’s Windows StepPage provisioning upstream (published bundle +
steppage-mcp.cmdunder~/.local/bin, probed viacmd /c; no PATH write). Native Windows acceptance from your side would be very welcome once the PR is up — we’ll link it here so we don’t duplicate work.Hylouis233 commentedon Oct 24, 2026
Compare (pending formal PR — waiting on GitHub create confirmation): https://github.com/stepfun-ai/Step-Code/compare/main...Hylouis233:Step-Code:fix/219-steppage-windows-provisioning?expand=1
Head:
9ea890477462bc7c8e22fbad912de9f394d7961fonfix/219-steppage-windows-provisioning(2 commits, 4 files).@li-xiu-qi — if you can validate on native Windows (isolated HOME,
step mcp prepare), that would be very helpful. Unit tests pass; we have not run a real Windows install yet. I will replace this with the PR link once it is opened.Hylouis233 commentedon Oct 25, 2026
Update on the Windows StepPage provisioning fix:
Branch is ready on the fork (2 commits, 4 files, unit coverage green):
Hylouis233:fix/219-steppage-windows-provisioning(9ea890477)GitHub reports these branches can merge cleanly, but this repo restricts opening PRs to collaborators, so I cannot create the upstream PR from the fork myself.
Could a maintainer please either:
main, orand @li-xiu-qi — if you can validate on native Windows (
step mcp prepareafter this branch), that would be a big help.Happy to adjust the branch if review needs changes.
li-xiu-qi commentedon Oct 25, 2026
@Hylouis233, I tested your original 9ea8904 without local changes. Windows tests passed 10/10; full build and Bun standalone
step-bin.exebuild succeeded. On native Windows, with an isolatedHOMEcontaining spaces, the original standalone binary completedmcp prepare. The wrapper’s--versionreturned 1.0.0, MCP initialize returnedsteppage0.0.1, andtools/listreturned 13 tools. The main Windows implementation and standalone-binary path work and need no rewrite.Two hardening items surfaced. The wrapper invokes bare
node. Launching from a directory containing a maliciousnode.cmdprintedNODE_HIJACKED_FROM_CWD, proving cwd-shim hijacking. Resolvenode.exefrom absolute PATH entries and reuse that absolute path for version checking and the wrapper. Do not useprocess.execPath; in the standalone binary it points to Step itself.Passwords/tokens in mirror URLs can appear in final error text on Windows and POSIX error paths. Redact the complete final error text consistently. The POSIX issue already exists on unmodified main; this branch did not introduce it.
Overall, the original implementation is functionally complete; these are localized security hardening items. This is validation feedback only; I have not opened a separate issue or PR. I hope this helps you and the maintainers advance the existing branch.
Hylouis233 commentedon Oct 25, 2026
@li-xiu-qi thank you for the native Windows verification (10/10 on
9ea890477) and for the two hardening suggestions.Pushed follow-up on
Hylouis233:fix/219-steppage-windows-provisioning→ headd77b1efe74036a124beabed22e0c4224805c3792(ff on top of9ea890477, no rebase):node.exevia PATH absolute path for version checks and the wrapper (do not useprocess.execPath)Unit tests: windows 15/15 (related suite 102/102). Native Windows re-check of this tip welcome if you have a moment.
Compare (ready for a formal PR — fork cannot open one into this repo without collaborator access):
https://github.com/stepfun-ai/Step-Code/compare/main...Hylouis233:Step-Code:fix/219-steppage-windows-provisioning?expand=1
Maintainers: please open/accept a PR from that head when convenient, or grant collaborator so we can open it ourselves. Happy to adjust further.
li-xiu-qi commentedon Oct 26, 2026
@Hylouis233 following up on your last comment: since fork PRs cannot be opened into this repo, I opened one from your branch so the work can move forward: #305 (head
e37e8d44, ready, CI green).878ff8f,9ea8904,d77b1ef) are preserved in the branch history with you as author. On top ofd77b1efeI added one hardening commit:node.exe/cmd.exe/curl.exeare resolved only from absolute PATH entries, the wrapper health check probes the wrapper by basename from its own directory via the absolutecmd.exe, mirror URLs are redacted in raw and shell-escaped form, and the Windows ENOENT message now points tostep mcp prepare.Fixes #304. Maintainers may also want to link it to this issue, since it covers the original Windows provisioning path described here.Validation of the final tip on native Windows: the feature tests fail 5/34 on the unpatched baseline and pass 34/34 with the change, the full workspace comparison shows no candidate-only failures, and
pnpm run checkpasses.mcp preparesucceeds in an isolated HOME containing spaces,&and%PATH%, withnode.cmd,cmd.exeandcurl.exeshims planted in the launch directory; the wrapper reports 1.0.0, MCP initialize returns steppage 0.0.1, and tools/list returns 13 tools.Earlier I wrote that I had not opened a PR; that changed once it was clear the fork could not open one and the remaining items needed a tracked home. Happy to adjust the branch if you or the maintainers want changes, and a native Windows re-check of
e37e8d44from your side is welcome.Hylouis233 commentedon Oct 26, 2026
@li-xiu-qi thank you for opening #305 from our branch (
e37e8d44, our three commits retained + your hardening). Please have maintainers associate this issue when reviewing that PR.Hylouis233 commentedon Oct 26, 2026
Local re-check of #305 (
e37e8d44): our three commits retained; contributor hardening LGTM; mocked-win32 suites 18/18 + related 106/106. No further code from us — waiting on maintainer review (please associate this issue).