Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/kurabirko/turbo-ngc-loop

Which canary version will you have in your reproduction?

2.5.9-canary.7

Environment information

CLI:
   Version: 2.5.9-canary.7
   Path to executable: /Users/kurabirko/Developer/turbo-ngc-loop/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: npm

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 3690
   Available CPU cores: 10

Environment:
   CI: None
   Terminal (TERM): xterm-ghostty
   Terminal program (TERM_PROGRAM): ghostty
   Terminal program version (TERM_PROGRAM_VERSION): 1.2.1
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

Running the Angular compiler ngc in watch mode as a persistent task should work like how tsc works. There should be no infinite loops.

Actual behavior

Running angular compiler in watch mode through a persistent turbo task puts the compiler in an infinite loop by triggering change detection. This does not happen when I run the same task outside turbo.

I can see the change detection being triggered in the task's logs.

test:dev: message TS100: File change detected. Starting incremental compilation.
test:dev:
test:dev: message TS100: Compilation complete. Watching for file changes.
test:dev:
test:dev: message TS100: File change detected. Starting incremental compilation.
test:dev:
test:dev: message TS100: Compilation complete. Watching for file changes.
test:dev:
test:dev: message TS100: File change detected. Starting incremental compilation.
test:dev:
test:dev: message TS100: Compilation complete. Watching for file changes.
...

To Reproduce

On the example repository I provided, the test package contains a dev task to run the compiler in watch mode. Running this task outside turbo with npm run dev -w test does not cause a loop. Running the task with turbo by npx turbo run dev causes an infinite loop.

Additional context

Rolling back to 2.5.6 solves the issue, so I think this problem is essentially the same as #10914. However I don't think I am violating any boundaries, so I don't see what might be triggering the change detection.