Dangerous-rm approval dialog displays a target resolved against the session cwd, not the cd target

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When a Bash command begins with cd <dir> and the dangerous-rm checker declines to honor that cd — for example because the command also contains a ; — the approval dialog still prints an absolute path, but one resolved against the session's working directory rather than against the cd target. The path the human is asked to approve is not the path the command would remove.

This is sharpest with git worktrees, where sibling checkouts differ only by a suffix: the dialog names the main checkout while the command targets the worktree.

Reproduction

Claude Code 2.1.272, Linux.

1. Create sibling checkouts, e.g. git worktree add ../repo-wt, so that /repo and /repo-wt both exist. Put a file in tmp/probe/ in each.
2. Start Claude Code with cwd /repo, permission mode bypassPermissions.
3. Have it run exactly this command:

cd /repo-wt && rm -f tmp/probe/* ; ls tmp

Actual — the approval dialog reads:

Dangerous rm operation on statically-unresolvable target: /repo/tmp/probe/*

Expected — either /repo-wt/tmp/probe/*, or the operand as written plus a note that the cd could not be statically resolved. Never a cwd-joined absolute path presented as though it were the target.

The ; matters: it is what makes the checker decline to honor the leading cd. The same command with the ; ls tmp removed is handled correctly.

What Should Happen?

The dialog's only function is to let a human verify which files are about to be removed. Here it names a different directory than the one that would be affected, so the approve/refuse decision is made on false information — a person could approve believing a scratch worktree is being cleaned while reading the path of their main checkout, or refuse a command that was in fact safe.

If the cd cannot be resolved, that is worth saying out loud in the dialog rather than papering over it with a path computed from a directory the command explicitly left.

Note on scope

This is about the content of the dialog, not about whether it should appear at all. #75588 argued the prompt should not fire in bypass mode and was closed as not planned. This report grants that the prompt is correct to fire, and reports only that the path it displays is wrong.