Investigate high number of Error_FlutterDaemonTimeout events on macOS

The Error_FlutterDaemonTimeout was added to understand how many users might be affected by #4840 which is the Flutter daemon not working properly for Windows users that have a version of Git on path from msys2 (the upstream bug is documented at dart-lang/sdk#55792).

It triggers when the Flutter daemon has not produced any output after being started for 20 seconds.

While reviewing the stats today, the number of events is quite high, but concerningly, 85% of these events come from users on macOS, not Windows.

This suggests that either there is another issue leading to this, or the threshold of 20s is too low and it's being triggered falsely a lot (such as because of locks on the flutter tool during startup).

I'm unable to reproduce this on my Macbook, so I'm pushing a change ~~in the pre-release extension~~(edit: now stable too) so that when this timeout occurs, if you're on macOS, you will see this prompt (once per session):

If you see this notification

Please click the "Show Log" button to open the log. It will contain a line like this:

[12:01:11 PM] [FlutterDaemon] [Error] Request "emulator.getEmulators to daemon was not responded to within 30000ms. Daemon has been up for 33s"

The request name (and times) might be different. There might be errors recorded above this (possibly a little further up because the timeout is after 20s), in lines that are prefixed with "[FlutterDaemon]". Please post what you find here (or if there is no error, that is useful information too).

If the error is happening after a long period (for example you left VS Code open overnight) then it might be useful to record the FlutterDaemon events to their own log file. You can do this by adding the following to your VS Code settings:

"dart.flutterDaemonLogFile": "~/logs/${workspaceName}_flutter_daemon.txt",

