Visual Studio Code - Remote Debugging Bazel C++ - Unable to read file 'vscode-remote://dev- file

when you try to compile with bazel, you will have 4 soft link(bazel-bin, bazel-{source-folder}, bazel-out, bazel-testlog)modify this attribute wi

"cwd": "${workspaceFolder}/bazel-",

I'm not sure that your problem is due to remote debugging. I believe that the following info will work whether or not you're in a remote environment.

Bazel generates a few symlinks in your project's root folder that contain useful data (for more see the docs):

• bazel-bin is a symlink to a folder in the output directory that contains generated code and binaries for the latest configuration of the build you've run.
• bazel-{folder-name} is a symlink to the execRoot, which is how bazel sees your project's source code. {folder-name} is the name of the folder your project is in.
• bazel-out is a symlink to bazel's output root.
• bazel-testlog is a symlink to the outputs from test runs

If you're not using bazel's runfiles library

To provide VSCode with sources at the right location, modify the "cwd" attribute in launch.json to:

"cwd": "${workspaceFolder}/bazel-{folder-name}",`

If you are using runfiles

You're using runfiles if your program requires files in a data attribute in any of its dependencies

First, set "cwd" to the root of the runfiles tree for your binary, and then set "sourceFileMap" in a way that maps the current working directory to the execRoot symlink. For me (on linux), /proc/self/cwd maps correctly, but that might not be true for you. I was able to tell that I got it wrong because VSCode complained about being unable to read a file at /proc/self/cwd/external/external-project/src/file.cpp.

"cwd": "${workspaceFolder}/bazel-bin/path/to/executable/executable.runfiles/{workspace-name}`,"sourceFileMap": {    "/proc/self/cwd": "${workspaceFolder}/bazel-{folder-name}`,},

{workspace-name} can be found in WORKSPACE, it will look like workspace(name = "my-project"). If there is no workspace name defined in that file, it defaults to __main__.

I might also recommend changing the "program" attribute to a more convenient location. If the last thing you did was build your binary with bazel, you can find the built executable at bazel-bin/path/to/executable/executable

A full example:

{    "version": "0.2.0",    "configurations": [        {            "name": "(gdb) Launch Debug",            "type": "cppdbg",            "request": "launch",            // path to the most recently built version of executable            // this should be built with `bazel build -c dbg //path/to:executable`            "program": "${workspaceFolder}/bazel-bin/path/to/executable/executable",            "args": [],            "stopAtEntry": false,            "cwd": "${workspaceFolder}/bazel-bin/path/to/executable/executable.runfiles/{workspace-name}",            "environment": [],            "externalConsole": false,            "MIMode": "gdb",            "setupCommands": [                {                    "description": "Enable pretty-printing for gdb",                    "text": "-enable-pretty-printing",                    "ignoreFailures": true                }            ],            "sourceFileMap": {                "/proc/self/cwd": "${workspaceFolder}/bazel-{folder-name}"            }        }    ]}

Most of this is covered in this useful post (which also shows how to automatically build your executable using tasks.json):https://shanee.io/blog/2019/05/28/bazel-with-visual-studio-code/