Change:
constructor( @ILogService protected readonly logService: ILogService, <del> @IStorageService protected readonly storageService: IStorageService </del> <ins> @IStorageService protected readonly storageService: IStorageService, </ins> ) { super();

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.90.1 OS Version: Rocky 8 Steps to Reproduce: with the option with a string containing the desired connection token. server starts up with the specified connection token. with the option with a path to a file with the desired connection token. server starts up with a randomly-generated UUID as the connection token. The exposes a which would reasonably be expected to work, especially since does work as expected and overrides generation of a random token. In particular, in calls to handle either generating a fresh token or using a provided one. This only handles and as far as I can tell there is no code in the option handling that would replace this value with the token read from the file . The option only appears to be used in different contexts like running the downloaded servers, and the value in the ServeWebArgs version appears to only ever be overwritten by the previously-mentioned token minting code. When executing the function, it would be much preferable to provide a specified connection token in a file, for reasons similar to those in to prevent the connection token from being accessible by other users. I do not believe this is a security vulnerability, since you have to explicitly opt in to providing a connection token in a potentially unsafe manner as-is, but being able to provide one in a file would be a substantial security improvement when using specified connection tokens. I believe that this code should read in the file at the path provided by the argument and use the contents as the token when provided.

If this isn't intended to be used, I would think it should be removed from the options provided for the CLI command instead of being non-functional.
Hi Are you able to verify if this fix works? You can do so by getting the latest pre-release version of the remote-ssh extension and trying these same steps there. We want to make sure we get this bug verified, and the fix is correct, before we release this to stable. Thanks!
I checked the code-insiders build I downloaded today (1.92.0). It does not appear to have a fix for this issue and the current insiders build has the same behavior as before. I also took a look at the that closed this issue and although it is titled as relevant to this issue, it contains a that appears like it would perhaps be relevant to the remote-ssh extension but does not have any relation to this issue with connection tokens and the CLI that I can tell. I think perhaps that PR/commit got mixed up from different issue than this one.
Reopening with verification found based on authors report
huh, not sure what happened to the branch in that PR. I'll resubmit the change.