[harness] Parallel Bash calls in one response share the shell's working directory; a cd in one call breaks a sibling's relative paths

Finding. When the model issues several Bash tool calls in ONE response (the documented way to run independent commands in parallel), the calls share one shell state for the working directory: a cd <dir> && ... inside one call moved the working directory for a sibling call in the same batch, and that sibling's relative paths then failed with "No such file or directory" although the paths were correct from the project root. The harness's own note after the batch ("Shell cwd was reset to <root>") shows it noticed the drift only afterwards. Nothing in the tool description says the batch shares a cwd; "Working directory persists between calls" reads as a per-sequence guarantee, not a within-batch hazard.

Evidence. 2026-09-28: three Bash calls in one response; call 2 ran cd <repo>/reports/<subdir> && ...; call 3 ran cd <repo> && grep -n ... <existing file> and reported "No such file or directory" for two existing files; the same grep run alone one turn later succeeded. The environment update after the batch reported the primary working directory as the subdirectory.

Minimal reproduction. In one response: call A = cd subdir && ls; call B = ls relative/path/that/exists/from/root. B fails intermittently depending on scheduling.

Ask. (1) Give each Bash call in a parallel batch its own cwd (start every call at the session's primary working directory unless the call itself changes it). (2) Or state the shared-state hazard in the tool description and reset the cwd BEFORE the sibling calls run, not after. (3) Absolute paths are the workaround the model adopted; the harness could warn when a batched call contains a cd.

Environment: Claude Code desktop app (Windows 11), the Bash tool (Git Bash), version 2.1.281, Fable 5.1 as the lead session.