Test suite is not portable on Windows (path separators, path.resolve, platform-conditional snapshots, shell)

[zbl1998-sdjn]

Summary

Running the full test suite on Windows (with a correctly-configured Git Bash) produces a large number of failures that are all environment / cross-platform-portability issues, not product logic bugs. On a clean checkout I get:

Test Files  44 failed | 339 passed | 5 skipped (388)
     Tests  143 failed | 4830 passed | 42 skipped | 2 todo (5017)

The same tree is green on Linux CI. I've categorized every failure cluster below with file:line evidence so the maintainers can decide whether/how to support running the suite on Windows. I'm raising an issue first (per CONTRIBUTING) rather than sending a broad unsolicited PR, because several of these require an intent decision (e.g. should tool paths be native or normalized?).

Environment

• OS: Windows 10 Pro (x64)
• Node: v24.16.0, pnpm 10.33.0
• Shell: Git Bash, set via KIMI_SHELL_PATH
• Repro: pnpm install → pnpm test

Failure categories

1. Git Bash path detection (already being addressed)

Without KIMI_SHELL_PATH, ~205 tests abort with shell.git_bash_not_found because bash lives at …\Git\usr\bin\bash.exe while detection probed …\Git\mingw64\bin\bash.exe. This is already handled by #145 (packages/kaos/src/environment.ts) — listing it only for completeness.

2. Path separator / vs \ (cuts both ways → test-only)

• packages/agent-core/test/skill/scanner.test.ts:58 — scanner returns forward-slash paths (C:/Users/.../.kimi-code/skills); the test expects native \ via path.join + realpath.
• apps/kimi-code/test/scripts/native/paths.test.ts:52 — the opposite: nativeIntermediatesDir() returns native \ paths; the test hardcodes ${appRoot}/dist-native/intermediates with /.

Because the mismatch goes in both directions, this is test-portability noise rather than a single product bug — but it does mean tests bake in a separator convention.

3. path.resolve assumes a POSIX absolute input

• packages/migration-legacy/test/sessions/workdir-bucket.test.ts:33 hashes the raw literal '/Users/me/Developer/proj', but computeWorkdirBucket (packages/migration-legacy/src/sessions/workdir-bucket.ts:26) runs resolve() first (correctly, and intentionally — see the comment there). On POSIX resolve() is a no-op for that input; on Windows it re-anchors to C:\Users\me\Developer\proj, so the hashes diverge:

  expected 'wd_proj_76bfce3667dc'  (sha256 of the raw POSIX string)
  received 'wd_proj_043717ef0f63'  (sha256 of the resolved Windows path)
  

  The product function is self-consistent per platform; the test should derive its expected hash from resolve(input) (as the sibling referenceEncodeWorkDirKey / "byte-identical" block already does).

4. CRLF line endings (separate PR)

There is no .gitattributes, so with core.autocrlf=true the raw-text prompt .md files (loaded as model input, e.g. read.ts → import … from './read.md') check out as CRLF, inflating token/byte counts and breaking token-sensitive snapshots. I've opened a separate small PR adding .gitattributes (* text=auto eol=lf) for this piece: #224.

5. Platform-conditional tool descriptions make snapshots platform-dependent

• packages/agent-core/src/tools/builtin/file/glob.ts:103 appends a "Windows note" to the Glob tool description when this.kaos.pathClass() === 'win32'. Inline snapshots that capture tool descriptions (e.g. packages/agent-core/test/agent/compaction.test.ts) therefore differ depending on the resolved path class, so they fail on Windows.

6. Shell-flavor differences (cygwin vs msys2)

• Several packages/kaos/test/** (e.g. e2e/exec-edge-cases.test.ts, e2e/concurrent-operations.test.ts, local.test.ts) assume a specific Git-Bash/MSYS2 behavior; on a cygwin-based bash (x86_64-pc-cygwin) some path translation / process behavior differs.

What I'd like to align on

1. Is running pnpm test on Windows a supported/desired workflow? If yes, I'm happy to send focused PRs per category (the test-only ones in fix: correct Anthropic provider inputOther token counting #2/fix: remove double path resolution in SSH readLines #3 are small and low-risk).
2. For fix: correct Anthropic provider inputOther token counting #2/fix: clear reverseRpcDisposers array after disposing handlers #5: should tool-facing paths and descriptions be normalized to be platform-stable in snapshots, or should the snapshots/tests be made platform-aware?

I can provide the full pnpm test log on request.

[zbl1998-sdjn]

顺着这个 issue 再补一条:光把测试改可移植还不够,得让 CI 真的在 Windows 上跑一次,否则修好了也会慢慢退化回去。

现状有个挺明显的反差:

• .github/workflows/ci.yml 里 build / test / lint / typecheck 四个 job 全是 runs-on: ubuntu-latest;
• 但 .github/workflows/_native-build.yml 实打实地出 windows-2025-vs2026 和 windows-11-arm 两个原生包。

也就是给 Windows 用户发二进制,却从没在 Windows 上跑过一次测试。#122、#145、#176 还有上面列的那一堆,基本都是这么漏出去的。

所以这个 issue 的完整解法我觉得是两步:(1)把测试改可移植(上面那些类别);(2)给 CI 加一个 Windows job 把它锁死、防回归。 下面主要说第 2 步的落地节奏,免得"一上来 143 个红"把大家吓退。

落地节奏(分阶段,不阻塞 PR)

1. 先加一个非阻塞的 Windows test job(continue-on-error: true),内容跟现有 test 一样,只是 runs-on 换成 Windows。这样每个 PR 都能看见 Windows 的真实情况,但不卡合并。
2. 随着上面可移植性问题逐项修好,这条逐步转绿。
3. 全绿后去掉 continue-on-error,升级成必需检查——以后谁再写出"只在 POSIX 成立"的断言,CI 直接拦。

几个落地细节(我本地把 5000 个测试跑了一遍,踩过的坑)

• Git Bash:agent-core 要定位 bash.exe。GitHub 的 Windows runner 预装了 Git for Windows,bash 在 C:\Program Files\Git\bin\bash.exe——正好在现在的探测候选里(packages/kaos/src/environment.ts),所以 CI 上大概率不用额外设置;真不行就给 job 加个 KIMI_SHELL_PATH。(我自己机器上 fail 是因为 git 装在非标准路径,那是 fix(agent-core): search usr\bin\bash.exe paths for Git Bash on Windows #145 在修的另一回事。)
• 换行:配套 chore: normalize line endings to LF via .gitattributes #224 的 .gitattributes(强制 LF)能直接消掉一批 token 计数 / 快照里的 CRLF 差异。
• 大头:剩下的就是上面 ② 路径分隔符、③ path.resolve 把 POSIX 绝对路径当输入、⑤ 平台条件化的快照(比如 Glob 描述里的 "Windows note")——这些是"改测试 / 让快照平台无关"的实活,也是这个 issue 的核心工作量。

大概长这样(在 ci.yml 里加一个 job)

  test-windows:
    runs-on: windows-latest        # 也可对齐发布目标 windows-2025
    continue-on-error: true        # 阶段一:非阻塞,先把真实情况暴露出来
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v6
      - uses: actions/setup-node@v6
        with:
          node-version-file: .nvmrc
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm run test

(lint / typecheck 基本跟平台无关,顺手也能加;真正会出问题、也最有价值的是 test。)

方向要是 OK,可移植性修复 + 这个 Windows job 我都可以来做,拆成几个小 PR、都关联这个 issue。先听听维护者的意见——尤其"Windows 要不要做成必需检查"这个尺度想定到哪一步。