Question:
Testing open show outline and have sticky scroll enabled scroll the cell with "# Header " into view delete the cell :bug: the sticky scroll breaks, the error below is printed <img width="1482" alt="Screenshot 2024-04-23 at 08 51 18" src=""
I'm unable to repro this. Please can you share a screen recording of the steps. Perhaps recoding from opehning the notebook to selecting and deleting. Thanks.
Looking at the stacktrace tells me this is coming here which means the model had been already
following the steps above (empty profile) always reproduce the error (console) for me. The screen cheese shows in sticky scroll and/or other paces of the outline tree

} })); <del> this.delayRecomputeActive(); </del> <ins> this._recomputeActive(); </ins> } private _recomputeActive(): { changeEventTriggered: boolean } {


Question: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I'm creator of [SWC][] and I want vscode to use the officla JSON schema introduced by for by default. I'm going to create a PR. [SWC]

"url": "./schemas/jsconfig.schema.json" }, { <ins> "fileMatch": ".swcrc", "url": "https://swc.rs/schema.json" }, { </ins> "fileMatch": "typedoc.json", "url": "https://typedoc.org/schema.json" }


Question:
If I open a Dart project, right-click on a folder in the explorer and then "Run Tests", I see: ! However if I open the test explorer tree first and then try again, everything works. It appears that "Run Tests" from explorer does not trigger the to allow initial test discovery. ( I presume this is a bug and not intended?)
even after I've shown the explorer tree and triggered discovery, it seems like "Run Tests" now works on the "tests" folder, but not on an individual test file (even though I've confirmed the URI for that file is being set when creating the test tree item). Is there something else I need to do besides having the URI on the test file node?
Does this reproduce on Insiders for you? It should be fixed with
looks like that fix handles the second issue above (running the file now works), however the original issue above is still an issue - if I don't trigger discovery of the tests before using it, it reports no tests found.
Fix works for me, thanks! :) /verified

// tests already encompass their children. if (!test) { // no-op <del> } else if (!test.item.uri) { queue.push(test.children.values()); continue; } else if (ident.extUri.isEqualOrParent(test.item.uri, uri)) { </del> <ins> } else if (test.item.uri && ident.extUri.isEqualOrParent(test.item.uri, uri)) { </ins> yield test; <del> } else if (ident.extUri.isEqualOrParent(uri, test.item.uri)) { </del> <ins> } else if (!test.item.uri || ident.extUri.isEqualOrParent(uri, test.item.uri)) { </ins> if (test.expand === TestItemExpandState.Expandable) { await testService.collection.expand(test.item.extId, 1); }


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

use std::sync::{Arc, Mutex}; use std::time::{Duration, Instant}; <del> use const_format::concatcp; </del> use hyper::service::{make_service_fn, service_fn}; use hyper::{Body, Request, Response, Server}; use tokio::io::{AsyncBufReadExt, BufReader};


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

/// Number of bytes for the secret keys. See workbench.ts for their usage. const SECRET_KEY_BYTES: usize = 32; /// Path to mint the key combining server and client parts. <del> const SECRET_KEY_MINT_PATH: &str = "/_vscode-cli/mint-key"; </del> <ins> const SECRET_KEY_MINT_PATH: &str = "_vscode-cli/mint-key"; </ins> /// Cookie set to the `SECRET_KEY_MINT_PATH` const PATH_COOKIE_NAME: &str = "vscode-secret-key-path"; <del> /// Cookie set to the `SECRET_KEY_MINT_PATH` const PATH_COOKIE_VALUE: &str = concatcp!( PATH_COOKIE_NAME, "=", SECRET_KEY_MINT_PATH, "; SameSite=Strict; Path=/" ); </del> /// HTTP-only cookie where the client's secret half is stored. const SECRET_KEY_COOKIE_NAME: &str = "vscode-cli-secret-half";


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