Then restart VS Code. Next time this happens, when you click "Show Log" it should open the configured log file that contains only daemon events (and won't drop events out of the buffer used for the general log buffer).

Thank you!

Show a notification for Daemon timeouts on macOS for pre-release users

Remove pre-release check from encouraging bug reports when Flutter da…

[10:10:50] [FlutterDaemon] [Info] Spawning /Users/softwave/fvm/versions/3.35.7/bin/flutter with args ["daemon"]
[10:10:50] [FlutterDaemon] [Info] ..  in /Users/softwave/fvm/versions/3.35.7
[10:10:50] [FlutterDaemon] [Info] ..  with {"toolEnv":{"FLUTTER_HOST":"VSCode","PUB_ENVIRONMENT":"vscode.dart-code","FLUTTER_ROOT":"/Users/softwave/fvm/versions/3.35.7","DASH__IDE_NAME":"Visual Studio Code","DASH__IDE_VERSION":"1.120.0","DASH__PLUGIN_NAME":"Dart-Code","DASH__PLUGIN_VERSION":"3.134.0","DASH__IDE_ENVIRONMENT":"desktop","DASH__TOOL":"vscode-plugins","DASH__SUPPRESS_ANALYTICS":"false"}}
[10:10:50] [FlutterDaemon] [Info]     PID: 16709

[10:10:51] [FlutterDaemon] [Info] <== [{"event":"daemon.connected","params":{"version":"0.6.1","pid":17134}}]
[10:10:51] [FlutterDaemon] [Info] ==> [{"id":"1","method":"device.enable"}]

[10:10:52] [FlutterDaemon] [Info] <== [{"event":"daemon.logMessage","params":{"level":"status","message":"Device daemon started."}}]
[10:10:52] [FlutterDaemon] [Info] <== [{"id":"1"}]
[10:10:54] [FlutterDaemon] [Info] ==> [{"id":"2","method":"emulator.getEmulators"}]
[10:10:54] [FlutterDaemon] [Info] ==> [{"id":"3","method":"daemon.getSupportedPlatforms","params":{"projectRoot":"/Users/softwave/Projects/Intesa/digical_frontend_mobile"}}]
->> NOTE: Some line hidden for privacy
[10:11:14] [FlutterDaemon] [Error] Request "emulator.getEmulators" to daemon was not responded to within 20000ms. Daemon has been up for 23.593s when this timeout fired."
[10:11:14] [FlutterDaemon] [Warn] Prompting to reload: (The Flutter daemon did not respond to a request within 20s. Please post any "FlutterDaemon" errors from the log to [this GitHub issue](https://github.com/Dart-Code/Dart-Code/issues/5793#issuecomment-3527504661).) (actions: Restart Extension, Show Log)

@lukluca

@lukluca thanks for the log! Do you see this issue often? Is it usually when your machine is busy (or after a fresh reboot)?

If the issue is just that it is slow, then I think my changes for #6048 will improve things in the next release.

chore(cursor): document widget preview daemon troubleshooting

macOS report — Flutter daemon 120s timeout (Cursor / Dart-Code 3.136.1)

Environment

macOS 26.5.1 (25F80), arm64 (Mac15,9)
Cursor (VS Code extension host)
Dart-Code 3.136.1 + Flutter extension 3.136.0
flutter on PATH: /opt/homebrew/bin/flutter → /opt/homebrew/Caskroom/flutter/3.44.3/flutter
Also present: /opt/homebrew/share/flutter (Homebrew share install)
Flutter 3.44.3 stable, Dart 3.12.2
Large Flutter monorepo workspace (sea_trials_universal, melos, 100+ packages)

Symptom
Popup: "The Flutter daemon did not respond to a request within 120s. Please post any FlutterDaemon errors from the log to this GitHub issue."

FlutterDaemon log output (Cursor → Output → flutter daemon):

Device daemon started.

(No further [FlutterDaemon] lines; dart.flutterDaemonLogFile is unset/default null.)

Related extension-host errors (exthost.log, stack while handling daemon notifications during window reload):

Canceled: Canceled
  at FlutterDaemon.notify (.../dart-code.dart-code-3.136.1-universal/out/dist/extension.js:24250:40)
  at FlutterDaemon.handleNotification (...:12282:28)
  at FlutterDaemon.handleMessage (...:24190:27)
  at FlutterDaemon.processMessageBuffer (...:24163:74)
  at FlutterDaemon.handleStdOut (...:24101:18)

Likely contributing factor — many stale daemon / device processes
At time of investigation, 20+ flutter_tools.snapshot daemon and devices --machine processes were still running, including many pointing at a removed SDK path:

/opt/homebrew/Caskroom/flutter/3.22.2/flutter (directory no longer exists; only 3.44.3 remains in Caskroom)

Example PIDs (all idle, hours old): daemon 18229, 21295, 43012, 50675, 56209, 68196, 77029, … and matching devices --machine children.

Meanwhile active Cursor session daemons use /opt/homebrew/share/flutter/....

CLI reproduction

flutter --version — OK (fast)
flutter doctor -v — hangs (no output after 80s+)
flutter devices — hangs (no output within 10s timeout)

Prior crash (possibly unrelated)
~/Library/Logs/DiagnosticReports/dartaotruntime-2026-06-17-130443.ips — dartaotruntime killed with SIGKILL (Code Signature Invalid) while running dart:analysis_server_aot.dart.snapshot under Cursor.

Notes

Multiple IDE sessions (Cursor + Claude Code) each appear to spawn their own daemon; uninstalling/upgrading Flutter via Homebrew left orphaned daemon processes from the old path.
Happy to capture a verbose log with dart.flutterDaemonLogFile set if that would help.

Follow-up — hang point identified

After killing 22 stale flutter_tools.snapshot daemon / devices --machine processes (many referencing removed /opt/homebrew/Caskroom/flutter/3.22.2/flutter), flutter devices -v still hangs. Verbose log ends at:

executing: /usr/bin/arch -arm64e xcrun simctl list devices booted

Running xcrun simctl list devices booted directly also times out with no output (10s+). So device enumeration appears blocked in CoreSimulator / simctl, not in Dart-Code itself.

macOS 26.5.1 (25F80). Flutter uses /opt/homebrew/share/flutter at runtime even when PATH flutter points at Caskroom 3.44.3.

@hughesyadaddy

@hughesyadaddy thanks for the digging! Are you able to reliably reproduce this? Or do you know under what conditions it hangs?

It looks like the command is spawned here in Flutter:

https://github.com/flutter/flutter/blob/a658b9e5f9beee26f9221103d375b0d1ef8eb38c/packages/flutter_tools/lib/src/ios/simulators.dart#L155

macOS 26.5.1 (25F80). Flutter uses /opt/homebrew/share/flutter at runtime even when PATH flutter points at Caskroom 3.44.3.

I'm not sure what you mean by "Flutter" here, do you mean the VS Code extensions? If you have already run flutter pub get in a project such that the .dart_tool/package_config.json file already points at a Flutter SDK, we will use that one over the one on PATH. If we don't do that, the IDE would be spawning one version of Flutter while the analysis server would be using the one resolved by the package config.

If you want to change the SDK being used for a project, you should re-run flutter pub get or flutter clean and then reload or restart VS Code/the extension.

Running xcrun simctl list devices booted directly also times out with no output (10s+).

Also, just to be clear - when you say "times out", do you mean it fails and exits, or it hangs and never completes? (if it completes, then I don't think it should cause a complete hang here, only a delay of 10s?)

FlutterDaemon error from the VS Code log:

[13:48:00] [FlutterDaemon] [Error] Request "emulator.getEmulators" to daemon was not responded to within 120s. Daemon has been up for 125.204s when this timeout fired.

Context: Dart Code / Flutter extension 3.144.0, VS Code 1.141.0 on macOS; Dart 3.11.5 and Flutter 3.41.9. The daemon started at 13:45:54 and connected at 13:45:55; it then received emulator.getEmulators requests while supported-platform checks were running across the workspace.

@pengjinning

@pengjinning thanks for the info - do you see this error frequently, or was this a one-off? If it happens frequently, is it usually only the first time after booting, or every time you open a Flutter project?

Navigation Menu

Repository navigation

Investigate high number of Error_FlutterDaemonTimeout events on macOS #5793

If you see this notification

36 remaining items

macOS report — Flutter daemon 120s timeout (Cursor / Dart-Code 3.136.1)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Investigate high number of Error_FlutterDaemonTimeout events on macOS #5793

Description

Activity

DanTup commented on Nov 13, 2025

If you see this notification

36 remaining items

lukluca commented on May 15, 2026

DanTup commented on May 18, 2026

hughesyadaddy commented on Jun 23, 2026

macOS report — Flutter daemon 120s timeout (Cursor / Dart-Code 3.136.1)

hughesyadaddy commented on Jun 23, 2026

DanTup commented on Jun 24, 2026

DanTup commented on Jun 24, 2026

pengjinning commented on Oct 12, 2026

DanTup commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions