Dev container using dotfiles

Describe the Bug

I use devcontainer with repo settings in devcontainer.json. For personal customization I use dotfiles. I was able to set this up on cursor but it broke with the recent upgrade. The suggested workflow from a cursor agent was to create a ~/.cursor/settings.json file with the following entries:

{
    "dotfiles.repository": "https://github.com/user_name/dotfiles.git",
    "dotfiles.targetPath": "~/dotfiles",
    "dotfiles.installCommand": "install.sh"
  }

This would install my personal tools and make them available inside the container. This broke when upgrading to 1.1.5. I believe it worked on all previous versions. There is also no way in the vscode settings to configure dotfiles. The microsoft devcontainer extension allows configuration of the dotfiles settings.

Steps to Reproduce

Create a repo with an install.sh that just creates an empty file in the users home directory. My repo is part of a private organization and requires a github token to access and I do not know if this is required to test.

Create a ~/.cursor/settings.json with the following settings (point to the git repo created above)

{
    "dotfiles.repository": "https://github.com/user_name/dotfiles.git",
    "dotfiles.targetPath": "~/dotfiles",
    "dotfiles.installCommand": "install.sh"
  }

Open the dev container. On versions of cursor <1.1.5 it successfully ran the install.sh and created the associated files in ~/dotfiles directory in the container. On version 1.1.5 it does not. This might also be affected by the devcontainer extension version which is currently 1.0.8 on my system.

Expected Behavior

The configured dotfiles repo is cloned and install script (e.g. install.sh) is run in the configured directory (e.g. ~/dotfiles).

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.1.5 (Universal)
VSCode Version: 1.96.2
Commit: ef5eeb47a684b4c217dfaf0463aa7ea952f8ab90
Date: 2025-06-21T05:26:18.966Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Additional Information

Dev container extension version: 1.0.8

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @jlord_vectra, this is likely happening because we switched our marketplace upstream to OpenVSX, and it doesn’t look like the dotfiles extension is available in OpenVSX. Please reach out to the extension author to publish it there so it will be available in Cursor: GitHub - grgar/vscode-dotfiles: VS Code extension to apply dotfiles from settings

I do not believe that the above extension is related. I do not have that extension installed and I cannot access the command referenced in that git repo from the command palette. I see the dotfiles referenced in vscode docs for devcontainers. The settings that I referenced that I can find in the vscode settings UI (i.e. when using the vscode application and changing settings and searching for “dotfiles”) and they reference the extension “Dev containers”.

I believe the problem is that the forked dev containers extension maintained by anysphere used to support dotfiles and with an update no longer supports dotfiles.

Hi @jlord_vectra, thanks for sharing the docs here. We’re looking at what it would take to support this feature to bring the extension to parity.

1 Like

Hi @jlord_vectra, thank you for your patience as we worked through this issue. We just released version 1.0.14 of the Anysphere Remote Containers extension which supports dotfiles. Could you try upgrading to the latest version of the extension?

Yes, thanks, I see the config option and it attempts to clone while building the container. I have one more issue which I believe is a race condition with the copy of the .gitconfig from host to container related to this issue. I believe I need the copy of the .gitconfig to be placed in the container before cloning the dotfiles repo.

I get the following error:

2025-07-15 08:20:13.519 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.582Z] Start: Run in container: # Clone & install dotfiles via 'install.sh'

2025-07-15 08:20:13.520 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.586Z] Cloning into '/home/vadmin/dotfiles'...

2025-07-15 08:20:13.812 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.885Z] fatal: could not read Username for 'https://github.com': No such device or address

2025-07-15 08:20:13.817 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.891Z]

2025-07-15 08:20:13.817 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.891Z]

2025-07-15 08:20:13.818 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.891Z] Exit code 128

2025-07-15 08:20:13.818 [info] [devcontainer up][stderr]: [2025-07-15T15:20:13.891Z] Stop (411 ms): Run in container: # Clone & install dotfiles via 'install.sh'

In one of my repositories I can get the clone to work by adding

{
    "source": "${localEnv:HOME}/.gitconfig",
    "target": "/home/vadmin/.gitconfig",
    "type": "bind"
},

but in other repositories it always fails with this error.

Hi @jlord_vectra, thanks for raising this issue. We’re working on fixing this by reordering the initialization to configure git / ssh before initializing the dotfiles.

1 Like

Hi @jlord_vectra, we have fixed this in version 1.0.16 of the extension, where it runs the initialization scripts only after the .gitconfig and SSH Auth Socket is configured. Could you try upgrading to the latest version of the extension?