Attaching to a running docker container VSCode session still uses the host environment

[yassibeh]

Question:
I've launched a Docker container with full configuration and sourced the environment during the build process. By doing this, I am able to run any bitbake command directly from my terminal without needing to source anything. I’ve tested various sanity check commands, such as which bitbake, which devtool, and bitbake-layers show-layers, and everything works fine in the container. Despite having the correct paths and everything appearing fine, the sanity check still fails and can't even run which bitbake, and I can't figure out why.

Here’s my devcontainer.json configuration that should enable the Bitbake extension to work without needing any extra environment setup:

{
  "workspaceFolder": "/home/user/Documents/Prj_1/mep",
  "extensions": [
    "mads-hartmann.bash-ide-vscode",
    "ms-python.debugpy",
    "ms-python.python",
    "ms-python.vscode-pylance",
    "yocto-project.yocto-bitbake"
  ],
  "settings": {
    "bitbake.loggingLevel": "debug",
    "files.watcherExclude": {
      "**/.git/**": true,
      "**/build_*": true,
      "./Delivery*/**": true,
      "./packages/**": true
    },
    "files.associations": {
      "*.conf": "bitbake",
      "*.inc": "bitbake"
    },
    "search.exclude": {
      "**/build_*": true
    },
    "bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
    "bitbake.sdkImage": "mgdp-biosdk-image",
    "bitbake.commandWrapper": "",
    "python.analysis.exclude": [
      "**/build_*"
    ],
    "python.autoComplete.extraPaths": [
      "${workspaceFolder}/sources/poky/bitbake/lib",
      "${workspaceFolder}/sources/poky/meta/lib",
      "${workspaceFolder}/bitbake/lib",
      "${workspaceFolder}/meta/lib"
    ],
    "python.analysis.extraPaths": [
      "${workspaceFolder}/sources/poky/bitbake/lib",
      "${workspaceFolder}/sources/poky/meta/lib",
      "${workspaceFolder}/bitbake/lib",
      "${workspaceFolder}/meta/lib"
    ],
    "bitbake.disableConfigModification": true
  }
}

Despite all configurations being correct and logging level set to "debug", the output is still empty, and I am not sure what’s wrong. Any suggestions?

Another separate question unrelated to the first one :
Additionally, I have a script that takes multiple configuration options as parameters. Based on the selected configuration, I need to source the terminal before running bitbake. The command looks like this:

./script_setup -arg config_case.conf

I want to know how to use bitbake.shellEnv for this purpose. Can anyone provide examples of how to configure this?

[deribaucourt]

A few things to try:

1. Are you sure this settings is correct? "bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
   It may result in the behavior you observe. It outputs a tooltip, but it can be dismissed in a "no longer show" manner, which becomes hard to notice.
2. I don't think you have to specify "workspaceFolder": "/home/user/Documents/Prj_1/mep",. Maybe it changes how this variable is expanded.
3. The extension always wants to source something itself or run a command wrapper. Your use case of running bitbake directly inside the container's shell is actually new! I'd suggest to skip the environment setup by providing "bitbake.commandWrapper": "bash -c"

Regarding your other question, we can support multiple commandline environments through bitbake.buildConfigurations. See https://github.com/yoctoproject/vscode-bitbake#defining-multiple-configurations
You could source your script through a commandWrapper since it requires to pass an additional argument.

[yassibeh]

Context

I am using the "Attach to Running Container" feature in VS Code to connect to a Docker container that was started manually using a custom script. The container mounts my Yocto workspace at /home/dev/workspace.

Inside the container, I source a script (setup-env) that correctly sets up the Yocto build environment. The bitbake and devtool commands are available in the container’s $PATH, and everything works fine from the terminal.

---

Problem

The BitBake extension seems to run its commands on the host machine, not inside the attached container.

Here is the log output from the BitBake extension:

Executing Bitbake command with /bin/bash in /home/dev/workspace:
bash -c 'which devtool bitbake || true'
BitBake settings error: devtool not found in $PATH
bitbake settings are not sane, skip rescan

However, inside the container’s terminal, running the same command works as expected:

bash -c 'which devtool bitbake || true'
/home/dev/workspace/scripts/devtool
/home/dev/workspace/bitbake/bin/bitbake

This confirms that the environment is correctly configured inside the container.

---

Expected Behavior

When using "Attach to Running Container", the BitBake extension should run all its commands inside the container, not on the host.

Other features like the terminal and file explorer work correctly in the container. The extension should behave the same way.

---

Actual Behavior

The extension tries to execute commands in the workspace path as if it were running on the host, where the Yocto environment is not available and $PATH is incorrect.

---

Setup

• VS Code connected to container via “Attach to Running Container”
• Yocto workspace mounted at /home/dev/workspace
• BitBake tools available in $PATH inside container
• devContainer settings.json includes:

  {
    "bitbake.commandWrapper": "bash -c",
    "bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
    "bitbake.pathToBuildFolder": "${workspaceFolder}/build_target"
  }

Visual Confirmation

As shown in the attached screenshots:

The container is named image_ubuntu_20.04, and the Yocto workspace (/home/yassine/Documents/Pj_1/mep) is mounted correctly.

Steps to Reproduce

1. Start a container manually and mount the Yocto workspace.
2. Attach to it using VS Code’s "Attach to Running Container".
3. In the container’s terminal, verify bitbake and devtool are in $PATH.
4. Open the BitBake Output panel.
5. Observe that the extension cannot find the commands.

---

Request

If the "Attach to Running Container" flow is currently unsupported or has known limitations, it would be very helpful to have this documented in the extension’s README or FAQ.

Otherwise, I would kindly suggest reviewing how the extension determines its execution context, so that it can correctly detect and operate within the container environment—especially in cases where the terminal and file system access already reflect the container context.

Please let me know if additional logs or details would help in reproducing the issue.

[yassibeh]

More Context

I’m using Visual Studio Code by attaching it directly to a running Docker container. The container was started manually using custom scripts and contains all necessary Yocto environment tools, variables, and folder mounts.

One of the main bind mounts is the Yocto workspace:

Host: /home/.../Pj_1/mep
→ Container: /home/.../Pj_1/mep

This workspace already contains a valid .vscode/settings.json that works correctly when opened from the host system.

Inside the container, I'm not using a .devcontainer/devcontainer.json. Instead, I configure container-specific settings using the Dev Containers extension's "Configure Container Features / Settings" interface.

---

What Works

• Attaching to the container from VS Code works as expected.
• Terminal commands like bash -c 'which devtool bitbake' return the correct paths.
• The Yocto environment is sourced using a script injected into /etc/profile.d/yocto-env.sh, and sourced via /etc/bash.bashrc.
• All paths are correct and validated inside the terminal of the container.

---

The Problem

Even though bitbake and devtool are accessible from the integrated terminal, the Yocto BitBake extension logs the following:

Executing Bitbake command with /bin/bash in /.../mep:
bash -c 'which devtool bitbake || true'
BitBake settings error: devtool not found in $PATH
bitbake settings are not sane, skip rescan

This suggests the extension is running its commands in an environment where the Yocto setup script has not been sourced — despite it being defined globally in /etc/profile.d.

---

Goal

The goal is simple: enable the Yocto BitBake extension to function properly inside the container. This means recognizing bitbake and devtool via $PATH, and correctly applying extension settings like bitbake.pathToBuildFolder.

---

What I’ve Tried

• Confirmed that bitbake and devtool are available from the terminal inside the container.
• Verified that the environment is correctly sourced on login and interactive terminals.
• Added a persistent source ./setup-env call in /etc/profile.d/yocto-env.sh and ensured it’s referenced in /etc/bash.bashrc.
• Reviewed and tested all relevant bitbake.* settings in the container VS Code configuration.

Despite this, the extension does not seem to source the environment or load $PATH correctly when it runs background diagnostics.

---

Visual Confirmation

• The container mounts and correct source/destination mapping.
• A terminal session where devtool and bitbake are detected correctly.
• The extension log still reporting that devtool is not found.

---

Questions

• Is the BitBake extension known to ignore /etc/profile.d or /etc/bash.bashrc when running background checks?
• Is there a recommended way to make the extension load the full interactive environment?
• Does this use case require a .devcontainer/devcontainer.json for proper extension support, even if the container is already running and configured?

---

[deribaucourt]

I don't know about the "Attach to Running Container" feature, have to try this one out!
I thought you were using the Remote sessions, which we do support on build servers: https://code.visualstudio.com/remote/advancedcontainers/develop-remote-host
Maybe docker containers are a specific type of session where we incorrectly use the host system's shell environment.

There's probably something we have to do to support the "Attach docker" feature, like getting a different shell environment, but I don't have time to address for now unfortunately. I'll mark this as a feature request.

In the meantime, I can think of a few workarounds to try:

1. Use a remote SSH connection to enter the container, this could get rid of the host shell environment (needs to add an openssh server in your docker)
2. Allow starting the container with a bitbake.commandWrapper (probably not feasible in your case, I imagine the container has to be running beforehand for a specific reason)
3. Do a docker exec commandWrapper that executes inside your running container (see the documentation for docker exec)

Hope this helps!