Repository navigation
tsc --watch does not work in docker #63646
Description
🔎 Search Terms
docker devcontainer tsc7
🕗 Version & Regression Information
- This changed between versions v6.0.2 and v7.0.2
⏯ Playground Link
No response
💻 Code
No response
🙁 Actual behavior
tsc --watch simply does not work on any of my projects in the new Go build. It will do an initial build but after that it notices no changes.
Docker: Version 4.81.0
macOS: 15.7.7 (24G720)
uname -a (in container): Linux docker-desktop 6.12.76-linuxkit #1 SMP Thu Jun 25 13:45:40 UTC 2026 aarch64 GNU/Linux
I am using a straightforward bind mount: "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
I can confirm that the Docker container is receiving filesystem events via entr:
root[17:26:39] [/workspace] $ echo package.json | EV_TRACE=1 entr echo 123
open_max: 1048576
123
0/1: fflags: 0xa r 100644 package.json
123
0/1: fflags: 0xa r 100644 package.json
123
If I add --cap-add=SYS_ADMIN I receive a diagnostic from tsc, but still no watch success:
fanotify_mark on '/workspace/node_modules/.pnpm/redis@5.12.1' failed: name_to_handle_at: operation not supported
🙂 Expected behavior
It should watch files for changes.
Additional information about the issue
I have tried VirtioFS and gRPC FUSE.
I have tried Docker VMM and Apple Virtualization framework.
I also tried a bunch of watchOptions configurations but those didn't seem to have any effect.
Activity
hiSandog commentedon Jul 16, 2026
The
entrresult is useful because it shows that events reach the container. Could you add a minimal repo plus the relevant devcontainer/Compose mount configuration, and note whetherTSC_WATCHFILE=UsePollingchanges the behavior? Comparing that with the default watcher would help isolate a Go watcher regression from a Docker Desktop bind-mount issue.Alex-Bond commentedon Jul 16, 2026
I have a similar problem on MacOS 15.7. I observed an issue where new TS watch exhausting system and other watchers can't start (in my case, when I start 3+ watchers, it just stops working at all).
I think the new file-watching system has some really bad issues. Maybe it makes sense to roll back or at least allow usage of the old system with a flag?
Might be related:
tsgo --watcherror: "error starting FSEvents stream" on largenode_modulessince the fswatch rewrite typescript-go#4378tsc -b --watchtakes tens of seconds to start watching on a large project-references solution (computeDesiredWatchesis O(files × dirs)) typescript-go#4614johnfav03 commentedon Jul 16, 2026
Does your issue also involve docker or is this a separate issue with running watchers in parallel?
Alex-Bond commentedon Jul 16, 2026
In my case, not in Docker, but on the native system. Based on what I can gather, the current implementation gets overwhelmed easily by circular symlinks that can happen in node_modules.
In the console, it looks like it started listening, but never receives any updates.
jakebailey commentedon Jul 17, 2026
You should file a separate issue, as the fix for Linux docker is not going to be related
Not sure what you mean, TS7 is in an entirely different language, there's no toggle to flip back to "what nodejs does".
danyreyna commentedon Jul 31, 2026
Similar issue with Docker using
node:22.22.3-slimThe project builds fine once with
tsc -p tsconfig.json --watch, but when attempting subsequent builds it stalls with this messagefanotify_mark on '/home/node/node_modules/@types/string-similarity' failed: name_to_handle_at: operation not supportedjohnfav03 commentedon Jul 31, 2026
Thanks - this is the same issue addressed by 4661. Docker’s filesystem returns
EOPNOTSUPPfromname_to_handle_at, so the affected watch will now fall back from fanotify to inotify once this PR is merged.danyreyna commentedon Aug 13, 2026
Thank you for the prompt fix John Favret (@johnfav03), but will it be available until v7.1?
jakebailey commentedon Aug 13, 2026
We have yet to discuss 7.0 patches (focusing on moving the code back to this repo and then reenabling releasing) but I would suspect this would be on the table
michael42 commentedon Nov 2, 2026
I assume I'm hitting a very similar issue inside a VM with
virtiofs, just that it fails withfanotify_mark on '/home/user/Projects' failed: invalid cross-device linkon TypeScript 7.0.2.The mount layout looks like this:
smolvm0 on /home/user type virtiofs (rw,relatime)smolvm1 on /home/user/Projects/test type virtiofs (rw,relatime)tsc --watchwatches >2000 files inside the project just fine. Then it tries to watch all the parents, too, which fails withEXDEVon the 1st parent outside the project directory and then no changes are ever detected.Maybe it can be fixed by simply checking for
EXDEVat the existing check?I wanted to include a simple reproduction script, but it seems that
ext4andtmpfsboth handle it (with FUSE it's probably doable).jakebailey commentedon Nov 2, 2026
michael42 This issue has closed; have you tried a 7.1 nightly?