This was originally reported at, microsoft/vscode#102628, however I believe that the issue at play is in the scripts used here, not in VSCode.

Observed problem

When running VSCode's Remote WSL extension with this script in place on the most recent Windows Insider build (20175.1000), the terminal fails to start. It flashes the following errors briefly before closing.

xargs: unmatched double quote; By default quotes are special to xargs unless you use the -0 option

Usage: login [-p] name
       login [-p] [-h host] [-f name]
       login [-p] [-r host]

Underlying problems

The output above points to two separate issues:

1. xargs is choking because of bad quoting somewhere, and
2. the login command is being run with arguments that it doesn't expect.

Xargs issue

The xargs error above comes from the usage of the xargs command at line 47 of enter-systemd-namespace.

When the WSL Remote extension connects, it creates/modifies ~/.systemd-env. The line below is from that file. When I delete only this line and run the command manually, the xargs error goes away.

SUDO_COMMAND="/bin/bash -c set -a; [ -f \"\$HOME/.systemd-env\" ] && source \"\$HOME/.systemd-env\"; set +a; exec bash -c \\'/home/myuser/.vscode-server/bin/91899dcef7b8110878ea59626991a18c8a6a1b3e/node\\'\\ -p\\ \\'\\\"f3cfc37ff7a5\\\"\\ +\\ JSON.stringify\\(process.env\\)\\ +\\ \\\"f3cfc37ff7a5\\\"\\'"

Fix

I couldn't make sense of that mess of escape sequences, so I simply edited enter-systemd-namespace to use \n as a delimiter by replacing xargs printf ' %q' with xargs -d '\n' printf ' %q' at line 47 of enter-systemd-namespace. This appears to make things work as expected.

Login command issue

Regardless of whether the xargs fix above is in place, the VSCode terminal shows the following error immediately prior to exiting.

With the xargs fix in place, the login command that's failing now looks like the following on my machine

/bin/login -p -f myuser 'AMD_ENTRYPOINT="vs/server/remoteExtensionHostProcess"' 'APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL="true"' <other env vars snipped>

Unfortunately I don't yet have a fix for this one. I assume the failure is either because of the single quotes causing the double quotes to be passed as part of the env var args, or because login doesn't expect a list of env vars when the -f flag is used, as shown at the top of the login man page, which I've included below:

NAME
       login - begin session on the system

SYNOPSIS
       login [-p] [-h host] [username] [ENV=VAR...]

       login [-p] [-h host] -f username

       login [-p] -r host