devcontainer.json

{
  // Starter devcontainer written by bootstrap/bootstrap.ps1 (or .sh) from
  // github.com/nabil-becker/devcontainer-features. Edit freely; bootstrap
  // never overwrites this file once it exists.
  "name": "${localWorkspaceFolderBasename}",
  "image": "mcr.microsoft.com/devcontainers/base:debian",
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {},
    // Shares the host's Docker daemon (Docker Desktop / wslc). Swap for
    // ghcr.io/devcontainers/features/docker-in-docker:2 (with "moby": false
    // on Debian 13) if you need `devcontainer features test` or nested
    // `devcontainer up` from inside on a Windows/macOS host.
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
    "ghcr.io/nabil-becker/devcontainer-features/go-task:1": {},
    "ghcr.io/nabil-becker/devcontainer-features/devcontainer-cli:1": {},
    // Every Feature of the collection owns its persistent state (logins,
    // config, transcripts) in a named volume it mounts itself and makes
    // usable at post-create; nothing to configure. git: worktree-aware
    // wrapper, safe.directory and core.hooksPath; a checkout whose git dir
    // lives in the host home's .git-dirs (OneDrive) needs no line here when
    // you start through the tasks: the launcher adds that mount (git 1.4.0 or
    // later; see "Host mounts" below).
    "ghcr.io/nabil-becker/devcontainer-features/git:1": {},
    // "ghcr.io/nabil-becker/devcontainer-features/gh:1": {},
    // "ghcr.io/nabil-becker/devcontainer-features/claude-code:1": {},
    "ghcr.io/devcontainers/features/powershell:1": {}
  },
  // The host, as the launcher (task devcontainer:up) found it: it sets these in its
  // own environment before it runs the devcontainer CLI, and ${localEnv} passes them
  // on. Features read them (unset = an unknown host, they use defaults); nothing in
  // this file needs to know the host. Opening the folder straight in VS Code skips the
  // launcher, so they expand to empty strings there: start through the tasks.
  "containerEnv": {
    // windows-docker, windows-wsl-docker, windows-wslc, linux or macos
    "DCF_HOST_TYPE": "${localEnv:DCF_HOST_TYPE}",
    // The host user's home: %USERPROFILE% on Windows, $HOME elsewhere
    "DCF_HOST_HOME": "${localEnv:DCF_HOST_HOME}",
    // socket, key or none (none for now)
    "DCF_HOST_SSH_AGENT": "${localEnv:DCF_HOST_SSH_AGENT}",
    // The host folder (DCF_HOST_CLOUD_FOLDER in .devcontainer/.env) the launcher mounts for the
    // cloud-folder Feature; empty when none. The Feature's status names it.
    "DCF_HOST_CLOUD_FOLDER": "${localEnv:DCF_HOST_CLOUD_FOLDER}",
    // The workstation's machine name, set by the launcher: agents' session names use it for
    // {machine}; "container" when empty.
    "DCF_HOST_MACHINE": "${localEnv:DCF_HOST_MACHINE}",
    // 1 when DCF_HOST_FUSE=1 in .devcontainer/.env asked the launcher for FUSE on this machine
    // (the cloud-folder Feature's mount mode); empty otherwise.
    "DCF_HOST_FUSE": "${localEnv:DCF_HOST_FUSE}"
  },
  // FUSE on request, per machine (ADR 0031): with DCF_HOST_FUSE=1 in .devcontainer/.env the
  // launcher fills these three with --device=/dev/fuse, --cap-add=SYS_ADMIN and
  // --security-opt=apparmor=unconfined; otherwise each falls back to a harmless label, so no
  // container gets the privilege unless asked. Keep the three lines even when unused; a change
  // takes effect at the next task devcontainer:rebuild.
  "runArgs": [
    "${localEnv:DCF_HOST_FUSE_DEVICE:--label=dcf.fuse.device=off}",
    "${localEnv:DCF_HOST_FUSE_CAP:--label=dcf.fuse.cap=off}",
    "${localEnv:DCF_HOST_FUSE_SECURITY:--label=dcf.fuse.security=off}"
  ],
  // Host mounts: the launcher (task devcontainer:up / rebuild) adds the mounts the host type
  // needs with `devcontainer up --mount`, today the host home's .git-dirs at /git-dirs (the git
  // Feature's one mount), so nothing here declares it; also, when DCF_HOST_CLOUD_FOLDER is set,
  // that host folder at /mnt/cloud-folder-host, where the cloud-folder Feature's mountPoint
  // option links. HOST_MOUNTS=false turns that off. If you
  // keep or add the line below, the launcher sees the target and skips its own, so it is harmless.
  // Only when you also open the folder straight in VS Code (Reopen in Container), which skips the
  // launcher and leaves DCF_HOST_HOME empty, add the line yourself, with the home variable VS Code
  // itself sees: ${localEnv:USERPROFILE} on a Windows host, ${localEnv:HOME} on Linux, macOS and WSL
  // (not DCF_HOST_HOME). Create the folder first with the initializeCommand of the next block:
  //   "mounts": [ "source=${localEnv:USERPROFILE}/.git-dirs,target=/git-dirs,type=bind" ],
  //
  // To keep a Feature's state on the host disk instead of its volume
  // (survives container-engine resets, stays outside a synced checkout),
  // bind-mount the same target; the repo's mount wins over the Feature's.
  // The folder must exist before the start, hence the initializeCommand
  // (array form: a string goes through cmd /c on Windows, which mangles
  // quotes and %VARS%):
  //   "initializeCommand": ["task", "devcontainer:homes", "NAME=myrepo", "--", "claude-code", "gh"],
  //   "mounts": [
  //     "source=${localEnv:USERPROFILE}/.devcontainer-homes/myrepo/claude-code,target=/var/lib/devcontainer-features/claude-code,type=bind",
  //     "source=${localEnv:USERPROFILE}/.devcontainer-homes/myrepo/gh,target=/var/lib/devcontainer-features/gh,type=bind"
  //   ],
  "remoteUser": "vscode"
}