Skip to content

fix(desktop): stabilize Windows remote access setup - #4778

Merged
M4n5ter merged 2 commits into
mainfrom
diagnose/windows-local-remote-access-ebusy
Sep 4, 2026
Merged

fix(desktop): stabilize Windows remote access setup#4778
M4n5ter merged 2 commits into
mainfrom
diagnose/windows-local-remote-access-ebusy

Conversation

@M4n5ter

@M4n5ter M4n5ter commented Sep 4, 2026

Copy link
Copy Markdown
Member
English

Summary

Stabilize Windows Local Runtime Host remote-access setup at the failure boundaries reproduced on a real Windows checkout:

  • run deferred package cleanup outside the Desktop-owned scratch directory, so its helper cannot keep that directory locked;
  • make scratch cleanup best-effort, preserving the setup operator's primary framed success or error;
  • project the native Task Scheduler launcher into the deployment root, keeping <Command> below Task Scheduler's path limit while retaining exact-package verification and automatic convergence for existing deployments;
  • make projected launchers immutable and content-addressed, so reconciliation never tries to overwrite the executable that a running scheduled task has locked.

Scheduled tasks still execute the native launcher directly. No visible cmd.exe/PowerShell trampoline or shell-quoting authority is introduced.

Root cause

The reported EBUSY was secondary: a detached cleanup helper inherited the setup scratch directory as its current working directory, while the Desktop's finally cleanup replaced the setup operator's framed result with the directory-removal error. Once that masking was removed, the lifecycle failure was 0x80041318: the versioned launcher path was 301 characters and Task Scheduler rejected it in <Command>. A mutable projected singleton would then fail during a later package change because Windows locks the running executable; content-addressed projection removes that overwrite boundary.

Verification

  • npx biome check on all changed files
  • Desktop main-process build and focused local-operator suite: 6/6 passed on Linux and Windows
  • CLI build and focused setup suite: 7/7 passed on Linux
  • New launcher-projection test passed on native Windows; two unrelated existing symlink tests require Windows Developer Mode
  • CLI complete compiled suite on Linux: 795 tests, 792 passed, 3 skipped, 0 failed
  • Real Windows recovery from the reported setupPending state completed as managed; Remote access enabled and connection-code creation succeeded
  • With the legacy launcher still owned by a running scheduled task, convergence created and verified the immutable content-addressed launcher without overwriting the locked executable
  • Setup scratch cleanup left no EBUSY; the managed Host remained running after Desktop exited

AI use

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex diagnosed the Windows failure chain, implemented the bounded fix, reviewed it, and performed Linux and native Windows verification.

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck, and affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No
中文

摘要

修复在真实 Windows checkout 中复现的本机 Runtime Host 远程访问安装故障边界:

  • 延迟包清理进程不再继承 Desktop 的安装临时目录,避免 helper 自己锁住该目录;
  • 临时目录清理降为 best-effort,不再覆盖 setup operator 的主要 framed 成功或错误结果;
  • 将 Task Scheduler 的原生 launcher 投影到 deployment root,绕开其 <Command> 路径长度限制,同时保留 exact-package 校验并让既有部署自动收敛;
  • 投影后的 launcher 改为不可变的内容寻址文件,reconciliation 不再覆写正在被计划任务锁定的可执行文件。

计划任务仍直接执行原生 launcher,不引入可见的 cmd.exe/PowerShell 中转窗口或 shell quoting authority。

根因

日志中的 EBUSY 是次生错误:延迟清理 helper 继承了 setup 临时目录作为 cwd,Desktop 的 finally 清理又用目录删除错误覆盖了 operator 的 framed 结果。去掉错误覆盖后,真正的 lifecycle 故障是 0x80041318:版本目录内的 launcher 路径长达 301 个字符,Task Scheduler 在 <Command> 处拒绝该路径。若投影目标仍是可变单例,后续换包又会因 Windows 锁定正在运行的 executable 而失败;内容寻址投影从机制上删除了这个覆写边界。

验证

  • 所有变更文件通过 npx biome check
  • Desktop main-process 构建及聚焦 local-operator 测试:Linux、Windows 均 6/6 通过
  • CLI 构建及聚焦 setup 测试:Linux 7/7 通过
  • 新增 launcher projection 测试在原生 Windows 通过;另两项无关的既有 symlink 测试需要开启 Windows Developer Mode
  • Linux CLI 完整编译后测试:795 项,792 通过、3 跳过、0 失败
  • Windows 从报告中的 setupPending 状态真实恢复为 managed;远程访问成功开启并生成连接码
  • 旧 launcher 仍被运行中的计划任务占用时,convergence 成功创建并验证不可变的内容寻址 launcher,没有覆写被锁文件
  • setup 临时目录清理不再出现 EBUSY;Desktop 退出后 managed Host 仍保持运行

AI 使用

  • 没有生成式工具作出实质贡献
  • 生成式工具作出了实质贡献

工具与范围:OpenAI Codex 排查 Windows 故障链、实现并审查修复,并完成 Linux 与原生 Windows 验证。

检查清单

  • 测试覆盖该变更且在修复前失败
  • lint、format、typecheck 和受影响测试均在本地通过

此 PR 是否改变行为?

  • 是——已在摘要中说明

@M4n5ter M4n5ter self-assigned this Sep 4, 2026
@github-actions github-actions Bot added the effort/M Under 500 readable lines label Sep 4, 2026
@M4n5ter
M4n5ter marked this pull request as ready for review September 4, 2026 11:37
@M4n5ter
M4n5ter force-pushed the diagnose/windows-local-remote-access-ebusy branch from 9aaaef1 to af1b6ad Compare September 4, 2026 12:46

@jackwener jackwener left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved at exact head af1b6ad5f15e5292ae8892bf31a704fccf8e69ee at the explicit direction of M4n5ter. No technical review was performed as part of this action; M4n5ter requested the approval and accepts responsibility for subsequent handling.


Review notice: This approval was submitted by an automated review agent operated by jackwener and is published at the direction of M4n5ter, who requested this action and is the human accountable for it.

@M4n5ter
M4n5ter force-pushed the diagnose/windows-local-remote-access-ebusy branch from af1b6ad to 461cc99 Compare September 4, 2026 13:05
@M4n5ter
M4n5ter merged commit 80319f7 into main Sep 4, 2026
12 checks passed
@M4n5ter
M4n5ter deleted the diagnose/windows-local-remote-access-ebusy branch September 4, 2026 13:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/M Under 500 readable lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants