Ken Muse

Marking Workspaces Safe with Dotfiles


There are many ways to automate the process of marking directories as “safe” to avoid the “detected dubious ownership in repository” message. Last week, I discussed how to avoid the issue by using postStartCommand or postAttachCommand in devcontainer.json. This week, let’s see an alternative using Dotfiles.

If you’re not familiar with Dotfiles, they are simply a repository container a set of files prefixed with ‘.’ and any install scripts you might need to configure a working environment. These are particularly helpful with dev containers, since they can bootstrap, customize, and personalize the development environment per user. This is especially helpful when working with development containers. You can read more about using Dotfiles with dev containers here . Unless a specific script name is provided, the process looks for a script with one of the following names in the root of the repository (in order):

  1. install.sh
  2. install
  3. bootstrap.sh
  4. bootstrap
  5. setup.sh
  6. setup

This means that we can customize the script to automatically try to configure the safe.directory for us. By default, the workspace with the source code will be created as a child folder in /workspaces. In addition, we can detect that we are running inside of Visual Studio Code by looking at the TERM_PROGRAM environment variable. It will be configured with the value “vscode”. It will also define REMOTE_CONTAINERS (set to true) when we’re running inside of a containerized environment.

Knowing this, we can create a script that automatically adds all folders in /workspaces if the Dotfiles script is being run in an environment with TERM_PROGRAM and REMOTE_CONTAINERS configured. For example:

1if [ -d "/workspaces" -a "$TERM_PROGRAM" = "vscode" -a "$REMOTE_CONTAINERS" = "true" ]
2  then
3    for f in /workspaces/*
4    do
5      git config --global --add safe.directory $f
6    done
7  fi

Github Codespaces allows us to get more specific. In addition to TERM_PROGRAM, it will have some additional variables that we can detect and use:

VariableDescription
CODESPACE_NAMEThe subdomain that is used for hosting our Codespace instance on github.dev
CODESPACE_VSCODE_FOLDERThe full path to our workspace. No guessing required!
CODESPACESIf we’re running in Codespaces, this will be set to true

We could easily extend the script to include support for Codespaces, applying the same assumption about /workspaces or using CODESPACE_VSCODE_FOLDER to automatically add the correct directory.

Happy scripting!