[BUG] Windows: polling a background task's output path with backslashes via grep silently hangs forever (no error)

Description

On Windows, the Bash tool (Git Bash) reports background-task output file paths in Windows backslash form, e.g.:

Command running in background with ID: bz84ce05q. Output is being written to: C:\Users\me\AppData\Local\Temp\claude\<project>\<session>\tasks\bz84ce05q.output.

The tool's own documented polling idiom for waiting on a background task is:

until grep -q "Ready" "C:\Users\me\AppData\Local\Temp\claude\<project>\<session>\tasks\bz84ce05q.output"; do sleep 0.5; done

Git Bash interprets the backslashes in that path as escape sequences rather than path separators, so grep (and similarly test -f, cat, etc.) silently fails to open/match the file. Critically, this does not error — grep -q just returns non-zero forever, so the until loop spins indefinitely even after the file exists and already contains the target line.

The result is indistinguishable from a genuine hang: the background process has already finished successfully, the target output is already in the file, but the polling loop never exits and no error surfaces to explain why.

Steps to reproduce

1. On Windows, start a background Bash command, e.g. npm run dev, via the harness's run_in_background.
2. Note the reported output file path is in C:\Users\...\tasks\<id>.output form.
3. Poll for readiness the way the tool's own guidance suggests:

``bash
until grep -q "Local:" "C:\Users\...\tasks\<id>.output"; do sleep 0.5; done
``

1. Observe the loop never exits, even once the target line is already present in the file (verified via Read tool or cat on the equivalent POSIX-style path /c/Users/.../tasks/<id>.output, which works fine).

Expected behavior

Either:

• The reported background-task output path should be given in a form that Git Bash can consume directly (POSIX-style /c/Users/...), or
• grep/test/similar should fail loudly (non-zero exit distinguishable from "not yet ready") rather than silently never matching, or
• Tool guidance/documentation should explicitly warn against combining Windows-style paths with Bash-tool commands, and point at the Read tool as the safe alternative for checking these files.

Related issues

This is the same root cause as several other reported (closed as not-planned/stale) issues about Windows backslash paths being fed into Git-Bash-based tooling, but manifests differently — as a silent infinite hang rather than a loud failure, which makes it harder to diagnose:

• #21878 — Hook scripts fail on Windows: backslash paths misinterpreted by Git Bash
• #46783 — Windows: permission prompt generates backslash allow-rules that never match forward-slash Bash commands
• #30736 - allowedTools glob patterns never match Windows backslash paths

Environment

• OS: Windows 11
• Shell: Git Bash (Bash tool)