Launching of custom GDB does not correctly set CWD (breaks relative paths)

I'm trying to debug an STM32 microcontroller through OpenOCD in VSCode 1.13.0 on Windows 10.

I have this launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "ARM GDB Launch",
            "logging": { "trace": true, "traceResponse": true, "engineLogging": true },
            "type": "cppdbg",
            "request": "launch",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "program": "${workspaceRoot}/BUILD/DISCO_F407VG/GCC_ARM/tracker.elf",
            "windows": {
                "miDebuggerPath": "arm-none-eabi-gdb.exe"
            },
            "linux": {
                "miDebuggerPath": "arm-none-eabi-gdb"
            },
            "miDebuggerServerAddress": "localhost:3333",
            "targetArchitecture": "arm",
            "customLaunchSetupCommands": [
                {
                    "description": "Set remote target",
                    "text": "file BUILD/DISCO_F407VG/GCC_ARM/tracker.elf"
                },
                {
                    "description": "Set remote target",
                    "text": "target remote localhost:3333"
                },
                {
                    "description": "Set hardware breakpoints",
                    "text": "set remote hardware-breakpoint-limit 6"
                },
                {
                    "description": "Set hardware breakpoints",
                    "text": "set remote hardware-watchpoint-limit 4"
                },
                {
                    "description": "Reset 1",
                    "text": "monitor reset halt"
                },
                {
                    "description": "Load code",
                    "text": "load"
                },
                {
                    "description": "Reset 2",
                    "text": "monitor reset halt"
                }
            ]
        }
    ]
}

However, this doesn't work. I get the following error:

Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "file BUILD/DISCO_F407VG/GCC_ARM/tracker.elf"". BUILD/DISCO_F407VG/GCC_ARM/tracker.elf: No such file or directory.

However, the file is there, and if I use the full path, it works. (I do consider it bad practice to use full paths in any code, specially code that others might use).

Since it looked like a path problem, I launched SysInternals' Process Explorer and tried to find the arm-none-eabi-gdb.exe process. I found that its Current directory field is just empty! Screenshot:

One workaround that I found, at least until the bug is fixed, is to create a batch (.bat) with this content:

@arm-none-eabi-gdb.exe %*

Then I changed the miDebuggerPath setting to:

                "miDebuggerPath": "${workspaceRoot}/wingdb.bat"

Where wingdb.bat is the name of the file I just created.

Curiously, this does work, which suggests that VSCode is not properly setting the debugger's current directory properly.

Start with the launch.json configuration, especially cwd and miDebuggerPath, and reproduce the failure using the relative file command in customLaunchSetupCommands. Compare the direct arm-none-eabi-gdb.exe launch with the wingdb.bat workaround. Done means the debugger process receives the intended current directory and resolves the relative tracker.elf path without a full path or wrapper.