plugins/docker-master/skills/docker-git-bash-guide/SKILL.md
Docker on Windows with Git Bash / MINGW path conversion. PROACTIVELY activate for: (1) Docker commands failing on Windows Git Bash with path errors, (2) volume mount path conversion (-v $(pwd):/app), (3) MSYS_NO_PATHCONV and MSYS2_ARG_CONV_EXCL workarounds, (4) double-slash escapes (//c/foo) for MINGW, (5) docker-compose volume mounts on Windows, (6) WSL2 vs Hyper-V backend path interop, (7) line-ending issues in mounted scripts (CRLF vs LF), (8) UNC path limitations. Provides: MSYS path-conversion explainer, copy-pasteable env-var workarounds, double-slash recipes, line-ending fixes, and compose-mount patterns for Windows.
npx skillsauth add JosiahSiegel/claude-plugin-marketplace docker-git-bash-guideInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill provides comprehensive guidance on handling Docker commands in Git Bash (MINGW) on Windows, with specific focus on volume mount path conversion issues and solutions.
When running Docker commands in Git Bash (MINGW) or MSYS2 on Windows, automatic path conversion can cause serious issues with volume mounts and other Docker commands.
MSYS/MINGW shells automatically convert arguments that look like Unix paths when calling Windows executables (like docker.exe):
Examples of problematic conversions:
# What you type:
docker run -v /c/Users/project:/app myimage
# What Docker receives (BROKEN):
docker run -v C:\Program Files\Git\c\Users\project:/app myimage
Triggers for path conversion:
/) in arguments/foo:/bar)- or ,What's exempt from conversion:
= (variable assignments)C:); (already Windows format)// (network paths/Windows switches)Use these environment variables to detect when path conversion issues may occur:
# Most reliable: Check for MSYSTEM
if [ -n "$MSYSTEM" ]; then
echo "Running in Git Bash/MINGW - path conversion needed"
fi
# Alternative: Check uname
if [[ "$(uname -s)" == MINGW* ]]; then
echo "Running in MINGW environment"
fi
# Environment variable to check:
# MSYSTEM values: MINGW64, MINGW32, MSYS
The most reliable solution for Git Bash on Windows.
Prefix each Docker command with MSYS_NO_PATHCONV=1:
# Volume mount with $(pwd)
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# Volume mount with absolute path
MSYS_NO_PATHCONV=1 docker run -v /c/Users/project:/app myimage
# Multiple volume mounts
MSYS_NO_PATHCONV=1 docker run \
-v $(pwd)/data:/data \
-v $(pwd)/config:/etc/config \
myimage
Disable path conversion for all Docker commands in your session:
# Add to ~/.bashrc or run in current shell
export MSYS_NO_PATHCONV=1
# Now all Docker commands work normally
docker run -v $(pwd):/app myimage
Create a function wrapper that automatically disables path conversion:
# Add to ~/.bashrc
docker() {
(export MSYS_NO_PATHCONV=1; command docker.exe "$@")
}
# Or using MSYS2_ARG_CONV_EXCL for MSYS2
docker() {
(export MSYS2_ARG_CONV_EXCL='*'; command docker.exe "$@")
}
# Make function available in subshells
export -f docker
For MSYS2 environments (not standard Git Bash):
# Disable all argument conversion
export MSYS2_ARG_CONV_EXCL='*'
# Selective exclusion (specific patterns)
export MSYS2_ARG_CONV_EXCL='--dir=;/test'
# Environment variable conversion exclusion
export MSYS2_ENV_CONV_EXCL='*'
Prefix paths with an extra / to prevent conversion:
# Single slash (converted - BROKEN)
docker run -v /c/Users/project:/app myimage
# Double slash (not converted - WORKS)
docker run -v //c/Users/project:/app myimage
# Works in Git Bash on Windows
# Treated as single slash on Linux (portable)
Advantages:
Disadvantages:
Always use lowercase $(pwd) (not $PWD) with proper syntax:
# CORRECT: Round brackets, lowercase pwd, no quotes
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# CORRECT: With subdirectories
MSYS_NO_PATHCONV=1 docker run -v $(pwd)/src:/app/src myimage
# WRONG: Uppercase PWD variable (may not convert correctly)
docker run -v $PWD:/app myimage
# WRONG: Without MSYS_NO_PATHCONV (path gets mangled)
docker run -v $(pwd):/app myimage
# Named volumes (no path conversion issue)
docker run -v my-named-volume:/data myimage
# Bind mount with MSYS_NO_PATHCONV (RECOMMENDED)
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# Bind mount with double slash (ALTERNATIVE)
docker run -v //c/Users/project:/app myimage
# Read-only bind mount
MSYS_NO_PATHCONV=1 docker run -v $(pwd)/config:/etc/config:ro myimage
# Multiple volumes
MSYS_NO_PATHCONV=1 docker run \
-v $(pwd)/src:/app/src \
-v $(pwd)/data:/app/data \
-v my-named-volume:/var/lib/data \
myimage
Docker Compose files use forward slashes and relative paths - these work correctly in Git Bash:
# WORKS WITHOUT MODIFICATION in Git Bash
services:
app:
image: myimage
volumes:
# Relative paths (RECOMMENDED)
- ./src:/app/src
- ./data:/app/data
# Named volumes (RECOMMENDED)
- my-data:/var/lib/data
# Windows absolute paths with forward slashes (WORKS)
- C:/Users/project:/app
# Unix-style paths (WORKS if referring to WSL/MINGW paths)
- /c/Users/project:/app
volumes:
my-data:
Important: When running docker compose commands:
# No special handling needed for compose files
docker compose up -d
# But if you use command-line volume overrides:
MSYS_NO_PATHCONV=1 docker compose run -v $(pwd)/extra:/extra app
# Set up environment once per session
export MSYS_NO_PATHCONV=1
# Run with live code reload
docker run -d \
--name dev-app \
-v $(pwd)/src:/app/src \
-v $(pwd)/public:/app/public \
-p 3000:3000 \
node:20-alpine \
npm run dev
# View logs
docker logs -f dev-app
# Use named volume for database data (no path issues)
docker run -d \
--name postgres-db \
-e POSTGRES_PASSWORD=mypassword \
-v pgdata:/var/lib/postgresql/data \
-p 5432:5432 \
postgres:16-alpine
# Mount init scripts with MSYS_NO_PATHCONV
MSYS_NO_PATHCONV=1 docker run -d \
--name postgres-db \
-e POSTGRES_PASSWORD=mypassword \
-v pgdata:/var/lib/postgresql/data \
-v $(pwd)/init.sql:/docker-entrypoint-initdb.d/init.sql:ro \
-p 5432:5432 \
postgres:16-alpine
# Project structure:
# /c/Users/project/
# ├── docker-compose.yml
# ├── backend/
# ├── frontend/
# └── data/
# docker-compose.yml (no special path handling needed)
cat > docker-compose.yml <<'EOF'
services:
backend:
build: ./backend
volumes:
- ./backend/src:/app/src
- ./data:/app/data
ports:
- "4000:4000"
frontend:
build: ./frontend
volumes:
- ./frontend/src:/app/src
- ./frontend/public:/app/public
ports:
- "3000:3000"
depends_on:
- backend
database:
image: postgres:16-alpine
volumes:
- db-data:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: changeme
volumes:
db-data:
EOF
# Start everything (works normally)
docker compose up -d
# Override with additional volume (needs MSYS_NO_PATHCONV)
MSYS_NO_PATHCONV=1 docker compose run -v $(pwd)/scripts:/scripts backend bash
Symptoms:
Error response from daemon: invalid mount config for type "bind":
bind source path does not exist: C:\Program Files\Git\c\Users\project
Diagnosis:
C:\Program Files\Git\ prefix addedSolution:
# Add MSYS_NO_PATHCONV before command
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
Symptoms:
Diagnosis:
Solution:
# Use MSYS_NO_PATHCONV with $(pwd)
MSYS_NO_PATHCONV=1 docker run -v $(pwd)/data:/data myimage
# Or use double slash
docker run -v //c/Users/project/data:/data myimage
# Or use named volumes for persistent data
docker run -v my-named-volume:/data myimage
Symptoms:
Error: invalid reference format
Diagnosis:
Solution:
# Use MSYS_NO_PATHCONV and quote $(pwd)
MSYS_NO_PATHCONV=1 docker run -v "$(pwd)":/app myimage
# Or avoid spaces in project paths entirely (RECOMMENDED)
# Move project from:
# C:/Users/My Name/My Projects/app
# To:
# C:/Users/MyName/projects/app
Symptoms:
$PWD variable instead of $(pwd)Solution:
# WRONG: Using $PWD
docker run -v $PWD:/app myimage
# CORRECT: Using $(pwd)
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# Explanation:
# $(pwd) is a command that returns current directory
# $PWD is an environment variable that may not be properly formatted
Create a test script to verify Docker volume mounts work correctly:
#!/bin/bash
# test-docker-volume.sh
echo "Testing Docker volume mounts in Git Bash..."
# Create test file
mkdir -p test-mount
echo "Hello from host" > test-mount/test.txt
# Test 1: With MSYS_NO_PATHCONV
echo "Test 1: With MSYS_NO_PATHCONV"
MSYS_NO_PATHCONV=1 docker run --rm -v $(pwd)/test-mount:/data alpine cat /data/test.txt
# Test 2: With double slash
echo "Test 2: With double slash"
docker run --rm -v //$(pwd)/test-mount:/data alpine cat /data/test.txt
# Test 3: Without workaround (should fail)
echo "Test 3: Without workaround (may fail)"
docker run --rm -v $(pwd)/test-mount:/data alpine cat /data/test.txt
# Cleanup
rm -rf test-mount
echo "Testing complete!"
Run it:
chmod +x test-docker-volume.sh
./test-docker-volume.sh
Add to your ~/.bashrc:
# Docker path conversion fix for Git Bash on Windows
export MSYS_NO_PATHCONV=1
# Or use a wrapper function if you prefer per-command control
docker() {
(export MSYS_NO_PATHCONV=1; command docker.exe "$@")
}
export -f docker
# Alias for docker compose (if needed)
alias docker-compose='MSYS_NO_PATHCONV=1 docker compose'
Use this to automatically detect and configure Docker for Git Bash:
# Add to ~/.bashrc
# Detect if running in Git Bash/MINGW on Windows
if [ -n "$MSYSTEM" ] || [[ "$(uname -s)" == MINGW* ]]; then
# Running in Git Bash/MINGW
echo "Git Bash detected - enabling Docker path conversion fix"
export MSYS_NO_PATHCONV=1
# Optional: Create wrapper function for explicit control
docker() {
(export MSYS_NO_PATHCONV=1; command docker.exe "$@")
}
export -f docker
fi
| Variable | Purpose | Values |
|----------|---------|--------|
| MSYS_NO_PATHCONV | Disable all path conversion (Git Bash) | 1 to disable |
| MSYS2_ARG_CONV_EXCL | Exclude specific arguments (MSYS2) | '*' or patterns |
| MSYS2_ENV_CONV_EXCL | Exclude environment variables (MSYS2) | '*' or patterns |
| MSYSTEM | MSYS subsystem indicator | MINGW64, MINGW32, MSYS |
# RECOMMENDED: Export once per session
export MSYS_NO_PATHCONV=1
docker run -v $(pwd):/app myimage
# Per-command prefix
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# Double slash workaround
docker run -v //c/Users/project:/app myimage
# Named volumes (no path issues)
docker run -v my-data:/data myimage
# Docker Compose (relative paths work)
docker compose up -d
These Docker commands work normally in Git Bash without special handling:
-v my-volume:/datadocker network createdocker build, docker pulldocker run myimageThese commands require path conversion fixes:
-v /c/Users/project:/app-v $(pwd):/appBest Practice for Git Bash on Windows:
export MSYS_NO_PATHCONV=1./src:/app/srcmy-data:/var/lib/dataMSYS_NO_PATHCONV=1 docker run -v $(pwd):/appThis configuration ensures Docker commands work correctly in Git Bash on Windows without path conversion issues.
development
This skill should be used when the user asks to train, debug, scale, or improve ML models. PROACTIVELY activate for: (1) PyTorch, TensorFlow/Keras, JAX, Flax, Hugging Face Trainer/Accelerate training loops, (2) distributed training, DDP/FSDP/DeepSpeed, TPU/GPU setup, (3) mixed precision AMP/bf16, gradient accumulation, checkpointing, seeding, (4) overfitting, imbalance, loss functions, regularization, LR schedules, warmup, (5) memory optimization, gradient checkpointing, offloading, quantization-aware training. Provides: reproducible training best practices across deep learning and classical ML.
development
This skill should be used when the user asks to productionize, track, version, govern, monitor, or automate ML systems. PROACTIVELY activate for: (1) MLflow, Weights & Biases, Neptune, Comet, ClearML experiment tracking, (2) model registry, model versioning, artifact lineage, reproducibility, (3) Kubeflow, SageMaker Pipelines, Vertex AI Pipelines, Azure ML pipelines, Databricks workflows, (4) CI/CD, continuous training/evaluation, A/B tests, canary/shadow deployments, (5) drift detection, model monitoring, data validation, responsible AI governance. Provides: end-to-end MLOps architecture and operational safeguards.
development
This skill should be used when the user asks to optimize, export, serve, compress, or accelerate ML inference. PROACTIVELY activate for: (1) latency, throughput, p95/p99, batching, concurrency, KV cache, memory, or cost issues, (2) quantization INT8/INT4, GPTQ, AWQ, bitsandbytes, pruning, sparsity, distillation, (3) ONNX export, ONNX Runtime, TensorRT, TorchScript, torch.compile, XLA, OpenVINO, Core ML, TFLite, (4) Triton, TorchServe, TF Serving, BentoML, Seldon, KServe configuration, (5) edge deployment, CPU/GPU/TPU/Inferentia serving. Provides: hardware-aware inference optimization and safe benchmarking.
testing
This skill should be used when the user asks to tune hyperparameters, run sweeps, optimize search spaces, or use AutoML. PROACTIVELY activate for: (1) Optuna, Ray Tune, FLAML, AutoGluon, Hyperopt, Nevergrad, KerasTuner, W&B sweeps, (2) grid search, random search, Bayesian optimization, TPE, Gaussian processes, evolutionary search, (3) ASHA, Hyperband, successive halving, multi-fidelity optimization, population-based training, (4) learning-rate finder, batch-size search, early stopping, pruning, (5) reproducible sweep design and experiment analysis. Provides: budget-aware hyperparameter search strategy.