Edit: My current proposal:

Based on recent discussions, I think using env variables makes most sense here, and I think we should try to standardise on a set of env vars both for the application name discussed here, and as a replacement for the other mechanisms we use today (--client-id for server, FLUTTER_HOST for flutter, PUB_ENVIRONMENT for pub). Using env vars mean we could update the IDEs once with all of these, and then migrate tools over in time, rather than have to coordinate changes and handle different versions that CLI flags would require.

Based on the info VS Code has, I think there are probably 6 useful pieces of information:

• The name of the application/product
• The version of the application/product
• The "name" of the plugin/client
• The version of the plugin/client
• The ID that identifies the "tool" used for analytics grouping
• Information about the kind of environment (desktop, web, docker, wsl)... This can be useful to understand if Linux users are actually on Windows (WSL) which can cause some kinds of issues or if the extension host is remote from the UI (eg. could affect latency and payload sizes might matter more)

So perhaps something like:

Questions:

• Should we keep the -Remote suffix on DASH__PLUGIN_NAME for VS Code? It feels like a hacky way to describe the environment and maybe DASH__IDE_ENVIRONMENT is a better (and more detailed) way to capture these environments.
  • No, drop it from the env var (keep in --client-id for compatibility)
• Should we change "VSCode" to something that better reflects Dart-Code for the env name to reduce confusion (even if this just maps to "VSCode" internally to avoid renaming the tool?)
  • Yes, we should us something specific to the plugin (probably there should be a mapping in unified analytics?)
• Currently we pass an IDE param to DevTools - should this use these new values? Or should we stop using the querystring and let the server read from the env vars?
• We also pass an IDE in the querystring for surveys (again, always "VSCode" when it could be Antigravity), should that change?
• If something like the MCP Server (which was spawned from a CLI in an external terminal) spawns an analysis server (or pub, or flutter), what should it set?
• If the user runs pub or flutter in an IDEs embedded terminal, should these env vars also be set?
  • No, embedded terminals should be treated like external terminals and user commands are user invocations, not editor invocations

Original message:

When we start the analysis server, was pass a "Client ID" which can be used in diagnostic reports and analytics. Currently this is one of two strings, depending on whether we're in a remote session (ssh, docker, Codespaces, etc.) or not:

It would be more helpful if we provided more specific client IDs for clients like Cursor and Firebase Studio since they often have customised code and may behave different (or have different bugs).

VS Code's API has env.appName which is usually customised by these other editors and we could perhaps pass instead. Since the analysis server currently switches on this string, we can only change what we pass when we know we're using a version of server that supports these new strings (or a fallback for strings it does not recognise).

Here are some examples of env.appNames that have been recorded:

We could also consider what we do with the current "-Remote" suffix if we change this (if we just use appName as-is, there will be no indication of being in a remote workspace.. usually we infer this from env.remoteName or env.appHost).