/// Handler function for an inbound request async fn handle(ctx: HandleContext, req: Request<Body>) -> Result<Response<Body>, Infallible> { let client_key_half = get_client_key_half(&req); <del> let mut res = match req.uri().path() { SECRET_KEY_MINT_PATH => handle_secret_mint(ctx, req), _ => handle_proxied(ctx, req).await, </del> <ins> let path = req.uri().path(); let mut res = if path.starts_with(&ctx.cm.base_path) && path.get(ctx.cm.base_path.len()..).unwrap_or_default() == SECRET_KEY_MINT_PATH { handle_secret_mint(&ctx, req) } else { handle_proxied(&ctx, req).await </ins> }; <del> append_secret_headers(&mut res, &client_key_half); </del> <ins> append_secret_headers(&ctx.cm.base_path, &mut res, &client_key_half); </ins> Ok(res) } <del> async fn handle_proxied(ctx: HandleContext, req: Request<Body>) -> Response<Body> { </del> <ins> async fn handle_proxied(ctx: &HandleContext, req: Request<Body>) -> Response<Body> { </ins> let release = if let Some((r, _)) = get_release_from_path(req.uri().path(), ctx.cm.platform) { r } else {


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

} } <del> fn handle_secret_mint(ctx: HandleContext, req: Request<Body>) -> Response<Body> { </del> <ins> fn handle_secret_mint(ctx: &HandleContext, req: Request<Body>) -> Response<Body> { </ins> use sha2::{Digest, Sha256}; let mut hasher = Sha256::new();


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

/// Appends headers to response to maintain the secret storage of the workbench: /// sets the `PATH_COOKIE_VALUE` so workbench.ts knows about the 'mint' endpoint, /// and maintains the http-only cookie the client will use for cookies. <del> fn append_secret_headers(res: &mut Response<Body>, client_key_half: &SecretKeyPart) { </del> <ins> fn append_secret_headers( base_path: &str, res: &mut Response<Body>, client_key_half: &SecretKeyPart, ) { </ins> let headers = res.headers_mut(); headers.append( hyper::header::SET_COOKIE, <del> PATH_COOKIE_VALUE.parse().unwrap(), </del> <ins> format!( "{}={}{}; SameSite=Strict; Path=/", PATH_COOKIE_NAME, base_path, SECRET_KEY_MINT_PATH, ) .parse() .unwrap(), </ins> ); headers.append( hyper::header::SET_COOKIE,


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

pub platform: Platform, pub log: log::Logger, args: ServeWebArgs, <ins> /// Server base path, ending in `/` base_path: String, </ins> /// Cache where servers are stored cache: DownloadCache, /// Mapping of (Quality, Commit) to the state each server is in


Question:
The command was augmented with the argument here in Because the does not include the , any attempts to mint a key will result in a 404 if the server-base-path is set. I think this is the reason why I am experiencing an issue that any sign-in attempt in the browser (e.g., Github Copilot, Settings Sync) do not persist between page refreshes. <!-- 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.89.1 OS Version: x64 Steps to Reproduce: the browser, observe 404s to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
assigned to you since you approved the original PR

(release.quality, release.commit.clone()) } <ins> fn normalize_base_path(p: &str) -> String { let p = p.trim_matches('/'); if p.is_empty() { return "/".to_string(); } format!("/{}/", p.trim_matches('/')) } </ins> impl ConnectionManager { pub fn new(ctx: &CommandContext, platform: Platform, args: ServeWebArgs) -> Arc<Self> { <ins> let base_path = normalize_base_path(args.server_base_path.as_deref().unwrap_or_default()); </ins> Arc::new(Self { platform, args, <ins> base_path, </ins> log: ctx.log.clone(), cache: DownloadCache::new(ctx.paths.web_server_storage()), update_service: UpdateService::new(


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

import { Button } from '../../../../base/browser/ui/button/button.js'; import { ITreeElement } from '../../../../base/browser/ui/tree/tree.js'; import { Action } from '../../../../base/common/actions.js'; <del> import { Delayer } from '../../../../base/common/async.js'; </del> <ins> import { Delayer, raceTimeout } from '../../../../base/common/async.js'; </ins> import { CancellationToken, CancellationTokenSource } from '../../../../base/common/cancellation.js'; import { fromNow } from '../../../../base/common/date.js'; import { isCancellationError } from '../../../../base/common/errors.js';


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

import { AbstractSettingRenderer, HeightChangeParams, ISettingLinkClickEvent, resolveConfiguredUntrustedSettings, createTocTreeForExtensionSettings, resolveSettingsTree, SettingsTree, SettingTreeRenderers } from './settingsTree.js'; import { ISettingsEditorViewState, parseQuery, SearchResultIdx, SearchResultModel, SettingsTreeElement, SettingsTreeGroupChild, SettingsTreeGroupElement, SettingsTreeModel, SettingsTreeSettingElement } from './settingsTreeModels.js'; import { createTOCIterator, TOCTree, TOCTreeModel } from './tocTree.js'; <del> import { CONTEXT_SETTINGS_EDITOR, CONTEXT_SETTINGS_ROW_FOCUS, CONTEXT_SETTINGS_SEARCH_FOCUS, CONTEXT_TOC_ROW_FOCUS, ENABLE_LANGUAGE_FILTER, EXTENSION_SETTING_TAG, FEATURE_SETTING_TAG, ID_SETTING_TAG, IPreferencesSearchService, ISearchProvider, LANGUAGE_SETTING_TAG, MODIFIED_SETTING_TAG, POLICY_SETTING_TAG, REQUIRE_TRUSTED_WORKSPACE_SETTING_TAG, SETTINGS_EDITOR_COMMAND_CLEAR_SEARCH_RESULTS, SETTINGS_EDITOR_COMMAND_SUGGEST_FILTERS, WORKSPACE_TRUST_SETTING_TAG, getExperimentalExtensionToggleData } from '../common/preferences.js'; </del> <ins> import { CONTEXT_SETTINGS_EDITOR, CONTEXT_SETTINGS_ROW_FOCUS, CONTEXT_SETTINGS_SEARCH_FOCUS, CONTEXT_TOC_ROW_FOCUS, ENABLE_LANGUAGE_FILTER, EXTENSION_FETCH_TIMEOUT_MS, EXTENSION_SETTING_TAG, FEATURE_SETTING_TAG, ID_SETTING_TAG, IPreferencesSearchService, ISearchProvider, LANGUAGE_SETTING_TAG, MODIFIED_SETTING_TAG, POLICY_SETTING_TAG, REQUIRE_TRUSTED_WORKSPACE_SETTING_TAG, SETTINGS_EDITOR_COMMAND_CLEAR_SEARCH_RESULTS, SETTINGS_EDITOR_COMMAND_SUGGEST_FILTERS, WORKSPACE_TRUST_SETTING_TAG, getExperimentalExtensionToggleData } from '../common/preferences.js'; </ins> import { settingsHeaderBorder, settingsSashBorder, settingsTextInputBorder } from '../common/settingsEditorColorRegistry.js'; import { IEditorGroup, IEditorGroupsService } from '../../../services/editor/common/editorGroupsService.js'; import { IOpenSettingsOptions, IPreferencesService, ISearchResult, ISetting, ISettingsEditorModel, ISettingsEditorOptions, ISettingsGroup, SettingMatchType, SettingValueType, validateSettingsEditorOptions } from '../../../services/preferences/common/preferences.js';


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

} const extensionId = extension.identifier.id; <ins> // prevent race between extension update handler and this (onConfigUpdate) handler await this.refreshInstalledExtensionsList(); </ins> const extensionInstalled = this.installedExtensionIds.includes(extensionId); // Drill down to see whether the group and setting already exist


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

// Create the entry. extensionInstalled is false in this case. let manifest: IExtensionManifest | null = null; try { <del> manifest = await this.extensionGalleryService.getManifest(extension, CancellationToken.None); </del> <ins> manifest = await raceTimeout( this.extensionGalleryService.getManifest(extension, CancellationToken.None), EXTENSION_FETCH_TIMEOUT_MS ) ?? null; </ins> } catch (e) { // Likely a networking issue. // Skip adding a button for this extension to the Settings editor. continue; } <ins> if (manifest === null) { continue; } </ins> const contributesConfiguration = manifest?.contributes?.configuration; let groupTitle: string | undefined;


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { raceTimeout } from '../../../../base/common/async.js'; </ins> import { CancellationToken } from '../../../../base/common/cancellation.js'; import { IStringDictionary } from '../../../../base/common/collections.js'; import { IExtensionRecommendations } from '../../../../base/common/product.js';


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

export const ENABLE_LANGUAGE_FILTER = true; export const ENABLE_EXTENSION_TOGGLE_SETTINGS = true; <ins> export const EXTENSION_FETCH_TIMEOUT_MS = 1000; </ins> export type ExtensionToggleData = { settingsEditorRecommendedExtensions: IStringDictionary<IExtensionRecommendations>;


Question:
<!-- 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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.

// Recommend prerelease if not on Stable. const isStable = productService.quality === 'stable'; try { <del> const [extension] = await extensionGalleryService.getExtensions([{ id: extensionId, preRelease: !isStable }], CancellationToken.None); if (extension) { recommendedExtensionsGalleryInfo[key] = extension; </del> <ins> const extensions = await raceTimeout(extensionGalleryService.getExtensions([{ id: extensionId, preRelease: !isStable }], CancellationToken.None), EXTENSION_FETCH_TIMEOUT_MS); if (extensions?.length === 1) { recommendedExtensionsGalleryInfo[key] = extensions[0]; </ins> } else { // same as network connection fail. we do not want a blank settings page: https://github.com/microsoft/vscode/issues/195722 // so instead of returning partial data we return undefined here


Question: You should not be assuming that the editor for which the action is being run for is the active editor. Make sure to correctly extract the context from the arguments passed to the script. The run method should be defined the following way: You can get the correct context with and resolve it with Make sure to adopt this for the following MultiDiffActions: - You can test that it works correctly with and 2 editor groups

import { Action2, MenuId } from 'vs/platform/actions/common/actions'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; <ins> import { getCommandsContext, resolveCommandsContext } from 'vs/workbench/browser/parts/editor/editorCommands'; import { IEditorCommandsContext } from 'vs/workbench/common/editor'; </ins> import { TextFileEditor } from 'vs/workbench/contrib/files/browser/editors/textFileEditor'; import { MultiDiffEditor } from 'vs/workbench/contrib/multiDiffEditor/browser/multiDiffEditor'; import { MultiDiffEditorInput } from 'vs/workbench/contrib/multiDiffEditor/browser/multiDiffEditorInput'; <ins> import { IEditorGroupsService } from 'vs/workbench/services/editor/common/editorGroupsService'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; export class GoToFileAction extends Action2 {


Question: You should not be assuming that the editor for which the action is being run for is the active editor. Make sure to correctly extract the context from the arguments passed to the script. The run method should be defined the following way: You can get the correct context with and resolve it with Make sure to adopt this for the following MultiDiffActions: - You can test that it works correctly with and 2 editor groups

}); } <del> async run(accessor: ServicesAccessor, ...args: any[]): Promise<void> { const editorService = accessor.get(IEditorService); const activeEditor = editorService.activeEditor; </del> <ins> async run(accessor: ServicesAccessor, resourceOrContext?: URI | IEditorCommandsContext, context?: IEditorCommandsContext): Promise<void> { const { editor } = resolveCommandsContext(accessor.get(IEditorGroupsService), getCommandsContext(accessor, resourceOrContext, context)); </ins> <del> if (activeEditor instanceof MultiDiffEditorInput) { const viewModel = await activeEditor.getViewModel(); </del> <ins> if (editor instanceof MultiDiffEditorInput) { const viewModel = await editor.getViewModel(); </ins> viewModel.collapseAll(); } }


Question: You should not be assuming that the editor for which the action is being run for is the active editor. Make sure to correctly extract the context from the arguments passed to the script. The run method should be defined the following way: You can get the correct context with and resolve it with Make sure to adopt this for the following MultiDiffActions: - You can test that it works correctly with and 2 editor groups

}); } <del> async run(accessor: ServicesAccessor, ...args: any[]): Promise<void> { const editorService = accessor.get(IEditorService); const activeEditor = editorService.activeEditor; </del> <ins> async run(accessor: ServicesAccessor, resourceOrContext?: URI | IEditorCommandsContext, context?: IEditorCommandsContext): Promise<void> { const { editor } = resolveCommandsContext(accessor.get(IEditorGroupsService), getCommandsContext(accessor, resourceOrContext, context)); </ins> <del> if (activeEditor instanceof MultiDiffEditorInput) { const viewModel = await activeEditor.getViewModel(); </del> <ins> if (editor instanceof MultiDiffEditorInput) { const viewModel = await editor.getViewModel(); </ins> viewModel.expandAll(); } }


Question: make an inline chat request that changes code select the re-generate action :bug: the previous changes aren't undone

} }); } else if (e.kind === 'removeRequest') { <del> // TODO@jrieken this currently is buggy when removing not the very last request/response // if (this._session!.lastExchange?.response instanceof ReplyResponse) { // 	try { // 		this._session!.hunkData.ignoreTextModelNChanges = true; // 		await this._strategy!.undoChanges(this._session!.lastExchange.response.modelAltVersionId); // 	} finally { // 		this._session!.hunkData.ignoreTextModelNChanges = false; // 	} // } </del> <ins> // TODO@jrieken this is buggy/weird when having code changes from multiple turns because // logically they are all the same hunks this._strategy?.cancel(); </ins> } }));


Question: make an inline chat request that changes code select the re-generate action :bug: the previous changes aren't undone

import { ICommandService } from 'vs/platform/commands/common/commands'; import { TestCommandService } from 'vs/editor/test/browser/editorTestServices'; import { INotebookEditorService } from 'vs/workbench/contrib/notebook/browser/services/notebookEditorService'; <ins> import { RerunAction } from 'vs/workbench/contrib/inlineChat/browser/inlineChatActions'; </ins> suite('InteractiveChatController', function () {


Question: make an inline chat request that changes code select the re-generate action :bug: the previous changes aren't undone

assert.ok(model.getValue().includes('MANUAL')); }); <ins> test('re-run should discard pending edits', async function () { let count = 1; store.add(chatAgentService.registerDynamicAgent({ id: 'testEditorAgent2', ...agentData }, { async invoke(request, progress, history, token) { progress({ kind: 'textEdit', uri: model.uri, edits: [{ range: new Range(1, 1, 1, 1), text: request.message + (count++) }] }); return {}; }, })); ctrl = instaService.createInstance(TestController, editor); const rerun = new RerunAction(); model.setValue(''); const p = ctrl.waitFor([...TestController.INIT_SEQUENCE, State.SHOW_REQUEST, State.SHOW_RESPONSE, State.WAIT_FOR_INPUT]); const r = ctrl.run({ message: 'PROMPT_', autoSend: true }); await p; assert.strictEqual(model.getValue(), 'PROMPT_1'); const p2 = ctrl.waitFor([State.SHOW_REQUEST, State.SHOW_RESPONSE, State.WAIT_FOR_INPUT]); await instaService.invokeFunction(rerun.runInlineChatCommand, ctrl, editor); await p2; assert.strictEqual(model.getValue(), 'PROMPT_2'); ctrl.finishExistingSession(); await r; }); </ins> });


