Windows: build fails without crossterm, and every Edit/Write prompts even in bypassPermissions

[scp3500]

Environment

Windows 11 (10.0.26200.7171), rustc 1.93.1 / x86_64-pc-windows-msvc, baseline 747c21c.

Two Windows-only defects. The first blocks the build, the second makes bypassPermissions useless
for every edit once it does build.

---

1. cargo build --release fails: crossterm is used but never declared

error[E0433]: failed to resolve: use of unresolved module or unlinked crate `crossterm`
   --> src\utils\asciicast.rs:157:31
157 |     if let Ok((cols, rows)) = crossterm::terminal::size() {

That call is in the #[cfg(not(unix))] arm of get_terminal_size(), so Unix never compiles it and
nothing points at a missing dependency.

Fix: crossterm = "0.29" in Cargo.toml (iocraft already uses 0.29.0, so no new crates).

---

2. Every Edit/Write prompts, even in bypassPermissions

std::fs::canonicalize() returns verbatim paths on Windows (\\?\E:\dir\file).
resolve_deepest_existing_ancestor (src/utils/fs_operations.rs:156) puts that form into the
permission-check candidate list, and the path safety check then reads it as a suspicious
user-supplied path — has_suspicious_windows_path_pattern (filesystem.rs:463) matches the leading
\\?\ and the drive colon now sitting past index 2, and is_dangerous_file_path_to_auto_edit
(filesystem.rs:513) matches the leading \\.

That produces a SafetyCheck ask, which is bypass-immune on purpose
(tool_permission_ask_is_bypass_immune, permissions.rs:2411), so it survives every mode.

Repro:

mkdir cc-repro && cd cc-repro && echo foo > hello.txt
cometix -p "Replace foo with bar in hello.txt using the Edit tool."

[DEBUG] Reading through symlink: E:\cc-repro\hello.txt -> \\?\E:\cc-repro\hello.txt
[DEBUG] Aborting: tool=Edit
Error: Request aborted

Interactively it is the normal edit-permission dialog, on every single edit, with
⏵⏵ bypass permissions shown.

Fix: strip the verbatim prefix where canonicalization introduces it — a small
strip_verbatim_prefix helper in fs_operations.rs applied to the canonicalize() results in
resolve_deepest_existing_ancestor, plus the same normalization in
check_path_safety_for_auto_edit (also covers the safe_resolve_path entry point,
path_validation.rs:419).

Local patch verified: same command now exits 0 and rewrites the file, no Aborting line. I can send
it as a PR if you prefer.

[Haleclipse]

Both halves of this report are now addressed on master — thank you for the precise diagnosis on each.

crossterm build failure: fixed a while back in d7f123e (crossterm is now declared for cfg(not(unix)) targets; cargo check --target x86_64-pc-windows-gnu passes).

bypassPermissions prompting on every Edit/Write: root cause confirmed exactly as you suspected. std::fs::canonicalize returns extended-length (\\?\E:\...) paths on Windows while Node's fs.realpathSync never does, so safeResolvePath's resolved != input check held for every existing file — everything looked like a symlink, the verbatim spelling then tripped the suspicious-Windows-path patterns (drive colon past index 2, plus the \\?\ prefix itself), and the resulting SafetyCheck ask is bypass-exempt by design.

Rather than patching the two call sites, 90f3a71 rebuilds the seam your report pointed at: filesystem access now goes through an injectable FsOperations owner whose realpath_sync implements Node's semantics end to end — lexical resolve first, then canonicalize, then the Win32 spelling conversion (\\?\C:\x → C:\x, \\?\UNC\srv\share → \\srv\share), then NFC. safeResolvePath rides on it, so the fabricated symlink/SafetyCheck chain is gone at the source.

Since this end-to-end behavior can only be truly verified on Windows, could you re-run your repro against current master? A handful of peripheral call sites still use raw canonicalize outside the permission chain and are being swept separately, but the chain your repro exercises should be clean. I'll close this once you confirm.

[scp3500]

Both are genuinely fixed — re-verified on Windows 11 / x86_64-pc-windows-msvc / 83bc048.

crossterm: cargo check --target x86_64-pc-windows-msvc and cargo build --release both pass. The fix is in d7f123e, but that commit's message is about ICU4X and never mentions crossterm — you need git log -S'crossterm' -- Cargo.toml to find it. Side note: the release binary built from the pre-fix tree wouldn't even start here (icuuc77.dll missing); that's gone now too.

Permission prompts: repro passes — exit code 0, hello.txt goes foo → bar, and neither Reading through symlink nor Aborting: tool=Edit shows up any more. I drove the tool call from a local mock of the Messages API because my real endpoint kept returning 429. The chain is definitely exercised: file_read.rs:92 goes through safe_resolve_path on every read, and that debug line only prints when is_symlink is true — which on the pre-fix code was true for every existing file.

But that fix left a test failing:

cargo test --lib safe_resolve_path_matches_official_nfc_realpath → FAILED
  left:  "C:\...\Temp\realpath-nfc-<uuid>\café"
  right: "\\?\C:\...\Temp\realpath-nfc-<uuid>\café"

The code is right, the test is stale: expected is computed straight from canonicalize() (tests.rs:129), which carries the \\?\ prefix on Windows, while the new implementation strips exactly that prefix — so it ends up comparing the new spelling against the old one. It must have passed before 90f3a71. Its sibling safe_resolve_path_matches_official_literal_path_spelling is #[cfg(unix)] and this one isn't, but it only fails on Windows, so Linux CI stays green.

Either build expected from the stripped spelling, or #[cfg(unix)]-gate it too — the Windows spelling is already covered by windows_realpath_matches_official_win32_spelling_without_weakening_inputs, which passes here.

Nothing else to report — good to close.