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.56.2 OS Version: macos big sur I am unable to find any record of someone else having this problem! Can someone point me to how I can start to debug this issue? Steps to Reproduce: a file with some text in it: using a relative path, the file opened is blank: opened using an absolute path, the text is correctly rendered: One hint is that when i edit the file (after opening with a relative path), vscode displays this error: ! Presumably, the code CLI is not using the cwd to open the relative path, and is assuming is a file in the filesystem root. I know this is super weird and am very eager to debug! Has anyone seen anything like this before? I have already tried disabling extensions, looking into logfiles etc.
/duplicate
do you by chance have a environment defined?
Aha! I do! How did that get set?! I've an unset to my shell profile but wondering how it is that this variable is being set in the first place.
I would like to understand how this variable can end up in your terminal environment. We do set it from application code here: But this cannot end up in the launching terminal imho... If you have any clues how you got there, please let me know. Also: I assume you are not using the integrated terminal right? //cc for terminal experts, maybe you have an idea how something we write from JavaScript can end up in the terminal environment.
The terminal environment code is a little complex, but except for cases like being set for extension terminals or getting contributed via an extension, this variable is meant to be sanitized in the terminal's process:
yeah I was also thinking that any prefixed environment variable would not make it to the integrated terminal, but would be good to ensure we have not regressed. However, here I actually think, people use the external (OS) terminal and still see set, which I cannot explain how that can happen from a process launched by the terminal.
Can confirm! This issue concerned using an external terminal to launch a vscode window!
is it at all reproducible for you somehow?
I see we only sanitize the external terminal env on Windows.
I think so! If I remove the unset from my zsh profile then the issue arises again, so it's reproducible in that respect. Is that what you mean?
how do you open terminals for using them? via a command VSCode provides or via Finder/Dock?
Usually the Finder/Dock variety (specifically, entering the letter "t" into spotlight and hitting enter without looking).
I cannot explain this issue then. If you are always opening terminals from the dock, none of the environment variables that VSCode defines should be there. Here is what I think can happen (correct me if you do something different): you open VSCode (either dock or terminal, doesn't matter) at one point you open a external terminal from VSCode (through some command or action) you type in that new terminal it fails to recognise the current working directory if now you open a terminal using dock or finder and try the same () it works
That all sounds right (I do sometimes open terminals from vscode!), except the issue arises even when the terminal is opened externally (via FInder). My immediate issue has been patched (via unset in zsh profile) and I'm alright to drop the concern if this is likely to be something extremely specific to my setup!
I cannot explain that. A terminal that is opened via finder can only contain environment variables as configured by startup scripts ( et al) to my knowledge. But happy to learn how this can happen otherwise...
Ok cool! I'm running some grep -r to see if anyone else might be sneakily setting this variable. Thanks for all your help!
I started seeing this issue after upgrading to MacOS big sur. Even when vscode is not running, the $VSCODE_ env variables are set when I open a new terminal from the dock
I think I figured out the cause of this for me at least. I have zsh set up to auto load tmux. so when a integrated terminal in vscode is launched it creates a tmux session and the env from that somehow leaks into other tmux sessions. I just disabled tmux auto loading and the problem disappeared.
Do you by any chance use tmux inside the integrated terminal in vscode ?
I do not!
maybe this is a red herring, in my testing when I run the command to open an external terminal, I do not see any of VSCodes environment variables appearing. Though it is true that we do not call the method in: Meanwhile I pushed to make sure we never on macOS/Linux, so this issue should not be present anymore.
are the verification steps in the original issue still valid/could you give some?
Yes the verification steps in the original issue are still valid one second. writing better instructions
to verify, close vscode open an external terminal and modify an environment variable in a repo directory starting with for example. open vscode and launch an external terminal from that same repo confirm that the environment variable you set is not present

} if (envVars) { <del> for (let key in envVars) { const value = envVars[key]; </del> <ins> // merge environment variables into a copy of the process.env const env = Object.assign({}, getSanitizedEnvironment(process), envVars); for (let key in env) { const value = env[key]; </ins> if (value === null) { osaArgs.push('-u'); osaArgs.push(key);


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.56.2 OS Version: macos big sur I am unable to find any record of someone else having this problem! Can someone point me to how I can start to debug this issue? Steps to Reproduce: a file with some text in it: using a relative path, the file opened is blank: opened using an absolute path, the text is correctly rendered: One hint is that when i edit the file (after opening with a relative path), vscode displays this error: ! Presumably, the code CLI is not using the cwd to open the relative path, and is assuming is a file in the filesystem root. I know this is super weird and am very eager to debug! Has anyone seen anything like this before? I have already tried disabling extensions, looking into logfiles etc.
/duplicate
do you by chance have a environment defined?
Aha! I do! How did that get set?! I've an unset to my shell profile but wondering how it is that this variable is being set in the first place.
I would like to understand how this variable can end up in your terminal environment. We do set it from application code here: But this cannot end up in the launching terminal imho... If you have any clues how you got there, please let me know. Also: I assume you are not using the integrated terminal right? //cc for terminal experts, maybe you have an idea how something we write from JavaScript can end up in the terminal environment.
The terminal environment code is a little complex, but except for cases like being set for extension terminals or getting contributed via an extension, this variable is meant to be sanitized in the terminal's process:
yeah I was also thinking that any prefixed environment variable would not make it to the integrated terminal, but would be good to ensure we have not regressed. However, here I actually think, people use the external (OS) terminal and still see set, which I cannot explain how that can happen from a process launched by the terminal.
Can confirm! This issue concerned using an external terminal to launch a vscode window!
is it at all reproducible for you somehow?
I see we only sanitize the external terminal env on Windows.
I think so! If I remove the unset from my zsh profile then the issue arises again, so it's reproducible in that respect. Is that what you mean?
how do you open terminals for using them? via a command VSCode provides or via Finder/Dock?
Usually the Finder/Dock variety (specifically, entering the letter "t" into spotlight and hitting enter without looking).
I cannot explain this issue then. If you are always opening terminals from the dock, none of the environment variables that VSCode defines should be there. Here is what I think can happen (correct me if you do something different): you open VSCode (either dock or terminal, doesn't matter) at one point you open a external terminal from VSCode (through some command or action) you type in that new terminal it fails to recognise the current working directory if now you open a terminal using dock or finder and try the same () it works
That all sounds right (I do sometimes open terminals from vscode!), except the issue arises even when the terminal is opened externally (via FInder). My immediate issue has been patched (via unset in zsh profile) and I'm alright to drop the concern if this is likely to be something extremely specific to my setup!
I cannot explain that. A terminal that is opened via finder can only contain environment variables as configured by startup scripts ( et al) to my knowledge. But happy to learn how this can happen otherwise...
Ok cool! I'm running some grep -r to see if anyone else might be sneakily setting this variable. Thanks for all your help!
I started seeing this issue after upgrading to MacOS big sur. Even when vscode is not running, the $VSCODE_ env variables are set when I open a new terminal from the dock
I think I figured out the cause of this for me at least. I have zsh set up to auto load tmux. so when a integrated terminal in vscode is launched it creates a tmux session and the env from that somehow leaks into other tmux sessions. I just disabled tmux auto loading and the problem disappeared.
Do you by any chance use tmux inside the integrated terminal in vscode ?
I do not!
maybe this is a red herring, in my testing when I run the command to open an external terminal, I do not see any of VSCodes environment variables appearing. Though it is true that we do not call the method in: Meanwhile I pushed to make sure we never on macOS/Linux, so this issue should not be present anymore.
are the verification steps in the original issue still valid/could you give some?
Yes the verification steps in the original issue are still valid one second. writing better instructions
to verify, close vscode open an external terminal and modify an environment variable in a repo directory starting with for example. open vscode and launch an external terminal from that same repo confirm that the environment variable you set is not present

if (cwd) { args.push(cwd); } <del> const child = spawner.spawn('/usr/bin/open', args); </del> <ins> const env = getSanitizedEnvironment(process); const child = spawner.spawn('/usr/bin/open', args, { cwd, env }); </ins> child.on('error', e); child.on('exit', () => c()); });


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.56.2 OS Version: macos big sur I am unable to find any record of someone else having this problem! Can someone point me to how I can start to debug this issue? Steps to Reproduce: a file with some text in it: using a relative path, the file opened is blank: opened using an absolute path, the text is correctly rendered: One hint is that when i edit the file (after opening with a relative path), vscode displays this error: ! Presumably, the code CLI is not using the cwd to open the relative path, and is assuming is a file in the filesystem root. I know this is super weird and am very eager to debug! Has anyone seen anything like this before? I have already tried disabling extensions, looking into logfiles etc.
/duplicate
do you by chance have a environment defined?
Aha! I do! How did that get set?! I've an unset to my shell profile but wondering how it is that this variable is being set in the first place.
I would like to understand how this variable can end up in your terminal environment. We do set it from application code here: But this cannot end up in the launching terminal imho... If you have any clues how you got there, please let me know. Also: I assume you are not using the integrated terminal right? //cc for terminal experts, maybe you have an idea how something we write from JavaScript can end up in the terminal environment.
The terminal environment code is a little complex, but except for cases like being set for extension terminals or getting contributed via an extension, this variable is meant to be sanitized in the terminal's process:
yeah I was also thinking that any prefixed environment variable would not make it to the integrated terminal, but would be good to ensure we have not regressed. However, here I actually think, people use the external (OS) terminal and still see set, which I cannot explain how that can happen from a process launched by the terminal.
Can confirm! This issue concerned using an external terminal to launch a vscode window!
is it at all reproducible for you somehow?
I see we only sanitize the external terminal env on Windows.
I think so! If I remove the unset from my zsh profile then the issue arises again, so it's reproducible in that respect. Is that what you mean?
how do you open terminals for using them? via a command VSCode provides or via Finder/Dock?
Usually the Finder/Dock variety (specifically, entering the letter "t" into spotlight and hitting enter without looking).
I cannot explain this issue then. If you are always opening terminals from the dock, none of the environment variables that VSCode defines should be there. Here is what I think can happen (correct me if you do something different): you open VSCode (either dock or terminal, doesn't matter) at one point you open a external terminal from VSCode (through some command or action) you type in that new terminal it fails to recognise the current working directory if now you open a terminal using dock or finder and try the same () it works
That all sounds right (I do sometimes open terminals from vscode!), except the issue arises even when the terminal is opened externally (via FInder). My immediate issue has been patched (via unset in zsh profile) and I'm alright to drop the concern if this is likely to be something extremely specific to my setup!
I cannot explain that. A terminal that is opened via finder can only contain environment variables as configured by startup scripts ( et al) to my knowledge. But happy to learn how this can happen otherwise...
Ok cool! I'm running some grep -r to see if anyone else might be sneakily setting this variable. Thanks for all your help!
I started seeing this issue after upgrading to MacOS big sur. Even when vscode is not running, the $VSCODE_ env variables are set when I open a new terminal from the dock
I think I figured out the cause of this for me at least. I have zsh set up to auto load tmux. so when a integrated terminal in vscode is launched it creates a tmux session and the env from that somehow leaks into other tmux sessions. I just disabled tmux auto loading and the problem disappeared.
Do you by any chance use tmux inside the integrated terminal in vscode ?
I do not!
maybe this is a red herring, in my testing when I run the command to open an external terminal, I do not see any of VSCodes environment variables appearing. Though it is true that we do not call the method in: Meanwhile I pushed to make sure we never on macOS/Linux, so this issue should not be present anymore.
are the verification steps in the original issue still valid/could you give some?
Yes the verification steps in the original issue are still valid one second. writing better instructions
to verify, close vscode open an external terminal and modify an environment variable in a repo directory starting with for example. open vscode and launch an external terminal from that same repo confirm that the environment variable you set is not present

const bashCommand = `${quote(args)}; echo; read -p "${LinuxExternalTerminalService.WAIT_MESSAGE}" -n1;`; termArgs.push(`''${bashCommand}''`);	// wrapping argument in two sets of ' because node is so "friendly" that it removes one set... // merge environment variables into a copy of the process.env <del> const env = Object.assign({}, process.env, envVars); </del> <ins> const env = Object.assign({}, getSanitizedEnvironment(process), envVars); </ins> // delete environment variables that have a null value Object.keys(env).filter(v => env[v] === null).forEach(key => delete env[key]);


Question:
Steps to Reproduce: Workspace and trust it code-insiders from a folder that is not trusted. -Shows the dialog code-insiders from a folder that is not trusted. -No warning dialog the window code-insiders from a folder that is not trusted. Expected: No warning dialog should be shown Actual: A warning dialog is being shown
Pushed a fix for this to main. Fix is low risk so we can take it as a candidate.

// Update workspace trust this._trustState.isTrusted = trusted; <ins> // Reset acceptsOutOfWorkspaceFiles if (!trusted) { this._trustState.acceptsOutOfWorkspaceFiles = false; } </ins> // Run workspace trust transition participants await this._trustTransitionManager.participate(trusted);


Question:
Steps to Reproduce: Workspace and trust it code-insiders from a folder that is not trusted. -Shows the dialog code-insiders from a folder that is not trusted. -No warning dialog the window code-insiders from a folder that is not trusted. Expected: No warning dialog should be shown Actual: A warning dialog is being shown
Pushed a fix for this to main. Fix is low risk so we can take it as a candidate.

set isTrusted(value: boolean | undefined) { this._mementoObject[this._isTrustedKey] = value; <del> if (!value) { this._mementoObject[this._acceptsOutOfWorkspaceFilesKey] = value; } </del> this._memento.saveMemento(); } }


Question:
I recently came across CSS rule. According to the : I do not think we want the panning and zooming, but the removal of the 300ms delay sounds great to get a more snappy UI when using touch for e.g. action bars. Maybe worth a try?
I wonder if would even be the right thing, but not sure it removes the 300ms delay:
Interesting, I see we use this property already, e.g. in the list:
Worth experimenting with. do you remember why you that css property for the list? For now assigning to June, might push out due to lack of time.
Did not have time, pushing out to August, since in July I am on vacation
Probably for the 300ms removal.
Adding bug, so we get this verified. Steps: ipad. sure the touch behaves as expected in the editor and some views touch triggers context menu
feels pretty snappy to me!

} .monaco-workbench.web { <del> touch-action: initial; /* reenable touch events on workbench */ </del> <ins> touch-action: none; /* Disable browser handling of all panning and zooming gestures. Removes 300ms touch delay. */ </ins> } @keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } }


Question:
Issue Type: <bBug</bI currently store some arbitrary JSON-serializable object using and updating keys. At the top level, my configuration variable is an array, and each element is a dictionary that contains some keys. One of those keys map to a value like this: This sets fine, and I can look in my workspace's to see all keys and values there as expected. However, when I try to get the value from the workspace configuration again, the empty string key and its value are missing, meaning I unable to retrieve the array with in it. So it seems VSCode filters out keys which are blank strings when reading workspace configurations, although it will set/save them. This is currently blocking a project I'm working on and should be a trivial fix. VS Code version: Code 1.57.1 (, 2021-06-17T13:28:07.755Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
I am sorry that I do not understand the usage of the API here and what is being done. Can you please provide a sample code snippet to reproduce the issue?
Here's a round trip example of me saving an object to the workspace configuration, and retrieving it. It shows all data is stored appropriately, but data is lost when reading it back if a blank string key exists. The message will be shown. If you comment out/remove the key-value pair in , it will instead say . So VSCode is losing data when obtaining data from the workspace configuration if you store an object which has a blank key somewhere (at any level of depth).
There was a fairly quick initial response here, but since then a good amount of time has elapsed. Has there been any progress updates or planning related to this issue? Can you confirm you now understand the issue given the above proof-of-concept? It should be very clear.
Thanks for the info. It is in my list of issues to investigate, I will try it out and get back to you.

function onValue(value: any) { if (Array.isArray(currentParent)) { (<any[]>currentParent).push(value); <del> } else if (currentProperty) { </del> <ins> } else if (currentProperty !== null) { </ins> currentParent[currentProperty] = value; } }


Question:
Issue Type: <bBug</bI currently store some arbitrary JSON-serializable object using and updating keys. At the top level, my configuration variable is an array, and each element is a dictionary that contains some keys. One of those keys map to a value like this: This sets fine, and I can look in my workspace's to see all keys and values there as expected. However, when I try to get the value from the workspace configuration again, the empty string key and its value are missing, meaning I unable to retrieve the array with in it. So it seems VSCode filters out keys which are blank strings when reading workspace configurations, although it will set/save them. This is currently blocking a project I'm working on and should be a trivial fix. VS Code version: Code 1.57.1 (, 2021-06-17T13:28:07.755Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
I am sorry that I do not understand the usage of the API here and what is being done. Can you please provide a sample code snippet to reproduce the issue?
Here's a round trip example of me saving an object to the workspace configuration, and retrieving it. It shows all data is stored appropriately, but data is lost when reading it back if a blank string key exists. The message will be shown. If you comment out/remove the key-value pair in , it will instead say . So VSCode is losing data when obtaining data from the workspace configuration if you store an object which has a blank key somewhere (at any level of depth).
There was a fairly quick initial response here, but since then a good amount of time has elapsed. Has there been any progress updates or planning related to this issue? Can you confirm you now understand the issue given the above proof-of-concept? It should be very clear.
Thanks for the info. It is in my list of issues to investigate, I will try it out and get back to you.

assert.deepStrictEqual(testObject.configurationModel.keys, []); }); <ins> test('Test empty property is not ignored', () => { const testObject = new ConfigurationModelParser('test'); testObject.parse(JSON.stringify({ '': 1 })); // deepStrictEqual seems to ignore empty properties, fall back // to comparing the output of JSON.stringify assert.strictEqual(JSON.stringify(testObject.configurationModel.contents), JSON.stringify({ '': 1 })); assert.deepStrictEqual(testObject.configurationModel.keys, ['']); }); </ins> test('Test registering the same property again', () => { Registry.as<IConfigurationRegistry>(Extensions.Configuration).registerConfiguration({ 'id': 'a',


Question:
And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?

} /** <ins> * Register an inlay hints provider. */ export function registerInlayHintsProvider(languageId: string, provider: modes.InlayHintsProvider): IDisposable { return modes.InlayHintsProviderRegistry.register(languageId, provider); } /** </ins> * Contains additional diagnostic information about the context in which * a [code action](#CodeActionProvider.provideCodeActions) is run. */


Question:
And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?

registerDocumentSemanticTokensProvider: <any>registerDocumentSemanticTokensProvider, registerDocumentRangeSemanticTokensProvider: <any>registerDocumentRangeSemanticTokensProvider, registerInlineCompletionsProvider: <any>registerInlineCompletionsProvider, <ins> registerInlayHintsProvider: <any>registerInlayHintsProvider, </ins> // enums DocumentHighlightKind: standaloneEnums.DocumentHighlightKind,


Question:
And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?

export function registerInlineCompletionsProvider(languageId: string, provider: InlineCompletionsProvider): IDisposable; /** <ins> * Register an inlay hints provider. */ export function registerInlayHintsProvider(languageId: string, provider: InlayHintsProvider): IDisposable; /** </ins> * Contains additional diagnostic information about the context in which * a [code action](#CodeActionProvider.provideCodeActions) is run. */


Question:
Since it seems pretty simple to stop the server now, It seems like using the task as a way to run a persistent server is sort of unnecessary. Settings should have a way to toggle whether they want the task to run or not.
Verification steps: this setting (or set to ) ! the command palette or other means to open an external preview, when doing this, the server logging task should not run automatically. setting to , the task should automatically run with the external preview launch (default behavior).

disposables.push(server.onServerStart(path => { <del> defaultStatus.text = '$(flame) Runnning'; </del> <ins> defaultStatus.text = '$(flame) Running'; </ins> defaultStatus.command = 'o.pickProjectAndStart'; defaultStatus.color = ''; render();


Question:
Issue Type: <bBug</bThe user defined keybiding editorScroll command with arg property "' to': 'up'" repeats slower than "'to':'down'". The key combination doesn't seems to have influence. [edit] I tested it further, and found what triggers this behavior is the conjunction of this keybinding with the setting smooth scrolling : "editor.smoothScrolling": true, Windows and Linux versions have the same behavior. VS Code version: Code 1.58.2 (, 2021-07-14T22:30:16.440Z) OS version: Linux x64 5.4.0-77-generic Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ Bookmarks13.1.0 vscode-language-babel0.0.31 cpptools1.5.1 LiveServer5.6.1 ninja0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --<!-- potentialduplicatescomment --
I could not reproduce. I tried with the following keybindings: The scroll speed appears similar to me for both keybindings.
I tested it further, and found what triggers this behavior is the conjunction of this keybinding with the setting smooth scrolling : Windows and Linux versions have the same behavior.
I can reproduce a slowdown. On my macOS computer, scrolling down went 114 lines down in 10s, while scrolling up went 100 lines up in 10s.
Not sure if my case is special. My issue was closed as duplicate of this one. Windows 10 here. On two completely different and unrelated machines but with the same VSCode user configuration. Scrolling down a document of 114 lines: 4.5 seconds Scrolling up again: 13 seconds This is a major slowdown by the factor 3!

if (args.unit === EditorScroll_.Unit.Line) { // scrolling by model lines <del> const visibleViewRange = viewModel.getCompletelyVisibleViewRange(); </del> <ins> const futureViewport = viewModel.viewLayout.getFutureViewport(); const visibleViewRange = viewModel.getCompletelyVisibleViewRangeAtScrollTop(futureViewport.top); </ins> const visibleModelRange = viewModel.coordinatesConverter.convertViewRangeToModelRange(visibleViewRange); let desiredTopModelLineNumber: number;


Question:
Testing disassembly view on screen reader on an element, notice the following being read out "Can set breakpoint, Instruction address: 0x000000ea, Instruction: of" We need to imrpove this aria label: most important piece of information needs to go first, so that blind users can skip the boring repetitive part. So start with the "0x000000ea address, " it more concise, I think "can set breakpoint" is not needed here do not understand the last part "intruction: of", this needs to be fixed I think
will fix this.
Is there a way to update aria label via accessibility provider? Looks like it's set only when the element is rendered? I'm wondering if we can add/remove all texts about breakpoint and stack frame. If not, we should probably remove texts related to breakpoints. Also, it's a great suggestion that we should reduce the amount of duplicates. So I'll change it to . As for , it's likely the disassembly instruction you are looking at is . For now, each line in disassembly view looks like: Where there may not be InstructionBytes. For example, Will have aria label (currently) .
no, it is not possible to dynamically update the aria label. This sounds good, I would just cut it short to be

getAriaLabel(element: IDisassembledInstructionEntry): string | null { let label = ''; <del> if (element.isBreakpointSet) { label += localize('breakpointIsSet', "Breakpoint is set"); } else if (element.allowBreakpoint) { label += localize('breakpointAllowed', "Can set breakpoint"); } </del> const instruction = element.instruction; <del> label += `, ${localize('instructionAddress', "Instruction address")}: ${instruction.address}`; </del> <ins> label += `${localize('instructionAddress', "Address")}: ${instruction.address}`; </ins> if (instruction.instructionBytes) { <del> label += `, ${localize('instructionBytes', "Instruction bytes")}: ${instruction.instructionBytes}`; </del> <ins> label += `, ${localize('instructionBytes', "Bytes")}: ${instruction.instructionBytes}`; </ins> } label += `, ${localize(`instructionText`, "Instruction")}: ${instruction.instruction}`;


Question:
Testing the steps in the test plan item to create an interactive window I get a notification saying there are extensions on the marketplace that can handle . I feel like this is unnecessary noise
Which extension is it recommending?
The marketplace query is ext:interactive when I click on Search Marketplace !
I forgot that we had this but we automatically query show this when there are extensions in the marketplace that match the query . I'm curious about how this works, it seems overly sensitive since these extensions don't use that file extension, seems that it just matches based on keywords? I think the only way to avoid it here is to change the extension that the interactive window uses, which is probably fine.
Discussed with and even if we picked an extension that isn't yet in use, we can't prevent extensions from introducing collisions later. What about the following (essentially, parse the notebook URI from the cell URI, and check if it's an untitled://, file:// or vscode-remote:// URI based on the notebook URI instead)?
What will the interactive window be? It won't pass that check?
Is the motive here is to not show any recommendations for this resource?
Yeah we don't want to show the '.interactive' file recommendation because it's not actually a file on disk. The interactive notebook schema is 'interactive'.
Then we shall be filtering out in our recommendations logic as you recommended above.

import { IExtensionRecommendationNotificationService, RecommendationsNotificationResult, RecommendationSource } from 'vs/platform/extensionRecommendations/common/extensionRecommendations'; import { distinct } from 'vs/base/common/arrays'; import { DisposableStore } from 'vs/base/common/lifecycle'; <ins> import { CellUri } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> type FileExtensionSuggestionClassification = { userReaction: { classification: 'SystemMetaData', purpose: 'FeatureInsight' };


Question:
Testing the steps in the test plan item to create an interactive window I get a notification saying there are extensions on the marketplace that can handle . I feel like this is unnecessary noise
Which extension is it recommending?
The marketplace query is ext:interactive when I click on Search Marketplace !
I forgot that we had this but we automatically query show this when there are extensions in the marketplace that match the query . I'm curious about how this works, it seems overly sensitive since these extensions don't use that file extension, seems that it just matches based on keywords? I think the only way to avoid it here is to change the extension that the interactive window uses, which is probably fine.
Discussed with and even if we picked an extension that isn't yet in use, we can't prevent extensions from introducing collisions later. What about the following (essentially, parse the notebook URI from the cell URI, and check if it's an untitled://, file:// or vscode-remote:// URI based on the notebook URI instead)?
What will the interactive window be? It won't pass that check?
Is the motive here is to not show any recommendations for this resource?
Yeah we don't want to show the '.interactive' file recommendation because it's not actually a file on disk. The interactive notebook schema is 'interactive'.
Then we shall be filtering out in our recommendations logic as you recommended above.

} private onModelAdded(model: ITextModel): void { <del> const uri = model.uri; const supportedSchemes = [Schemas.untitled, Schemas.file, Schemas.vscodeRemote, Schemas.vscodeNotebookCell]; </del> <ins> const uri = model.uri.scheme === Schemas.vscodeNotebookCell ? CellUri.parse(model.uri)?.notebook : model.uri; const supportedSchemes = [Schemas.untitled, Schemas.file, Schemas.vscodeRemote]; </ins> if (!uri || !supportedSchemes.includes(uri.scheme)) { return; }


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. --- Version: 1.59.0-insider Commit: Date: 2021-07-31T00:42:32.346Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: Linux x64 5.13.5 Steps to Reproduce: a project directory that is hooked up with tasks via v2. The file must define one of the tasks as being the default. you have bound to a shortcut (mine is ctrl+shift+b) the key combination to trigger the build picker combobox to choose a task appears instead of the default task being executed as used to happen before.
I'm not able to reproduce this issue. Do you have a repository I can test with? I tried with: If there is more than one default build task, then we have always shown the picker. If there is only one default build task, then we run it.
I'm experiencing this with internal company code which cannot be shared. I can share the file. It should work with any c# based project.
Has the schema for changed at all in the past month?
I've replicated this on other similar projects, even those that have just one task defined.
Thanks for the additional details and for reporting this issue!

} context.taskLoadIssues = Objects.deepClone(baseLoadIssues); } <del> if ((defaultBuildTask.rank > -1) && (defaultBuildTask.rank < 2) && defaultBuildTask.task) { </del> <ins> // There is some special logic for tasks with the labels "build" and "test". // Even if they are not marked as a task group Build or Test, we automagically group them as such. // However, if they are already grouped as Build or Test, we don't need to add this grouping. const defaultBuildGroupName = Types.isString(defaultBuildTask.task?.configurationProperties.group) ? defaultBuildTask.task?.configurationProperties.group : defaultBuildTask.task?.configurationProperties.group?._id; const defaultTestTaskGroupName = Types.isString(defaultTestTask.task?.configurationProperties.group) ? defaultTestTask.task?.configurationProperties.group : defaultTestTask.task?.configurationProperties.group?._id; if ((defaultBuildGroupName !== Tasks.TaskGroup.Build._id) && (defaultBuildTask.rank > -1) && (defaultBuildTask.rank < 2) && defaultBuildTask.task) { </ins> defaultBuildTask.task.configurationProperties.group = Tasks.TaskGroup.Build; <del> } else if ((defaultTestTask.rank > -1) && (defaultTestTask.rank < 2) && defaultTestTask.task) { </del> <ins> } else if ((defaultTestTaskGroupName !== Tasks.TaskGroup.Test._id) && (defaultTestTask.rank > -1) && (defaultTestTask.rank < 2) && defaultTestTask.task) { </ins> defaultTestTask.task.configurationProperties.group = Tasks.TaskGroup.Test; }


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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:

} } <ins> export class TestingSortByDurationAction extends ViewAction<TestingExplorerView> { public static readonly ID = 'testing.sortByDuration'; constructor() { super({ id: TestingSortByDurationAction.ID, viewId: Testing.ExplorerViewId, title: localize('testing.sortByDuration', "Sort by Duration"), toggled: TestingContextKeys.viewSorting.isEqualTo(TestExplorerViewSorting.ByDuration), menu: { id: MenuId.ViewTitle, order: ActionOrder.Sort, group: 'sortBy', when: ContextKeyExpr.equals('view', Testing.ExplorerViewId) } }); } /** * @override */ public runInView(_accessor: ServicesAccessor, view: TestingExplorerView) { view.viewModel.viewSorting = TestExplorerViewSorting.ByDuration; } } </ins> export class ShowMostRecentOutputAction extends Action2 { public static readonly ID = 'testing.showMostRecentOutput'; constructor() {


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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:

ShowMostRecentOutputAction, TestingSortByLocationAction, TestingSortByStatusAction, <ins> TestingSortByDurationAction, </ins> TestingViewAsListAction, TestingViewAsTreeAction, ToggleInlineTestOutput,


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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:

return (a instanceof TestTreeErrorMessage ? -1 : 0) + (b instanceof TestTreeErrorMessage ? 1 : 0); } <ins> const durationDelta = (b.duration || 0) - (a.duration || 0); if (this.viewModel.viewSorting === TestExplorerViewSorting.ByDuration && durationDelta !== 0) { return durationDelta; } </ins> const stateDelta = cmpPriority(a.state, b.state); if (this.viewModel.viewSorting === TestExplorerViewSorting.ByStatus && stateDelta !== 0) { return stateDelta;


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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:

export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', <ins> ByDuration = 'duration', </ins> } export const enum TestExplorerStateFilter {


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/No unable to start container without extensions enabled <!-- 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: Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-16T05:21:19.431Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. OS Version: Steps to Reproduce: VSCode Insiders Edition on Windows Insider gives error every time when logging in to GitHub and other sites 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command'. Also, have set up ssh, but still requires web authentication for extensions every time I open VSCode. It gives the error, but then continues to login after the error and does not save login information. after opening VSCode insiders login to github error and does not save login information tested on current VSCode and doesn't require login every time and no issues with memory (working) Version: 1.59.0 (system setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: WindowsNT x64 10.0. Regular Edition does not give the error and I do not have to login to github everytime the app starts.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.528 --- <!-- score: 0.528 --- <!-- score: 0.452 --<!-- potentialduplicatescomment --
! did not fix the issue Snapshot of the error message: !
!
there was an issue with the last insiders build. Can you update to the latest one and let us know if you're still seeing this?
Thank you. I installed the update, but unfortunately, it is still doing it. I did a full memory diagnostic and it did not find any issues with memory, and there is plenty of it available. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-19T05:15:46.693Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. ! !
!
Just updated again. Issue remains. Thank you. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-20T17:51:50.560Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. !
This is likely an issue with the library we use for storing secrets called but it's impossible for me to reproduce... so it'll be hard for me to make progress here.
+1 I am now getting this issue on my laptop Where can I find logs or what information do you need that would assist in resolving the issue?
Hey did you manage to fix this? Same problem..
Third that Same issue also...
I am also getting the same issue as well, both trying to sign in with my Microsoft Account for Settings Sync and with GitHub for Settings Sync, GitLens, or LiveShare. Visual Studio 2022 is also having problems connecting to GitHub, and since the new connection successful screen doesn't display the token information, I cannot even connect it manually.
do you see this only when using a Remote SSH/Remote Container connection? Your original video that it was a Remote connection. To the others in the thread, do you also experience this when using Remote?
I see it when using the Accounts -Sign In commands in the bottom left. Whether I use it to sign in to use Settings Sync or LiveShare (with either Microsoft Account or GitHub), or using GitHub for GitLens. I now get the token information with the instructions: Copy the token. Switch back to VS code. Click Signing in to in the status bar. Paste the token and hit enter.5. But, there is no "Signing in to " in the status bar, just the error message noted.
Are you using a Remote? Like Remote SSH, Remote WSL, Remote Containers?
no, just launching VS Code and attempting to sign in. Seems to be a problem with saving the token on the redirect.
I solved this by changing my pagefile settings by doing: System Properties -Advanced -Performance -Advanced -Virtual Memory -Change -uncheck 'Automatically manage paging file size for all drives' -check 'System managed size' -OK -Reboot edit: I'm not sure why the pagefile would affect it though. I have 128GB of RAM.
Thank you , that seems to have fixed it for me as well.
Thanks a lot it worked for me
Sadly, this did not work for me and I share the doubt about how a page file setting can affect this. I even tried it with the paging file completely disabled. Any other ideas?
if you have nodejs installed, you can run this simple one-liner to see if the problem is how your keychain is setup: or if you're on Insiders: This is using the following open source package: What you should get is something like this: If that succeeds, then the problem is possibly in vscode. If that does complain, then we'll need a fix in keytar itself.
I can try this tomorrow.
Hi Tyler, I understand that you can't reproduce the problem, making it hard for you to investigate. I'm happy to try to help. I am on Windows 11 if that makes a difference. Also, on a completely separate Windows 10 desktop right next to me I do not have the problem. I ran the test you suggested and I got back the expected response for github authentication. However, my difficulties are with microsoft authentication. So I changed the command to look for . I got back 100 account/password pairs. 98 of them had in the account field, for example: (Some digits changed in case they are sensitive) The account fields for the other two were and The password fields look quite different from the one retrurned by github. Something like: Probably the most important thing is that only the password returned with the account looks exactly like the one returned by github, sort of like SSH keys. The formats are the same, the digits are just different. So, if I had to guess it looks like the caller of this function is getting back a lot more data than expected and/or needs to filter it to get only the account.
thanks for giving that a try. The content of is different than GitHub. It has a different secret storage schema (that I could get into ... but lets call it as it is "legacy reasons") Anyway, the fact that the script I suggested worked fine, but VS Code fails leads me to believe that this might have something to do with Electron and how is loaded into that. Let me chat with on this to see if he has anything thoughts
I have a different problem. When I dumped my keychain, I have 123 entries in it so "not enough resources is probably not surprising. I wonder whether these accumulate over time and then the problem arises. Usually, I am asked to re-authenticate once a couple of weeks so it would take a while before they accumulate. I will remove them now so I can use my shit.
For my normal VSCode (which I stopped using since we last tacked this problem), i have the following targets: So probably this is how it looks "in the making". Should I clean that up as well or leave it for testing?
FWIW, I've worked around the problem by deleting all the credentials of the form: where "xxx" at the end is some random-looking decimal number. After restarting and reauthenticating, several subsequent restarts of VSCode did not require re-authentication and the number of credentials of the above form holds steady.
Yes, me too. I am guessing it will slowly grow as tokens expire. The library that gave does not have functionality to delete, so that is probably what is causing this.
I found the same thing; in my case it was a whole bunch of credentials placed there by Adobe Creative Cloud that were taking up all the space. Once I completely cleared out the Windows Credential Store, I was able to get both VS Code and Visual Studio to correctly connect to GitHub again. Get Outlook for iOS From: Vladislav Kosev Tuesday, July 12, 2022 10:37:40 AM To: microsoft/vscode Pierre Plourde Comment Re: [microsoft/vscode] error logging in 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command' () Yes, me too. I am guessing it will slowly grow as tokens expire. The library that does not have functionality to delete, so that is probably what is causing this. — Reply to this email directly, view it on GitHub, or unsubscribe You are receiving this because you commented.Message ID:
That process for keychain setup worked for me, I got the result expected. So what does that mean for vscode? A bug? Every time I restart VSCode or even reload the window, I have to login again for CoPilot and Settings Sync - I use the Github login. Using MacOS Monterrey.
I had the same issue - too many credentials (Windows 11: Start Credential Manager Windows Credentials). Mine included an obscene number of vscode entries, as noted above, so I deleted them all with a powershell line I cobbled together through Google: . It still threw the error so I hand-pruned most of the remaining entries and it took. Good luck! (FWIW, Win 11, 8GB RAM + 24GB Page File) !
I think this one is more likely the cause. Because after I deleted all the credentials in the credential manager, it still automatically logs me out. There is no out of resource error for me. It may be the syncing issue leads to duplicated credential creation.
For the folks that have cleared the large list of credentials in their credential manager... can you please check to see if that number is increasing again? My suspicion is that some of you got into a bad state around the time that I was making heavy changes in this space... but now that that has settled, vscode's code isn't polluting the cred store anymore... This is coming from my lack of reproduction of the issue even though I've tried numerous ways to do it. With that said, users could still get into this bad state though, if they use other applications that use the keychain (like someone mentioned with Adobe products). For this case, we should at the very least include docs in the troubleshooting keychain issues here:
Hi Tyler, I have not had any failures along the lines of the original problem (needing to login each time vscode is started) since I cleared the credentials back in July. Today, I see only about 5 hits from the command you posted. And I think I saw about the same number when I checked at some point between July and now. I tend to agree with your suspicion.
"Target" is localized. Need to chcp 437 first. I now clear my credentials and will try to reproduce.
Thanks I'll update my regex
updated mine and I'm updating your quote so that no one gets confused
Based on confirmation, I will optimistically close this issue once the doc PR goes in... however, if you still see the problem of VS Code's credentials growing an unreasonable amount, please don't hesitate to reach out.
One other thing I tried is a minimal Electron repro where I created 1000 secrets to see if I could reproduce it... I could not. For those that wanna assist in getting to the true root of the problem, I've documented a potential repro here: If you can reproduce the error mentioned in this issue using my Gist, please let me know so we can let the Electron team know. In any case, I'll still close this once goes in.
I have confirmed that once there are too many credentials, the Windows call fails with . This issue doesn't have to do with Electron or Node.
Given this, the best we can do is document that workaround which is done now. Thanks for the investigation
Hi , may I ask how to list the credential? And what's the upper limit? I don't think my box have "too many credentials". But it still hit this issue. Thanks
, isn't it possible to remove the expired credentials automatically? It doesn't seem normal that you must delete credentials by yourself. There is not even a command that does it, you need excel/PowerShell to do it.
We're still blocked by the issue. May anyone please suggest a workaround? Thanks.
see to get the list of credentials.
Thanks, . This is my observation: ! I notice tons of credential created by VS code. To me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue. Any thoughts? Thanks CC (, who seems the PM to me)
I think that the working assumption is that there was a temporary problem in VS code that generated the entries in the Credential Manager. See the explanation in this in this same issue thread. You might try deleting those entries in your Credential Manager and make sure you have the latest revision of VS Code. I did exactly that back in July and it worked. I see that at least some of your entries are in or before that timeframe.
Thanks. . I ran Then the issue is gone. I disagree with this statement: I have confirmed that once there are too many credentials, the Windows call CredWrite fails with ERRORNOTENOUGHMEMORY. This issue doesn't have to do with Electron or Node. Again, to me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue.
It's a Windows issue because it could be caused by other programs too. See Adding a command to clear credentials sounds like a separate feature request to me. Edit: Actually, if a bunch of credentials are still being incorrectly written even with VS Code version 1.71, that's a VS Code bug.
Hi , are you saying it's by design that VS code creates tons of the credentials? IMO, once vscode creates ton of credentials, it's by design that Windows OS prompts OOM. I read, in different way: both adobe/vscode should not create tons of credentials. It's their bugs to create tons of credentials.
I cleared my credentials back in July and haven't seen any evidence that "VS code creates tons of credentials". Right now, I have 5 that refer to "" user IDs and I suspect that has to do with my Microsoft account history. Tyler said that was a long story and has to do with legacy/older systems. I think I tried to explain before that Tyler suspected that there was some bad code in one of the releases of VS Code that caused the creation of these credentials. This would have probably been in the timeframe of the first half of this year. But apparently, that problem is no longer in current builds of VS Code. So you may be right that it is a VS Code bug, but it appears to be one that is fixed, at least according to my observations.
Thanks, . I think the issue still exists. 2 days ago, I have deleted all extra vscode credential using, cmdkey /list ForEach-Object { /delete $_.Matches.Groups[1].Value } But today, login failed again. Then I observed that vscode creates a bunch of credential again, which does not sounds expected to me. ! , do you have any idea? Thanks
This is why I asked if anyone was seeing the large quantities of vscode secrets after clearing out their secrets. And why I used the phrase "optimistically close" . You've provided new information with that last message and you've confirmed that there's some scenario where this still happens. With that said can you please supply: if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) how many windows of vscode you typically have open give me the full text of one of these keys (don't worry it's only public data)
Thanks if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) -Only hotmail account. etc, how many windows of vscode you typically have open -3 instance. But I use a python script to open them give me the full text of one of these keys (don't worry it's only public data) -Where to find these text?
Hey just jumping on this as per the comment in . I have just performed the credential manager clean out as per the command line in and my multiple VSCode windows are now all signed in, and persist across Exit's and re-open. There were 178 entries for the specific pattern on my machine. Edit: With things now working, there are 22 entries. I will keep an eye on things, and will post back here later on. For initial context: Windows Account 5 windows open at all times; 4 are folders/workspaces, and 1 is general files and unsaved instances
I've started experiencing the issue that appears to be mentioned in (but has now been merged into this ticket), but it appears that VSCode is correctly(?) reading my credentials from Seahorse (on Ubuntu) but still asks me to sign in every time I want to start or join a Live Share session. I've tried clearing out all the relevant credentials from Seahorse, and that (as expected) asks me to reauthenticate with my Microsoft account, but then continues to ask me to sign in whenever I start a new session. From Output Microsoft Authentication, everything seems to look fine to me - it finds two(?) stored sessions and seems to refresh the token fine... :shrug: Details about VS Code and my OS: In addition: It's a Microsoft work account () Usually only one or two, depending on the project. However, Live Share appears to open one window initially (that I have to click 'sign in' on) then opens a separate window (which I also have to sign in on) From Seahorse, I assume it's this bit you need? If you need to know anything else, don't hesitate to ask :+1:
Just chiming in here. I just used the hint with deleting all the credentials for vscode. I had like 100+ of them. After that I signed in to settings sync using my Microsoft account. No more memory error on save. And after restarting vscode it signed me in automatically again.
I have the hardest time reproducing this issue... for those of you that do see it, can you do me a favor and: the Credential Manager open on the side what you normally do (open multiple windows, just use VS Code) to see if you can notice when the number of credentials increases and let me know if there's a particular action that causes it I'll continue to try reproducing this...
Thank for continuing to try. Current it seems to not happen anymore or it happens very infrequently. In credential manager I have: 1 github token 8 tokens - 4 from yesterday and 4 from 30.08.2022. Not sure why 4. 5 numbered from 0 to 3 + one keylist.
those "8 tokens" are in the form right? Can you share them here? And if you don't want to can you at least tell me what's different about them? My guess is just a guid at the end...
Yes, there they are. Interestingly enough They were 4 pairs Two of the pairs are modified today (so they are somehow active, because the date changed from yesterday). There they are (dates are in front)
Just a little context on the pairs... Cred Man on windows has a limit to the number of characters you can store so we chunk them. The are the 2nd part of the other one. can you tell me how many things you've logged into with your Microsoft account? Based on 2 items being updated on Nov 4, I am going to guess...2... LiveShare & Settings Sync maybe? The ones from Aug 30 are odd... around that time, I was not working heavily in credentials land so that leads me to believe that you saw the bug that other folks in this thread are mentioning... the slow slow climb in the number of secrets. It's unclear to me why that happened... I ask myself questions: Were these credentials being used before that date and one day they weren't read properly so new credentials were created? This is possible. The library we use can be a bit dicey... and Windows certainly isn't perfect. before the "sign in every time behavior". Do you recall having to randomly sign in to Microsoft every once in a while? If this is the case, I need a better clean up mechanism... if possible. Were these credentials created accidentally as a duplicate... like could a 2nd window of VS Code think it was responsible for storing the credential and thus it stored a duplicate secret which was then overwritten by the updating of the keylist. Worth double checking... I thought only one window handles the creation of secrets, but maybe I'm missing something. If this is the case, the keylist might be getting mangled with 2 instances of vscode writing to the same place Btw, all of the non-keylist ones can probably be deleted (I'm assuming the date modified on those are a while ago). Those are from the old structure of secrets where all secrets were stored in one (chunked) credential.
Yes, these two. It's not that this doesn't happen, but it is diffucult to remember so far back.
Hi folks it has been a bit... I wanted to let you all know that I made a change that I think will be helpful here. It's available in the VS Code Insiders Build: What I'm hoping you see is no more gradually increasing number of credentials in CredMan. Please give it a try and let me know how it goes. I know it may take days/weeks/months to fully verify that this change made a difference... but it'll be worth it!
Wish I found this issue earlier. I just counted 188 entries in my Credential Manager for . I've been seeing this problem for the last few weeks (months?), where vscode constantly signs me out of my settings sync. Finally looked into it this morning and found the, "Not enough memory resources" output message, which led me to this issue. I deleted all the authenticator tokens from CredMan, and it seems to have resolved the issue (for the last 24 hours, at least). I use VSCode Insiders full-time and update it on a near-daily basis. Some sort of toast message, triggered by the the "not enough memory" error, might be nice to alert the user to the issue and instruct them to clear out their ms-auth tokens.
Spoke too soon. After a few days of daily Insiders updates and whatnot, I've continually been prompted to sign into Microsoft to sync settings, and each time, I end up with a dozen or so new tokens into CredMan. They appear to just grow unbounded. Is that expected? Am I going to have to periodically run the command to clean these up? I assume I'll eventually hit the, "Not enough memory" error at some point if I just let the list continue to grow?
Thanks for the update. We'll be doing more drastic work in this space this month and next and my hope is that this will be resolved then.
I don't know if this is useful or not, but I've only seen a Microsoft Authentication problem when running multiple instances of VS Code. By this I mean: Start VS Code normally, do work... Open another instance with the "Workspaces: Duplicate As Workspace in New Window" command Do more work Shut down VS Code for the day with File-Exit, and not by closing each window individually with X in the upper right. Next day, start VS Code just by clicking the icon in my taskbar. Both instance windows show up in the same state I left them in the day before Work some more I haven't seen a problem for months because I WAS NOT doing the above workflow. When I opened another instance, I closed them separately, which means I only get one window on the next startup of VS Code. But I did do the above workflow last night and today and about 4-5 hours after starting it this morning the Microsoft authentication failed with messages: I have no idea what's causing this, but it seems that problems related to this happen more often with multiple instances running. There were a few people commenting on this issue that they were running multiple instances. I also don't know if this is happening because VS Code was started with 2 instances, like I did this morning, or if it is just sufficient to have more than one instance where the additional instances were started with that Duplicate command after the first instance was created. I tend to suspect the former because I never saw the problem when starting a VS Code session with just one initial instance. I saw it today after starting a session with 2 initial instances/windows. Again, I have no idea, but it feels like the two instances of VS Code are banging on the authenticator at the same time or are running some non-reentrant code at the same time on the way to the authenticator. HTH
I cleared out the credentials, but in less than a day I was back to more than 100 entries. The problem also started showing up on two machines that didn't have it, immediately after the latest update. (As in, 100+ credentials created starting in the minutes after VS Code restarted for the upgrade.) Notably, in light of the above comment, my setup does involve multiple restored windows - and the upgrade restart does restore them.
Thanks all. Sorry to hear this issue has not been fixed yet and sad that I've not been able to repro this. I will say that we have some plans in the works for dealing with secret storage in light of 's archival. More on that later.
I'm also running into this, my Windows Credential manager is full of lines like this: ! See and since yesterday it is full again, so I'd be happy to help debug this if you can point me to the right logging commands.
Not sure related or not, but the latest version would cause consuming high CPU, especially when VS Code thinks I need to re-log in my account.
Even after log-in, CPU usage would not restore. Need to close vscode all over
I think I have finally found the issue and have a PR out for this. Thank you all for your patience and providing good information. To help me, you can get the insider build here: My change will be in the insider build that will go out either Thursday or Friday.
So far so good, I installed the insider build, played with some different git repo folders, and I have only 2 entries in the Credential Manager: ! The second one seems to be fore github copilot.
My change hasn't gone in yet
I haven't seen this problem for about a week on Insiders build, after several attempts to remove all credentials manually or with script. Problem re-emerged few times, but works as expected after another run of the script. Hope update would fix it for everyone and it won't re-emerge again. P.S. I haven't use a lot of workspaces lately (as mentioned in PR), will try to get into bad state before update once again.
Looking at your fix, I might be more aggressive about deleting all the chunks even if one of those deletes fails, for example, could 2 vscode instances be trying to delete the same chunks at the same time? Do you know what the user scenario is that results in very large passwords that need chunking? That might help me test it better...
This isn't possible because deletes are now handled sequentially thanks to that PR. Microsoft Auth via Settings Sync. The limit in CredMan is a measly 2500 characters. A refresh token that gets stored in Cred Man is usually way larger than that. That refresh token also gets updated every reload of a window (every time Microsoft Auth extension is activated) hence the issue with multiple windows writing at the same time when a VS Code update happens.
Your suspected behavior written up in the PR definitely tracks with my usage patterns and observations. I'm looking forward to the fix! Should we clear out the hundreds of tokens inside CredMan ahead of your fix going live? Or will they get cleared/handled as part of your revised operations? Thanks!
you'll want to clear out CredMan.
I just updated to 1.76.1. Now multiple vscode windows cannot sign in sync. A sign-in of one window will kick off others'.
It's likely the same problem since this issue was addressed in 1.77 which is only in insiders and will be released in a few weeks.
I was able to reproduce on my PC with then before update and it "spammed" credentials. After cleaning up credentials, updating, cleaning up again - 12+ days without issues. I think I was asked once (it might been for GHPR extension), but there is definitely no "spam" in credentials so far. However, it took noticeable time to repro it in so hard to tell for sure
Thanks for your report This one...... will be hard to verify.... and I think what you did is as close to a proper verification as we will get. I will mark this as verified and we will see what the 1.77 stable release gives us in a couple weeks. If anyone sees this issue in 1.77-insiders until then, please don't hesitate to reach out.
This issue doesn't look the same as , but I'll wait for 1.77 and reopen my bug report if the issue is not fixed.
I have the exact same issue as and I agree that it doesn't appear the same as . I will also wait for the new fix and see if it fixes my problem.
Now I am asked regularly to choose account so sync my settings from and when the list appears the Microsoft account appears as "(signed in)". I cleared the stored authentications a week ago (before the 1.77 update).
Looks like folks still see this in 1.77 at least partially. I need a new issue because this one is just way to busy... so we'll keep going in
this is useful
Just want to report that on Windows, the keychain could get into a bad state due to this issue, after which even upgrading to the newer version of vscode doesn't help'. One would need to take the actions suggested in , as mentioned above, which solved the issue for me.
it is actually worse now. I am being asked to select the account to sync settings from repeatedly upon launching VS Code. The Microsoft accont I am using appears as "(Signed in)", so the token does not appear to be lost, just disacossiated. I can't see anything within the logs.
Is it worse or did your Windows credentials just get full? That happens to me from time-to-time and it's annoying. posted above provided a recipe for deleting all of the Windows credentials. This fixes it for a while, then I have to do it again.
folks, re-posting what I'm saying above:

import { Disposable } from 'vs/base/common/lifecycle'; import { ILogService } from 'vs/platform/log/common/log'; import { isWindows } from 'vs/base/common/platform'; <del> import { retry } from 'vs/base/common/async'; </del> <ins> import { retry, SequencerByKey } from 'vs/base/common/async'; </ins> interface ChunkedPassword { content: string;