Question: My extension provides document links by calling on with a implementation. It provides tooltip, because it always sets the field to the return values of . I confirmed it works (tooltip is shown) by actually running the extension. I wrote an integration test for it. It activates the extension and calls where is the URI of an opened document that our extension supports. It returns the expected objects except those lack the field. Am I missing anything, or is it a bug of the command that it doesn't set the field? Version: 1.89.1 Commit: User Agent: Mozilla/5.0 (X11; CrOS x86_64 .0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Embedder: server-distro <!-- generated by web issue reporter --

// ignore } } <del> return new types.DocumentLink(Range.to(link.range), target); </del> <ins> const result = new types.DocumentLink(Range.to(link.range), target); result.tooltip = link.tooltip; return result; </ins> } }


Question: My extension provides document links by calling on with a implementation. It provides tooltip, because it always sets the field to the return values of . I confirmed it works (tooltip is shown) by actually running the extension. I wrote an integration test for it. It activates the extension and calls where is the URI of an opened document that our extension supports. It returns the expected objects except those lack the field. Am I missing anything, or is it a bug of the command that it doesn't set the field? Version: 1.89.1 Commit: User Agent: Mozilla/5.0 (X11; CrOS x86_64 .0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Embedder: server-distro <!-- generated by web issue reporter --

}); <ins> testApiCmd('DocumentLink[] vscode.executeLinkProvider returns lack tooltip #213970', async function () { disposables.push(extHost.registerDocumentLinkProvider(nullExtensionDescription, defaultSelector, <vscode.DocumentLinkProvider>{ provideDocumentLinks(): any { const link = new types.DocumentLink(new types.Range(0, 0, 0, 20), URI.parse('foo:bar')); link.tooltip = 'Link Tooltip'; return [link]; } })); await rpcProtocol.sync(); const links1 = await commands.executeCommand<vscode.DocumentLink[]>('vscode.executeLinkProvider', model.uri); assert.strictEqual(links1.length, 1); assert.strictEqual(links1[0].tooltip, 'Link Tooltip'); }); </ins> test('Color provider', function () {


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

const isAllowed = chatAgentNameService.getAgentNameRestriction(agent); let name = `${isAllowed ? agent.name : getFullyQualifiedId(agent)}`; <del> const isDupe = isAllowed && chatAgentService.getAgentsByName(agent.name).length > 1; </del> <ins> const isDupe = isAllowed && chatAgentService.agentHasDupeName(agent.id); </ins> if (isDupe) { name += ` (${agent.publisherDisplayName})`; }


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

return { suggestions: agents.map((agent, i): CompletionItem => { <del> const { label: agentLabel, isDupe } = getAgentCompletionDetails(agent, agents, this.chatAgentNameService); </del> <ins> const { label: agentLabel, isDupe } = this.getAgentCompletionDetails(agent); </ins> return { // Leading space is important because detail has no space at the start by design label: isDupe ?


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

const justAgents: CompletionItem[] = agents .filter(a => !a.isDefault) .map(agent => { <del> const { label: agentLabel, isDupe } = getAgentCompletionDetails(agent, agents, this.chatAgentNameService); </del> <ins> const { label: agentLabel, isDupe } = this.getAgentCompletionDetails(agent); </ins> const detail = agent.description; return {


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

return { suggestions: justAgents.concat( agents.flatMap(agent => agent.slashCommands.map((c, i) => { <del> const { label: agentLabel, isDupe } = getAgentCompletionDetails(agent, agents, this.chatAgentNameService); </del> <ins> const { label: agentLabel, isDupe } = this.getAgentCompletionDetails(agent); </ins> const withSlash = `${chatSubcommandLeader}${c.name}`; return { label: { label: withSlash, description: agentLabel, detail: isDupe ? ` (${agent.publisherDisplayName})` : undefined },


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

} })); } <ins> private getAgentCompletionDetails(agent: IChatAgentData): { label: string; isDupe: boolean } { const isAllowed = this.chatAgentNameService.getAgentNameRestriction(agent); const agentLabel = `${chatAgentLeader}${isAllowed ? agent.name : getFullyQualifiedId(agent)}`; const isDupe = isAllowed && this.chatAgentService.agentHasDupeName(agent.id); return { label: agentLabel, isDupe }; } </ins> } Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(AgentCompletions, LifecyclePhase.Eventually);


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

} Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(VariableCompletions, LifecyclePhase.Eventually); <del> function getAgentCompletionDetails(agent: IChatAgentData, otherAgents: IChatAgentData[], chatAgentNameService: IChatAgentNameService): { label: string; isDupe: boolean } { const isAllowed = chatAgentNameService.getAgentNameRestriction(agent); const agentLabel = `${chatAgentLeader}${isAllowed ? agent.name : getFullyQualifiedId(agent)}`; const isDupe = isAllowed && !!otherAgents.find(other => other.name === agent.name && other.id !== agent.id); return { label: agentLabel, isDupe }; } </del>


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

getAgents(): IChatAgentData[]; getActivatedAgents(): Array<IChatAgent>; getAgentsByName(name: string): IChatAgentData[]; <ins> agentHasDupeName(id: string): boolean; </ins> /** * Get the default agent (only if activated)


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

return this.getAgents().filter(a => a.name === name); } <ins> agentHasDupeName(id: string): boolean { const agent = this.getAgent(id); if (!agent) { return false; } return this.getAgentsByName(agent.name) .filter(a => a.extensionId.value !== agent.extensionId.value).length > 0; } </ins> async invokeAgent(id: string, request: IChatAgentRequest, progress: (part: IChatProgress) => void, history: IChatAgentHistoryEntry[], token: CancellationToken): Promise<IChatAgentResult> { const data = this._agents.get(id); if (!data?.impl) {


Question:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.

getAgentByFullyQualifiedId(id: string): IChatAgentData | undefined { throw new Error('Method not implemented.'); } registerAgentCompletionProvider(id: string, provider: (query: string, token: CancellationToken) => Promise<IChatAgentCompletionItem[]>): IDisposable { throw new Error('Method not implemented.'); } getAgentCompletionItems(id: string, query: string, token: CancellationToken): Promise<IChatAgentCompletionItem[]> { throw new Error('Method not implemented.'); } <ins> agentHasDupeName(id: string): boolean { throw new Error('Method not implemented.'); } </ins> } class TestSpeechService implements ISpeechService {


Question:
<!-- 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.

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { Emitter } from 'vs/base/common/event'; </del> import { Barrier } from 'vs/base/common/async'; <ins> import { Emitter } from 'vs/base/common/event'; </ins> import { Disposable } from 'vs/base/common/lifecycle'; <del> import { ILifecycleService, WillShutdownEvent, StartupKind, LifecyclePhase, LifecyclePhaseToString, ShutdownReason, BeforeShutdownErrorEvent, InternalBeforeShutdownEvent } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { ILogService } from 'vs/platform/log/common/log'; </del> import { mark } from 'vs/base/common/performance'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> import { IStorageService, StorageScope, StorageTarget, WillSaveStateReason } from 'vs/platform/storage/common/storage'; <ins> import { BeforeShutdownErrorEvent, ILifecycleService, InternalBeforeShutdownEvent, LifecyclePhase, LifecyclePhaseToString, ShutdownReason, StartupKind, WillShutdownEvent } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> export abstract class AbstractLifecycleService extends Disposable implements ILifecycleService {


Question:
<!-- 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.

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


Question:
<!-- 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.

import { AbstractLifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycleService'; import { InstantiationType, registerSingleton } from 'vs/platform/instantiation/common/extensions'; import { INativeHostService } from 'vs/platform/native/common/native'; <del> import { Promises, disposableTimeout, raceCancellation } from 'vs/base/common/async'; </del> <ins> import { Promises, disposableTimeout, raceCancellation, timeout } from 'vs/base/common/async'; </ins> import { toErrorMessage } from 'vs/base/common/errorMessage'; import { CancellationTokenSource } from 'vs/base/common/cancellation'; <ins> import { IRemoteAgentService } from 'vs/workbench/services/remote/common/remoteAgentService'; </ins> export class NativeLifecycleService extends AbstractLifecycleService { private static readonly BEFORE_SHUTDOWN_WARNING_DELAY = 5000; private static readonly WILL_SHUTDOWN_WARNING_DELAY = 800; <ins> private static readonly MAX_GRACEFUL_REMOTE_DISCONNECT_TIME = 3000; </ins> constructor( @INativeHostService private readonly nativeHostService: INativeHostService, @IStorageService storageService: IStorageService, <del> @ILogService logService: ILogService </del> <ins> @ILogService logService: ILogService, @IRemoteAgentService private readonly remoteAgentService: IRemoteAgentService, </ins> ) { super(logService, storageService);


Question:
<!-- 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.

// trigger onWillShutdown events and joining await this.handleWillShutdown(reply.reason); <ins> // now that all services have stored their data, it's safe to terminate // the remote connection gracefully before synchronously saying we're shut down await this.handleRemoteAgentDisconnect(); </ins> // trigger onDidShutdown event now that we know we will quit this._onDidShutdown.fire();


Question:
<!-- 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.

}); } <ins> private async handleRemoteAgentDisconnect(): Promise<void> { const longRunningWarning = disposableTimeout(() => { this.logService.warn(`[lifecycle] the remote agent is taking a long time to disconnect, waiting...`); }, NativeLifecycleService.BEFORE_SHUTDOWN_WARNING_DELAY); await Promise.race([ this.remoteAgentService.endConnection(), timeout(NativeLifecycleService.MAX_GRACEFUL_REMOTE_DISCONNECT_TIME), ]); longRunningWarning.dispose(); } </ins> protected async handleBeforeShutdown(reason: ShutdownReason): Promise<boolean> { const logService = this.logService;


Question:
<!-- 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.

@IProductService productService: IProductService, @IRemoteAuthorityResolverService remoteAuthorityResolverService: IRemoteAuthorityResolverService, @ISignService signService: ISignService, <del> @ILogService logService: ILogService </del> <ins> @ILogService logService: ILogService, </ins> ) { super(remoteSocketFactoryService, userDataProfileService, environmentService, productService, remoteAuthorityResolverService, signService, logService); }


Question:
<!-- 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.

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { Emitter } from 'vs/base/common/event'; </ins> import { Disposable } from 'vs/base/common/lifecycle'; <del> import { IChannel, IServerChannel, getDelayedChannel, IPCLogger } from 'vs/base/parts/ipc/common/ipc'; </del> <ins> import { getDelayedChannel, IChannel, IPCLogger, IServerChannel } from 'vs/base/parts/ipc/common/ipc'; </ins> import { Client } from 'vs/base/parts/ipc/common/ipc.net'; <del> import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; </del> <ins> import { IDiagnosticInfo, IDiagnosticInfoOptions } from 'vs/platform/diagnostics/common/diagnostics'; import { ILogService } from 'vs/platform/log/common/log'; import { IProductService } from 'vs/platform/product/common/productService'; </ins> import { connectRemoteAgentManagement, IConnectionOptions, ManagementPersistentConnection, PersistentConnectionEvent } from 'vs/platform/remote/common/remoteAgentConnection'; <del> import { IExtensionHostExitInfo, IRemoteAgentConnection, IRemoteAgentService } from 'vs/workbench/services/remote/common/remoteAgentService'; </del> <ins> import { IRemoteAgentEnvironment, RemoteAgentConnectionContext } from 'vs/platform/remote/common/remoteAgentEnvironment'; </ins> import { IRemoteAuthorityResolverService } from 'vs/platform/remote/common/remoteAuthorityResolver'; <del> import { RemoteAgentConnectionContext, IRemoteAgentEnvironment } from 'vs/platform/remote/common/remoteAgentEnvironment'; import { RemoteExtensionEnvironmentChannelClient } from 'vs/workbench/services/remote/common/remoteAgentEnvironmentChannel'; import { IDiagnosticInfoOptions, IDiagnosticInfo } from 'vs/platform/diagnostics/common/diagnostics'; import { Emitter } from 'vs/base/common/event'; </del> <ins> import { IRemoteSocketFactoryService } from 'vs/platform/remote/common/remoteSocketFactoryService'; </ins> import { ISignService } from 'vs/platform/sign/common/sign'; <del> import { ILogService } from 'vs/platform/log/common/log'; </del> import { ITelemetryData, TelemetryLevel } from 'vs/platform/telemetry/common/telemetry'; <del> import { IProductService } from 'vs/platform/product/common/productService'; </del> <ins> import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; import { RemoteExtensionEnvironmentChannelClient } from 'vs/workbench/services/remote/common/remoteAgentEnvironmentChannel'; import { IExtensionHostExitInfo, IRemoteAgentConnection, IRemoteAgentService } from 'vs/workbench/services/remote/common/remoteAgentService'; </ins> import { IUserDataProfileService } from 'vs/workbench/services/userDataProfile/common/userDataProfile'; <del> import { IRemoteSocketFactoryService } from 'vs/platform/remote/common/remoteSocketFactoryService'; </del> export abstract class AbstractRemoteAgentService extends Disposable implements IRemoteAgentService {


Question:
<!-- 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.

@IProductService productService: IProductService, @IRemoteAuthorityResolverService private readonly _remoteAuthorityResolverService: IRemoteAuthorityResolverService, @ISignService signService: ISignService, <del> @ILogService logService: ILogService </del> <ins> @ILogService logService: ILogService, </ins> ) { super(); if (this._environmentService.remoteAuthority) {


Question:
<!-- 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.

let platform: crate::update_service::Platform = PreReqChecker::new().verify().await?; if !args.without_connection_token { <del> // Ensure there's a defined connection token, since if multiple server versions // are excuted, they will need to have a single shared token. let token_path = ctx.paths.root().join("serve-web-token"); let token = mint_connection_token(&token_path, args.connection_token.clone()) .map_err(CodeError::CouldNotCreateConnectionTokenFile)?; args.connection_token = Some(token); args.connection_token_file = Some(token_path.to_string_lossy().to_string()); </del> <ins> if let Some(p) = args.connection_token_file.as_deref() { let token = fs::read_to_string(PathBuf::from(p)) .map_err(CodeError::CouldNotReadConnectionTokenFile)?; args.connection_token = Some(token.trim().to_string()); } else { // Ensure there's a defined connection token, since if multiple server versions // are executed, they will need to have a single shared token. let token_path = ctx.paths.root().join("serve-web-token"); let token = mint_connection_token(&token_path, args.connection_token.clone()) .map_err(CodeError::CouldNotCreateConnectionTokenFile)?; args.connection_token = Some(token); args.connection_token_file = Some(token_path.to_string_lossy().to_string()); } </ins> } let cm = ConnectionManager::new(&ctx, platform, args.clone());


Question:
<!-- 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.

// todo: can be specialized when update service is moved to CodeErrors #[error("Could not check for update: {0}")] UpdateCheckFailed(String), <ins> #[error("Could not read connection token file: {0}")] CouldNotReadConnectionTokenFile(std::io::Error), </ins> #[error("Could not write connection token file: {0}")] CouldNotCreateConnectionTokenFile(std::io::Error), #[error("A tunnel with the name {0} exists and is in-use. Please pick a different name or stop the existing tunnel.")]


Question:
See
I think it's related to this line not clearing the quick pick: It's meant to hit backspace:

// Reset await this.code.dispatchKeybinding('Backspace'); } <ins> await this.code.wait(100); </ins> await this.code.dispatchKeybinding(altKey ? 'Alt+Enter' : 'enter'); await this.quickinput.waitForQuickInputClosed(); if (commandId === TerminalCommandIdWithValue.NewWithProfile) {