[CRITICAL - Data Loss] Copilot agent bypasses WSL sandbox and deletes user home directory due to Windows/WSL quoting failure

[vitmantug]

Description

The Copilot agent caused catastrophic data loss (completely wiping the real WSL /home/user directory) while attempting to run what it thought was a safely sandboxed command.

The issue stems from a fatal interaction between how the Agent structures inline bash commands and how Windows/PowerShell passes arguments to wsl.exe. When the agent attempts to isolate destructive commands (like rm -rf "$HOME") using an inline string, the quoting fails during the transit between the Windows host and the WSL guest.

Steps to Reproduce

1. On a Windows 11 host with VS Code and WSL 2 enabled.
2. Engage the Copilot agent in a task that involves temporary WSL operations.
3. The agent attempts to sandbox a command using the following pattern:

   wsl bash -lc 'set -euo pipefail; export HOME=/tmp/repro_env; rm -rf "$HOME/test_dir"; mkdir -p "$HOME/test_dir2"'

4. The Failure: Observe that even though $HOME is exported to /tmp/repro_env in the same line, the rm -rf command targets the user's actual home directory (/home/username/test_dir).

Technical Analysis

The vulnerability is a Sandbox Escape via Quoting Corruption.

When a command wrapped in single quotes ('...') is passed from a Windows shell (like PowerShell or the VS Code terminal runner) to a native executable (wsl.exe), the Windows execution context often strips the outer single quotes and attempts to re-wrap arguments in double quotes for the CreateProcess Win32 API.

This process fails to escape internal double quotes (like those in "$HOME"). Consequently, the bash shell inside WSL receives a fragmented string where $HOME is evaluated against the pre-existing environment (the real home) before the inline export command can take effect or isolate the scope.

Impact

• Data Loss: Irreversible deletion of files in the WSL home directory.
• Security Risk: Deletion of sensitive configurations, SSH keys, and uncommitted source code.

Environment

• Copilot Chat Extension Version: 0.47.1
• VS Code Version: 1.119.1
• OS Version: Windows 11 (Build 10.0.26200.0)
• Feature: agent
• Selected model: GPT-5.4

Suggested Mitigation / Guardrail

Agents must be strictly prohibited from using inline shell execution (wsl bash -lc '...') for complex or destructive strings across the Windows-WSL boundary.
Safe Pattern: The agent should write the payload to a temporary .sh file on the Windows host and execute it via:

wsl bash /mnt/c/path/to/temp_script.sh

[vitmantug]

cc @meganrogge @roblourens

[dileepyavan]

@vitmantug Can you confirm if the repo is opened from WSL. For sandboxing to work using wsl2 in windows, please follow these steps: https://code.visualstudio.com/docs/remote/wsl#_getting-started

[vitmantug]

@dileepyavan

Thank you for looking into this.

To answer your question directly: No, the repo was not opened from WSL using the Remote - WSL extension. It was opened as a standard Windows workspace.

However, this specific context is exactly why this issue is a critical data loss bug and not a user error. Here is the breakdown:

1. The Workflow Context

I am working on a repository that synchronizes Copilot agents and skills across both Windows and WSL simultaneously. My PowerShell scripts (setup.ps1, sync-agents.ps1) and my git post-merge hook explicitly invoke wsl.exe from the Windows host to mirror the configuration inside the WSL environment. Therefore, opening the workspace in Windows is the intended workflow for this repository.

2. The Agent's Catastrophic Mistake

While I was working on these cross-platform scripts, the Copilot Agent (running in the Windows context) attempted to test a scenario in WSL by creating what it thought was a temporary sandbox.

It generated and executed this exact tool call via the terminal:

{
  "command": "wsl bash -lc 'set -euo pipefail; export HOME=/tmp/repro_agent_sync_2; rm -rf \"$HOME\"; mkdir -p \"$HOME/.copilot/agents\"; cp /mnt/c/FF/OTHERS/ai/agents/csharp-expert.agent.md \"$HOME/.copilot/agents/\"; printf local > \"$HOME/.copilot/agents/engineer-soul.md.agent.md\"; cd /mnt/c/FF/OTHERS/ai; bash -x ./scripts/setup.sh; echo ---; ls -l \"$HOME/.copilot/agents\"; echo ---; test -L \"$HOME/.copilot/agents/csharp-expert.agent.md\"; echo csharp_is_symlink=$?; test -f \"$HOME/.copilot/agents/engineer-soul.md.agent.md\"; echo engineer_is_file=$?'",
  "explanation": "Reproduce the POSIX agent sync migration scenario with shell tracing to inspect why a copied repo agent may not be replaced by a symlink",
  "goal": "Diagnose the remaining POSIX agent sync issue",
  "mode": "sync",
  "timeout": 120000
}

3. The Core Bug: Sandbox Escape via Quoting

The agent assumed that wrapping the command in single quotes ('...') would protect the $HOME variable from early evaluation, as it would in a pure POSIX environment.

However, because this was passed from a Windows shell to a native executable (wsl.exe), the Windows execution context stripped the outer single quotes and exposed the internal double quotes ("$HOME").

As a result, $HOME bypassed the inline export command, evaluated to my real WSL home directory (/home/vitorgoncalves), and the rm -rf command completely wiped my personal WSL files.

Conclusion

I understand that "sandboxing" might only be officially supported inside the Remote - WSL extension. But the bug here is that the Agent is generating destructive commands (rm -rf) wrapped in an inline wsl bash -c call, which is highly vulnerable to quoting corruption across the Win32/WSL boundary.

If cross-boundary execution isn't fully supported or safe, the Agent must have strict guardrails preventing it from using inline shell execution for destructive commands across this boundary. To prevent catastrophic data loss, it should be instructed to write the payload to a temporary .sh file on the Windows host and execute the script file instead.