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

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 #2/#3 are small and low-risk).
2. For #2/#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.

Start by running pnpm test on Windows and compare the failures with the categories in the issue. Read packages/agent-core/test/skill/scanner.test.ts, packages/migration-legacy/test/sessions/workdir-bucket.test.ts, packages/agent-core/src/tools/builtin/file/glob.ts, and the cited packages/kaos tests. Done means agreeing on Windows support and whether each affected test or snapshot should be platform-stable or platform-aware, then separating focused fixes from the already-addressed and separate-PR items.