Parallel Bash tool calls don't preserve working directory from sequential context

Description

When Claude fires two Bash tool calls in parallel (in a single message), the execution order is not guaranteed. This causes issues when one command relies on the current working directory set by a previous command, and the other uses an explicit cd.

Steps to Reproduce

1. Claude is working in /project/dashboard/ (previous command ran there)
2. Claude sends two parallel Bash calls:

• Call A: pnpm build (no cd, relying on current directory being dashboard/)
• Call B: cd /project/admin && pnpm build

1. Call B may execute first, changing the working directory
2. Call A then runs in the wrong directory

Expected Behavior

Either:

• Parallel Bash calls should each inherit the working directory from the last completed command before the parallel batch, independent of each other (i.e., each gets its own shell context)
• Or the documentation/system prompt should explicitly warn that parallel Bash calls don't share or preserve working directory state

Current Behavior

The working directory state leaks between parallel calls depending on execution order, leading to commands running in unintended directories.

Workaround

Always use explicit cd /full/path && prefix in every Bash call, even when the working directory is believed to be correct. This makes each call self-contained and order-independent.

Impact

This is a frequent source of errors when working in monorepos with multiple project directories. The user has to repeatedly reject tool calls that target the wrong directory.