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
The device_id field documented in the debug adapter schema is read from user config and forwarded to Flutter's DAP as deviceId, but Flutter's DAP never reads this field. As a result, flutter run is invoked without -d <id> and falls back to its auto-pick logic — so users either hit "More than one device connected" errors or silently launch on the wrong device.
With both macOS desktop and Chrome web available, launching this task fails with:
More than one device connected; please specify a device with the '-d <deviceId>' flag, or use '-d all' to act on all devices.
macOS (desktop) • macos • darwin-arm64 • macOS 26.1 25B78 darwin-arm64
Chrome (web) • chrome • web-javascript • Google Chrome 147.0.7727.138
Exited (1).
With an Android emulator additionally connected, the macOS task instead launches on the emulator (auto-pick of the only ephemeral device) — device_id: "macos" is still ignored.
Root cause (verified end-to-end)
Extension side (src/dart.rsget_dap_binary) reads device_id and emits it as deviceId in the launch JSON sent to flutter debug_adapter. ✅
Flutter side (flutter_tools/lib/src/debug_adapters/flutter_adapter.dart, launchImpl) builds the flutter run --machine ... argv from toolArgs and args.toolArgs (i.e. user-provided toolArgs). It never reads the deviceId field — grep -r deviceId packages/flutter_tools/lib/src/debug_adapters/ returns a single hit, and it's a comment.
Verified by sending hand-built DAP launch requests to flutter debug_adapter:
Launch JSON
Result
{"deviceId": "macos", ...}
"More than one device connected", exits
{"toolArgs": ["-d", "macos"], ...}
macOS app launches successfully
Tested on Flutter 3.41.6 stable, Zed 1.1.6, dart extension 0.3.6.
Proposed fix
In src/dart.rsget_dap_binary, translate device_id into toolArgs: ["-d", device_id] in the launch JSON. Two viable shapes:
Implicit: keep the device_id config field; in the extension, append ["-d", device_id] to a toolArgs array sent to the DAP.
Summary
The
device_idfield documented in the debug adapter schema is read from user config and forwarded to Flutter's DAP asdeviceId, but Flutter's DAP never reads this field. As a result,flutter runis invoked without-d <id>and falls back to its auto-pick logic — so users either hit "More than one device connected" errors or silently launch on the wrong device.Reproduction
.zed/debug.json:{ "label": "UI Demo: Debug on macOS", "adapter": "Dart", "type": "flutter", "request": "launch", "program": "lib/main.dart", "cwd": "$ZED_WORKTREE_ROOT/path/to/flutter-project", "device_id": "macos", "useFvm": true }With both macOS desktop and Chrome web available, launching this task fails with:
With an Android emulator additionally connected, the macOS task instead launches on the emulator (auto-pick of the only ephemeral device) —
device_id: "macos"is still ignored.Root cause (verified end-to-end)
src/dart.rsget_dap_binary) readsdevice_idand emits it asdeviceIdin the launch JSON sent toflutter debug_adapter. ✅flutter_tools/lib/src/debug_adapters/flutter_adapter.dart,launchImpl) builds theflutter run --machine ...argv fromtoolArgsandargs.toolArgs(i.e. user-providedtoolArgs). It never reads thedeviceIdfield —grep -r deviceId packages/flutter_tools/lib/src/debug_adapters/returns a single hit, and it's a comment.Verified by sending hand-built DAP launch requests to
flutter debug_adapter:{"deviceId": "macos", ...}{"toolArgs": ["-d", "macos"], ...}Tested on Flutter 3.41.6 stable, Zed 1.1.6, dart extension 0.3.6.
Proposed fix
In
src/dart.rsget_dap_binary, translatedevice_idintotoolArgs: ["-d", device_id]in the launch JSON. Two viable shapes:device_idconfig field; in the extension, append["-d", device_id]to atoolArgsarray sent to the DAP.toolArgsfield in the schema (which Fix debug adapter config bugs and add missing config options #66 already proposes) and let users writetoolArgs: ["-d", "macos"]themselves. Less convenient, but more flexible.Ideally both — auto-translate
device_idand supporttoolArgsfor other flags (--flavor,--dart-define, etc.).Related work
-d <device_id>viatoolArgs" and verifiesdevice_id: "macos"in its test plan.toolArgsconfig support, which would unblock users as a manual workaround.Either approach (or both combined) would close this issue.