You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] develop.watch initial_sync: true does not fire at container start #13725
develop.watch entries with initial_sync: true do not copy files from host to container at container creation time. Change-triggered syncs work correctly — only initial_sync is affected.
mkdir -p src &&echo"hello"> src/test.txt
docker compose up --watch -d
sleep 30
docker exec<container> ls /app/src/ # → "No such file or directory"# But change-triggered sync works:
touch src/test.txt
sleep 10
docker exec<container> ls /app/src/ # → test.txt appears
Observed Behavior
Container starts and runs successfully
⦿ Watch enabled message appears in compose output
/app/src/ does NOT exist inside the container after 30+ seconds
After touching src/test.txt on the host, compose watch detects the change and syncs — /app/src/test.txt appears
Expected Behavior
With initial_sync: true, files should be copied from host to container at compose startup, before the main process starts. Per the documentation: "If initial_sync is set to true, Compose copies the watched files to the container when the service is started."
Environment
Docker Desktop for Mac (Apple Silicon)
Docker Compose v2.35+ (tested with latest stable as of 2026-04-10)
macOS 15.4 (Darwin 25.4.0)
Reproducible across multiple compose projects and file types
Notes
sync entries for individual files (e.g., pytest.ini → /app/pytest.ini) DO work with initial_sync: true
sync entries for directories (e.g., docker/pythonocc → /app/docker/pythonocc) do NOT fire initial_sync
The distinction may be file vs. directory syncing behavior
I was able to reproduce this locally and traced it to initialSyncFiles() in pkg/compose/watch.go.
initial_sync was filtering files using the image creation time, so existing host files could be skipped during startup sync if their mtime was older than the image. That matches the behavior described here: startup sync is empty, but change-triggered sync works after touching the file.
Activity
trinhchien commentedon Apr 11, 2026
I was able to reproduce this locally and traced it to
initialSyncFiles()inpkg/compose/watch.go.initial_syncwas filtering files using the image creation time, so existing host files could be skipped during startup sync if their mtime was older than the image. That matches the behavior described here: startup sync is empty, but change-triggered sync works after touching the file.I opened a fix here: #13728
The patch removes the image-time filter for
initial_syncand adds tests for both directory and single-file watch paths.tsamarasinghe commentedon May 20, 2026
any news about this ?
NathanSavageKaimai commentedon Jul 28, 2026
Hey, I saw the PR was marked stale and closed. Is this still planned?
For anyone finding this thread, one workaround is just to write a utility script that updates the timestamp on your source files.
Heres mine
rocket-micha commentedon Jul 31, 2026
Any plans here? 👀 This is a very frustrating bug
Fix initial watch sync for existing files
fix(watch): sync all files on initial_sync, regardless of mtime