Test suite fails on Windows: 131 pre-existing failures (path separators, MSYS path translation, file locking)

[lab1207]

What happened

What I did: cloned main clean (commit 924f7c2), ran bun install, then the test suites on Windows 11 with bun 1.3.14.

What I expected: the suites to pass, or fail only where documented.

What I got instead: a consistent set of failures that exist on main with no local changes:

• CLI suite: 3,035 pass / 29 fail (196 files)
• SDK suite: 512 pass / 102 fail (62 files)

They cluster into three families, all pointing at the same root causes: POSIX path assumptions, Git Bash / MSYS path translation, and file-locking semantics. I verified this against a clean main checkout — none of these involve local modifications. (Context: I hit this while verifying a feature PR and baseline-diffed both suites against main to confirm the failure sets are identical.)

Steps to reproduce

1. On Windows 11, clone the repo and check out `main` (reproduces on clean `924f7c2`)
2. `bun install`
3. `cd cli && bun test` → 29 failures
4. `cd sdk && bun test` → 102 failures
5. Note every failure involves POSIX-vs-Windows paths, MSYS path translation, or file locking (examples below)

Example failures (same shape across the families):

cli/src/commands/__tests__/export-conversation.test.ts
  Expected output to contain "/project/..." but got "\project\..."

sdk/src/__tests__/change-file.test.ts
  Expected "file": "src/file.ts" but got "src\file.ts"
  (and with cwd '/repo': received "C:\Program Files\Git\repo\src\file.ts"
   — Git Bash translated the POSIX path before the code saw it)

sdk/src/__tests__/code-search.test.ts
  Expected spawn cwd "/test/project" but got "C:\test\project"

cli/src/utils/__tests__/write-file-atomic.test.ts
  "concurrent writes to the same file do not tear" — Windows keeps the
  destination locked while a handle is open, so the rename-based swap fails

Where does this happen?

CLI (terminal client)

Operating system

Windows

Version

cli 1.0.0 (source build, main @ 924f7c2), bun 1.3.14, Git Bash (MSYS)

Model

No response

Logs or screenshots

Full failing-file list, both suites, reproducible on clean main:

CLI (29 fails in 6 files):
- cli/src/commands/__tests__/export-conversation.test.ts (2) — path separators
- cli/src/components/__tests__/sponsored-proposal-block.test.tsx (1) — checked-in frames render at wrong column widths
- cli/src/hooks/__tests__/use-path-tab-completion.test.ts (3) — relative path conversion
- cli/src/init/__tests__/init-direnv.test.ts (3) — symlink handling
- cli/src/utils/__tests__/write-file-atomic.test.ts (1) — file locking
- cli/src/__tests__/release/wrapper-safety.test.ts (3) — reads config from MSYS-translated paths

SDK (102 fails, same three root causes):
- apply-patch / change-file / get-files / project-path tests — "src\file.ts" vs "src/file.ts", "C:\repo" vs "/repo", Git Bash path translation
- code-search tests — spawn cwd "/test/project" vs "C:\test\project"
- turn-spend / usage tests — depend on a live/local endpoint, rate-limit flakiness
- home-directory boundary test — `startsWith` check fails on backslash separators

Sample error:
  error: expect(received).toEqual(expected)
  -  "file": "src/file.ts",
  +  "file": "src\file.ts",

Suggested directions:
1. Normalize through a single path-display helper (forward slashes for user-facing strings) instead of comparing raw path.join output.
2. For tests, either skip with an explicit @platform tag on Windows or normalize expected values with path.normalize — right now the failures are silent noise that hides real regressions for Windows contributors.
3. The writeFileAtomicAsync lock test may need a Windows-specific strategy (retry-on-EBUSY or copy+swap fallback).

Happy to help split these into smaller issues or send a PR for one family if maintainers say which fix direction they prefer.

Tested on: Windows 11, bun 1.3.14, Git Bash (MSYS), clean clone of main.