VSCode extension wraps Bash commands with cd, bypassing user's allowed commands

Description

When running inside the VSCode extension, Claude Code wraps every Bash tool call with cd "$current_workspace_directory" && <actual_command>. This causes commands that are explicitly listed in ~/.claude/settings.json permissions.allow to not be auto-approved, because the permission system matches the full compound command string — not the individual commands in the chain.

Steps to reproduce

1. Add allowed commands in ~/.claude/settings.json:

``json
{
"permissions": {
"allow": [
"Bash(cd*)",
"Bash(git log*)",
"Bash(git status*)",
"Bash(git diff*)"
]
}
}
``

1. Open a project in VSCode with the Claude Code extension
2. Ask Claude to run git log

Expected behavior

The command should be auto-approved since git log matches Bash(git log*) (and the cd prefix matches Bash(cd*)).

Actual behavior

The user is prompted for approval because the actual command executed is:

cd "/c/Users/me/my-project" && git log --oneline -20

This compound command doesn't match any single allowlist entry. Even though Bash(cd*) is in the allowlist (which should match the full string starting with cd), the permission system still prompts — possibly due to security restrictions on &&-chained commands.

Impact

This is a significant UX issue: users who carefully configure their allowlist to avoid repeated prompts are still prompted on nearly every command because the cd prefix is injected by Claude Code itself, not by the user or the AI.

Related issues

• #20085 — Permission system treats command chains as single patterns instead of validating individual commands
• #28183 — Compound commands of individually-allowed safe commands prompt with incorrect safety reason
• #32985 — Allow configuring auto-approval for cd+git compound commands

Environment

• Claude Code VSCode extension
• Windows 11
• Shell: bash

Suggestion

Either:

1. Validate each command in a chain independently against the allowlist (as suggested in #20085)
2. Don't prepend cd "$workspace" when the working directory is already correct
3. Set the working directory via cwd on the subprocess rather than injecting a shell cd command