Type: <bBug</ba TS file at the language status item in the status bar Bug The bracket icon is instead rendered as a pie chart icon <img width="222" alt="Screenshot 2023-01-18 at 1 28 37 PM" src="https://user-"VS Code version: Code - Insiders 1.75.0-insider (Universal) (, 2023-01-18T08:53:10.224Z) OS version: Darwin x64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Looks like the id for got duplicated:


The static "when" clause on chat participants should be moved to the set of things that are finalized.
what would happen when a participant becomes "disabled" after having been interacted with? Evaluating going from to and to again
It would just stop showing up in the suggest widget and you wouldn't be able to invoke it. But it can still show up in your conversation thread. Same as if you uninstall a chat extension.
Verify that can be set and used on the chat participant contribution in without api proposal needed. Easiest to use the .


Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing


Don't know if this is the intention or a bug. See
I believed this is a bug, and I've sent a PR for this. cc
It was indeed, thanks again


an explorer with a lot of elements tree horizontal scrolling covers the last element and there is no way to read nicely the content of that element I would expect the scroll is rendered below the last element, not on top of it
Can you share a screenshot?
If it could help, here is it: !
Also here's one from the explorer !
Seems to be a special case of combination between our scrollbar and the tree: the row is less than double the height of the scrollbar. We should add some extra pixels at the end of the view.
Hello. I want to take this issue. Could you give me a hint where should I start?
can i take this up? some insights will be helpful..


Type: <bBug</bI suddenly started getting the following message when my terminal starts up: I did not install anything but I did update the application. VS Code version: Code - Insiders 1.80.0-insider (Universal) (, 2023-06-21T08:23:42.803Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ vscode-tailwindcss0.9.11 language-hugo-vscode1.3.1 vscode-eslint2.4.0 gitlens14.0.1 prettier-vscode9.15.0 vscode-github-actions0.25.8 vscode-graphql0.8.13 vscode-graphql-execution0.1.8 vscode-graphql-syntax1.2.0 endwise1.5.1 vscode-duplicate1.2.1 remote-containers0.296.0 code-spell-checker2.20.5 vscode-mdx1.3.0 simple-ruby-erb0.2.1 gistfs0.4.1 pretty-ts-errors0.4.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I also encounter this issue!
Reproduces only when fish is installed via
IE contains binary so hard to know what's going on here !
any thoughts here?
FWIW is a (if you weren't using directly, vim, maybe you were looking at it with ?) and those are binary but probably isn't. It probably isn't interesting either. As for the problem, this happens at the initial invocation of so I'd guess it runs into the branch where exists and it's trying to initialize the integration but that function isn't defined yet, and I'd guess moving that invocation from line 125 to after is defined should fix this issue.
I think the idea that this bug is only present when using brew to install fish is not quite true, I'm seeing the issue on a Windows machine using WSL2.
Thanks that fixes the error. Shell integration still doesn't work because isn't getting run, so will investigate that
For this case, when installed via brew, there is a . Moving from to fixes this.


So the repro is to have a
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
should I be able to repro this just by installing fish with brew and using shell integration there or is there other custom fish config required?
Yep that is how I reproduced it
I have fish installed via are and have shell integration enabled and I am not seeing any errors neither in stable nor in insiders. Is there a step I am missing here to verify?
Reproduced in 1.80.0-insiders Verified fixed in


Issue Type: <bBug</bRepro settings editor, search for Bugs <img width="588" alt="Screen Shot 2020-03-16 at 10 04 28 PM" src="https://user-"In the settings UI: If I don't know what ligatures are, the description is not useful. Maybe link to our documentation? The description also does not explain the font features part. Maybe have an example? I have to use the settings json editor to actually change this setting. I suspect the most common use of this setting is turning it on or off In the settings json editor: It was not clear to me at first how to configure the font features (for a while, I thought it was supposed to be an object instead of a string) If you have and hover over the string, the description of what this string does is very generic VS Code version: Code - Insiders 1.44.0-insider (, 2020-03-16T07:10:59.884Z) OS version: Darwin x64 19.3.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
I'm moving this to backlog since this is more of debt/polish item (it's not one we'd expect users to search out and vote for)


Issue Type: <bBug</bAfter upgrading to 1.68, text selection in the integrated terminal does not show selected text. This is purely a visual glitch, as I can still copy what I had selected on the terminal. My colleague has the same version but does not have this issue, so I'm wondering if it's an issue introduced through my update. VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ project-manager12.6.0 github-markdown-preview0.3.0 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-footnotes0.0.7 markdown-mermaid1.14.0 markdown-preview-github-styles1.0.1 markdown-yaml-preamble0.1.0 keymapceditor-vsc0.7.7 gitignore0.7.0 doxdocgen1.4.0 transformer1.12.1 git-extension-pack0.1.3 githistory0.6.19 gitlens12.1.1 EditorConfig0.16.4 align-mode0.0.21 better-cpp-syntax1.15.18 cmake-language-support-vscode0.0.4 theme-karyfoundation-themes26.2.1 vscode-docker1.22.0 vscode-dotnet-runtime1.5.0 python2022.8.0 vscode-pylance2022.6.20 jupyter2022.5.


jupyter-keymap1.0.0 jupyter-renderers1.0.8 remote-containers0.238.2 remote-ssh0.82.1 remote-ssh-edit0.80.0 remote-wsl0.66.3 vscode-remote-extensionpack0.21.0 cmake-tools1.11.26 cpptools1.10.7 cpptools-extension-pack1.2.0 makefile-tools0.5.0 indent-rainbow8.3.1 vscode-pbtxt0.0.4 cmake0.0.17 vim1.22.2 clang-format1.9.0 vscode-open-in-github1.3.6 (5 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same issue, I'm using theme. When I switch to a different theme the selection is visible. Looks like a theme issue.
Can you reproduce the issue in Insider's? I see selection in Insider's when using solarized light, but it does seem pretty light !
I believe we're implementing solarized light correctly here and that's how it's meant to work. If you're not a fan of the low contrast selection you can change it with this setting: Otherwise change to a theme that you prefer. Let me know if I misunderstood and the selection is actually not visible (not just subtle).
I was using the theme for a while and I was used to the low contrast on selection. It was quite ok on my screen TBH. Now there's no visible selection. Here I've selected "Counting objects". I've actually pasted it from the terminal instead of typing to be sure. ! I don't think this issue is ready for closing.
Do you have any settings set and does changing help?
I strive to work on defaults. No settings in Setting to true causes selected letters to become slightly lighter, but no background. "si" selected ! Not sure if it has anything to do with it, but the issue seems to have started after the recent update (via PPA on an ubuntu flavor). After updating I didn't restart immediately, but attempted to open an image and everything crashed. Restarted after that and noticed selection not working a bit later.
Some more things to try: Does closing all windows and running fix it?


If not, can you share your full file? Running the Generate color theme from current settings command will let us see if there's something weird going on with the theme
Confirming this is only happening in Solarized Light
Disabling GPU doesn't help <details</summary{ "window.menuBarVisibility": "toggle", "editor.minimap.enabled": false, "[javascript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "javascript.updateImportsOnFileMove.enabled": "always", "[json]": { "editor.defaultFormatter": "" }, "[typescript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "": "stuff=", "explorer.confirmDelete": false, "explorer.confirmDragAndDrop": false, "[html]": { "editor.defaultFormatter": "" }, "[jsonc]": { "editor.defaultFormatter": "" }, "workbench.colorTheme": "Solarized Light", "editor.inlineSuggest.enabled": true, "editor.renderWhitespace": "none", "[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } } </details<details<summarycolor theme from current settings</summary</details
I can't reproduce based on those settings so I'm a bit stumped on what to do with this one
So I checked the terminal background on the screenshot and it's which is exactly the same color as the default selection color. the dump I pasted above had in it, which seems odd. But since you didn't raise it, I'm assuming it's supposed to mean the actual background is the one of the panel inside which the terminal is working. What I also noticed about the terminal panel is it's no longer giving me the option to move it to the bottom of the window, which is odd, but most of all when I right-click, it no longer says "move terminal right" as an option, but "move sidebar". I checked, and means I will no longer see my selection. Conclusion is what ends up being the color behind terminal text. The theme should probably set terminal background or change the selection color as a fix. I wonder what else breaks because terminal is now a sidebar not something else.
Ah ok, thanks for looking into it. Because of this, setting the terminal background explicitly is a good solution for now.


I doubt it happens in many other themes since contrast is usually pretty high but I'll check Solarized Dark as well when fixing.


The : This doesn't currently work in VSCode. It does support a very wide range of formats and I don't recall ever seeing this format before (even from GNU tools) so I suspect nobody else uses it. Nonetheless it's easy to add support in VSCode. See
Doesn't seem to work, see <img width="825" alt="Screenshot 2023-08-29 at 14 41 05" src=""
The PR intentionally left that out: But it should be easy to add so will leave this open.


<!-- 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.73.0 (Universal) OS Version: 13.0 Steps to Reproduce: open (cmd+p) file The UI button for from quick open works. The shortcut also works for file selection in the explorer My settings: Related 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.73.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Setting aside your Ctrl+Enter issue, did you know that Ctrl+RightArrow will already do what you want? It intentionally leaves the quickpick open so you can open another of the matches, but it's easy enough to close by pressing Esc.
ctrl+enter appears to be working for me even with your settings. What is it doing for you?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the late reply. has the same effect as for me, it opens the file in the current tab. this also opens the file in the current tab for me, leaving quickopen open
if you remove these keybinding settings, does anything change? I'd also love to see what settings you have in your user settings to see if maybe something is up there.
Thanks for reaching back. I commented all keyboard shortcuts and disabled all extensions. Indeed I got it to work when I commented all config of . Then I got to pinpoint it to this setting: which apparently needs to be .


Thanks for your help!
That's interesting. is there are scenario where we can open to the side but as a preview? I wonder if this is why this setting affects the behavior.
This is driven by this line: I can only speculate that when I re-implemented quick open, I took this behaviour over from our first version. If I had to guess, then we had this rule back then: always opens to the side opens an editor as non-preview when preview editors are enabled opens an editor to the side when preview editors are disabled So I would argue that -click is the key to use here, same as for the explorer for example. And has special semantics depending on your settings. But we can certainly revisit this and make it consistent if there is inconsistency.
Thanks. That is the behavior I see. Maybe we update the setting description to make this more clear? Current: Maybe we add: "non-preview" or whatever jargon we use. Thoughts Not entirely sure we need to define Preview editor here too.
Yeah I like the idea of updating settings, feel free to do that!
verification: read the docs for the settings. Does the use of there make sense (knowing that we don't want to change the behavior)


Visual Studio's Output window has a "Toggle Word Wrap" button, but VS Code has word wrapping always (?) enabled. For certain scenarious like the pending "C/C++ References" output it is desirable for word wrapping to be disabled for the results to be more easily read. There is a "View: Toggle Word Wrap" command, but it applies to the active document only (and not the Output panel, even if it's active). And/or if the OutputChannel interface could add a toggleWordWrap capability, that would allow extensions to set an appropriate default for their particular Output channel. This seems like a pretty basic feature that other Output channel providers would want, but I couldn't find an existing feature request on this.
This describes the same issue and led to adding a config option but it doesn't seem to work or the feature request was misunderstood?
Thanks a lot -- I can use that [Log] setting as a workaround (by setting it in our configurationDefaults); however, the result is still not ideal because it will apply to all Output windows and our C/C++ extension would prefer to isolate the behavior to a specific one. (And a button in the UI would make it easier for users to figure out how to overwrite our "no wrap" default).
Currently, one workaround is to set:
Yes, that is the same workaround I was describing (which our C/C++ extension uses), but it applies to all the output panes, and we'd prefer to isolate the change to a particular output pane (e.g. "C/C++" or "C/C++ References" and not "Git", etc.).
that's a nice to have feature.
For log files, I had the word wrap button visible & after a few moments it just disappeared
It looks like the 'editor.wordWrap' setting no longer works for [Log]. Was it removed intentionally or it is a bug?
That setting is working for me with non-Insiders VS Code with our C/C++ output window, but I see certain output panes like "Window" ignoring the setting somehow (i.e. it always wraps).
Ah, it's working for me now. It looks like it requires a Reload Window after it is set.
command is now also supported for Output Channels.


Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.


Testing ! !
doesn't reproduce in the panel chat
I somehow suffer from this change which explicitly targets some monaco tokens...
This isn't nice but there's actually no other way to override the foreground color of an editor- because typically you have syntax highlighting. We do this for all the other "input box"-style editors. I think I opened a feature request when I did this. We should align this rule with your rule for coloring the decoration so that it can override it properly.
labeling so it gets verified
Thanks
in the latest insider's, still seeing this ! !
There is two separate issues with different steps. There is a difference between rendering of slash command and normal prompt text. the only useful/visible information in the original issue description is slash commands (please use words and not images to describe issues!). For verification you have not used slash commands but normal prompt text which is a different case. Please file a separate issue, use words/steps and don't rely on screen captures with just white on white text
Steps to reproduce/verify use HC light and dark theme open inline chat and type a slash command, e.d make sure the command is readable when selecting its text


<!-- 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.71.0 (user setup) OS Version: Windows_NT x64 10.0. Git Version: 2.30.2 (Windows) Steps to Reproduce: a new directory a new Git repository a new file and append some text on the first lines this file to the staging the line with text An OS native dialog box error pops up with the title of this issue as text. In the console output for Git: I have had this problem for a long time, 2 years I would say. I thought someone would have reported it but it seems not.
I'm having a similar issue on macOS 12.6 (21G115). If you have deleted lines at the top of a file and click the little arrow to undo the change, the error pops up. Notably, it still completes the undo. <img width="396" alt="image" src="https://user-"
apologies for not getting back to you on this. I used the repro steps above but I was unable to reproduce the problem with the latest VS Code Insiders (1.75) release. Could you please do me a favour and see if you are still able to reproduce the issue? If so, could you please share a recording using so that I can further investigate the issue? Thanks!
Issue is still present in the latest insider release on macOS. !


VSCode info: Version: 1.75.0-insider Commit: Date: 2022-12-19T05:35:41.089Z (10 hrs ago) Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes


There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:


<!-- 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.75.0-insider OS Version: Linux Hello, IMHO, the block cursor could use a different background. Default Dark+ Experimental (v2): ! ! Default Dark+: ! ! Default Dark+ Experimental (v2): with some cursor background color. For ex: ! ! ! ! Edit (one more option) (with color set to 's value, giving inverted cursor effect) ! ! Thanks


Presumably related to . Adding breakpoints to lines with gutter icons causes the icon to be stretched and cropped: ! I don't know if related, but I'm using :
The problem is that we set each decoration 's width to be the width of the entire gutter (which is sized to fit potentially multiple decorations, so sets which ends up stretching the decoration to fit the entire gutter instead of just its lane.
Fix looks good, thanks! /verified


type at the end of line have ghost text accept it word by word when reaching the end of the viewport accepted words aren't revealed https://user-
fyi that I have pushed as a fix for this
Thank you! Sorry for not fixing this, I thought the fix was more complicated.
Accepting single word seems to move the horizontal scroll, but tabbing to accept the whole line does not scroll. Is that expected?
Marking as verified as word by word works.


Error while turning off settings sync ! Might happen when turning off settings sync while a sync is happening
Can't repro this anymore.


Under some circumstances, the Code Action button won't go away and will still run its assign command (incorrectly) Steps to Reproduce: an error with 'Quick Fix' available ! the cursor on the same line and press to bring up the quickfix ! to cancel ! the code action button ! the button again ! again ! ! at step 4. the button should disappear, but it does not I found this bug while adding Code Actions to my personal extension VS Code Version: 1.88.1 OS Version: Windows 11


Perhaps we forgot to update the distro json files (for stable, insiders, oss)?
!
it was to distro weeks and many commits ago. I'm not seeing the same error, even when that API is used in insiders/pre-release. - Do you know if I forgot a step for enabling this?
I think there's a typo, in of distro you have `"NotebookCellExecution", and in jupyter extension you have , notice the casing of the first char


Steps to Reproduce: a notebook with the jupyter extension installed context keys the context key contains the entire contents of the file for that extension:


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.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --Pasting the below into a markdown file will cause a cpu thread to be pinned at 100% because of catastrophic backtracking. fixes it.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.947 --<!-- potentialduplicatescomment --
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


WebView width is limited to 780px. ! It shrinks all images included what makes them barely readable. What's the point of this limit? It should be set to either 100% or more reasonable 1200px, but would be best to manage it through <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.43 OS Version: Windows 10 Steps to Reproduce: any extension page including images in VSCode or hit Help -Release notes <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes and with all themes
Very long lines of text are not readable You can view the web release notes (or the ones on GitHub) if you want a different layout
seriously? Someone having problems with reading lines longer than 780px is the reason for this!? Do you even realise how ridiculous it is? And what exactly is a design problem here that it can't be managed by user settings like almost everything else? Please, reopen this issue.
You are welcome to submit a PR that makes images larger (while keeping the max text line length the same). However even the images should likely have a max width. See how GitHub and many other sites render readmes
My point exactly! GitHub's limit for content width is 882px and I believe it was also like that for VSCode few versions ago. Why it was lowered to 780px is inexplicable. Plus on GitHub you can actually click the image for full size. That's why even Microsoft often adds images 2000px+ width in readmes.
It is now 100px wider :)
Baby steps I'd rather make it 1200px or 100%, but I doubt it would be approved. Maybe someday it will be managed through settings for everyone's content... Thanks


a command that yields an error in the terminal the quick fix, in the terminal, -` in panel chat !
I'm unable to repro this. However, I do see an issue with additional unnecessary contexts being invoked. See attached issue for more info. Not a issue.
I cannot reproduce this behavior when coming from the terminal quick fix !
But the very first time I attempt submitting the query, I see that is not picked up by VS Code, cc !
Actually, I now repro not being picked up 100% of the time. We have two s and we're picking the first one, then dropping it because it's not available in panel chat
Today, I'm not seeing the copilot quick fix in the terminal at all !
Works for me on Windows with Powershell, latest Insiders + prerelease :shrug:


Testing <img width="290" alt="image" src=""I feel like this context menu should not show up in this case - and in fact, it doesn't if you right click on the commit message to the right... it just repros when you right click on the graph part (the dots, or the lines)


<!-- 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.79.0 OS Version: Windows 10, 22H2 Steps to Reproduce: a remote location (e.g. a WSL window) or something else that leads to the simple open file dialog being used a dotfile (e.g. ) an open file dialog with , you can use e.g. the "Create project from ST project" action from the embedded tools extension that the file is not available for selection (it can only be manually entered) Note: I originally reported this to the embedded-tools extension (see ), where the "Create project from ST project" dialog doesn't allow you to select the required files when working on WSL. They have however redirected me here.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Just to clarify: I have tested this with both the latest stable release, as well as with the latest insider version. Both exhibit the same broken behavior
I think this is you because it talks about the simple file picker.
I think you own . It looks like it doesn't recognize a file named as having an extension of . For now, I will just make the fix in the simple file picker, but should this change actually be made in ?


Since profiles are removed, the jupyter extension will show their "run above/below" commands unless we put them back in the cell toolbar by default, so we should just disable this setting until we have a jupyter profile available that disables it


<!-- 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!


Type: <bBug</bIssue Reporter, e.g. from off Command Palette. the first dropdown to VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-24T07:50:18.385Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
good catch, thanks! looks like an issue with the refactor


a TS file, use the keyboard and type out a syntax error. The scrollbar error marker doesn't show up. the text cursor to another location using the mouse. The scrollbar error marker shows up then. says:
Very likely a regression from


VSCode Version: 1.47 insiders OS Version: Windows Steps to Reproduce: on the "Add item" button in and press enter. ! Does this issue occur when all extensions are disabled?: Yes


Issue Type: <bBug</bWhile doing some experimentation with Bootstrap and the corresponding scss files, I encountered an issue while changing hexcolor codes. I was able to reproduce it on a different Windows machine (Windows 11 in that case) as well as on macOS (Monterey). Steps to reproduce: Open a large scss file. In my case, I used from the Bootstrap framework. Start changing a color by typing a different hex value. The issue only happened when changing at least two of the six digits and sometimes only after making a couple of changes. It did not happen when using the color picker. will become unresponsive eventually. For example the color pickers do not show up anymore, saving a file takes multiple seconds and the git integration stops working entirely. When the builtin SCSS extension is disabled, everything works fine. Therefore I would assume that this extension is causing the issue. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I can reproduce open a scss file with on the end of line 15, add a character . Note that diagnostics appear, Remove the character, diagnostics disappear (all good) on the end of line 15, add a character . Nothing happens. Hover over a symbol, hover computes forever: Extension host is blocked remove the letter, reload the window disable the emmet extension repeat the steps, now all is working When profiling, the emmet extension is busy in The bug got introduced in 1.53
There are 3 conditions that must be met to trigger this issue: must return one of , , , , or (so that in returns true). File must be longer than 1000 lines (so that is called as noted above). The first must begin with The culprit is from When trying to skip over blocks, this function attempts to peak back 1 character when it encounters to check for a (1)()` is then called to move the position back to where it was at the start of the function, but in this case moves it back to position 1:2.


This causes the loop that calls to loop infinitely, as the exit condition (position being to , in this case the start of the file) never occurs. Pull Request Resolves this by checking if the character being "peaked" at is a and breaking out of before is called. An alternative solution would be to not call if is within 3 characters of (as there is not enough space remaining to contain .
Thanks for the explanation I'll comment on the PR.


<!-- Do Not Delete This! bugreporttemplate --Issue Type: <bBug</bWhen trying to run with a markdown-code which contains a picture, a is thrown: My extension uses the vscode-parser for converting markdown-files to pdf, so my extension depends on the vscode-parser and needs it to work. Steps to Reproduce: a new extension to the -file following code to the extension: VS Code version: Code - Insiders 1.54.0-insider (, 2021-02-18T05:14:01.684Z) OS version: WindowsNT x64 10.0.


<details<summarySystem Info</summary </details<details<summaryExtensions (41)</summaryExtensionVersion ------ silverstripe1.0.6 ts-loader-problem-matcher0.3.0 markdown-emoji0.0.9 markdown-mermaid1.9.2 better-toml0.3.2 arm1.5.0 javascript-ejs-support1.3.1 vscode-reveal4.0.3 php-debug1.14.9 php-intellisense2.3.14 php-pack1.0.2 cshtml-tm1.0.0 coldfusion1.0.1 reg1.0.2 vscode-edit-csv0.5.4 vscode-peacock3.9.1 languague-renpy1.0.6 eslint-language-service1.0.8 rainbow-csv1.8.1 git-graph1.28.0 vscode-apache1.2.0 csharp1.23.9 remote-containers0.160.0 remote-ssh0.64.0 remote-ssh-edit0.64.0 remote-wsl0.54.0 vscode-remote-extensionpack0.20.0 hexeditor1.4.0 powershell2020.6.0 vscode-typescript-tslint-plugin1.3.3 vsliveshare1.0.3784 debugger-for-chrome4.12.12 php-docblocker2.1.0 material-icon-theme4.5.0 ejs-language-support0.0.1 ruby0.28.1 vscode-yaml0.15.0 vbsvscode1.2.0 vscodeintellicode1.2.11 vscode-ruby0.28.0 markdown-all-in-one3.4.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
We'd take a PR. However this looks specific to how your extension is using the markdown extension point in an unsupported way so this is not something we'll prioritize fixing
Thanks a lot for your rapid answer. I found myself able to refactor the package to make rendering work again out of the box. I'll open up a PR asap.
/verified


Tracks updating the TS 5.4.4. recovery build
Actually may wait for TS 5.4.5 with a fix for auto imports
Merging 5.4.4 for now


White on gray is not readable. I think the explorer tree has a different behavior here. !
Which theme is this?
Default Light+


Does this issue occur when all extensions are disabled?: Yes VS Code Version: OS Version: Steps to Reproduce: a terminal window within vscode and run this command: vscode hangs indefinitely, using 100% CPU on one core. It would be nice if that didn't happen.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I'm using web version (Vscode Server) and this code snippet cause the entirely browser tab to crash: ! Wanted to provide profiling info but profiler hanged too
I can reproduce
Nice find
Upstream:


found testing for a cell to get output ctrl+down to focus the output :bug: visually, it looks like the cell container is focused.
in the insiders build of 1.83.0, NVDA 2023.2 does read the output but like said it doesn't visually focus it. Unlike NVDA JAWS 2023.2307 doesn't even read the output. And even pressing alt+F2 while using JAWS, accessible view is not even pulled up/JAWS doesn't do anything. While output focus issue is not found in version 1.81.1 with JAWS 2023.2307. Seems like VS Code bug.
So this worked but with the keybindings on Mac. Not sure if the keybinding you mentioned is the keybinding on another platform like windows?
yes sorry, didn't notice that mac keybinding was different


Testing Version: 1.75.0-insider Commit: Date: 2023-01-24T05:22:50.699Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Linux x64 5.15.0-56-generic Sandboxed: Yes Export a profile to a file Confirmation dialog shows a question mark, but there's no question here !
It's better on Windows: !
We can change all dialogs from to use instead of type. This only seems to have an impact on Linux and changes the icon to an info icon.


I see this telemetry event getting sent when toggling the screen reader on whilst vscode is open, however if a screenreader is already on when the editor is opened, the telemetry event doesn't get fired as it's only triggered by Electron's event. This probably isn't the desired implementation here.
I can take this.
Thanks for catching and fixing this


cursor is rendered on top of it <img width="400" src="https://user-"Version: 1.78.0 Commit: Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.78.0 Chrome/108.0.5359.215 Electron/22.4.8 Safari/537.36
Hi thank you for filing the issue. I tried to reproduce this issue, but it seems to work fine on my computer. Could you please try spawning a color picker in the latest VS Code Insiders (). If you continue seeing this issue, could you please try to run VS Code Insiders without any extensions and reproduce this error? It so happens sometimes that extensions cause errors. If you still see this issue, do you think you could copy paste below a minimally reproducible example of the contents of the editor where this happens?
<details</summary</details! Maybe it only reproduces with zoom? Should it render like that with markers? !
Hi, thanks for the reply, could you post here a copy of your settings file. I am thinking this error could be happening in relation to one of your settings.
Hmmm, it's a 2000 line-long file, not sure how useful it would be. It looks like I can reproduce it on the web with browser zoom and . On desktop that would be:


Problem: A popup opens, displaying: "The 'Remote - WSL' extension is recommended for opening a terminal in WSL." It has a 'Dont Show Again' and an 'Install' option. Clicking Don't Show Again has no effect. Expected Behaviour: Once I click Don't Show Again, this popup doesn't appear every single time I open the WSL terminal in VS Code. VSCode Version: 1.38.1 (user setup) OS Version: Windows_NT x64 10.0. Steps to Reproduce: WSL Ubuntu installed on Windows. the WSL integrated terminal on VS Code. Does this issue occur when all extensions are disabled?: No.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.614 --- <!-- score: 0.559 --- <!-- score: 0.549 --- <!-- score: 0.54 --- <!-- score: 0.52 --<!-- potentialduplicatescomment --
I wanna take a shot at this!
Does this happen on different workspaces or on the same workspace? Edit: I have checked and this only happens when you open different workspaces (Different project folders with VSCode) I personally think that this should not be the case and should be global so I will make a pull request for it.
Sorry for the late reply. I see you've already pushed a fix for this, so thanks a lot :)
Should I close the issue now?


Testing open search viewlet drag explorer (activity icon) into search pane all explorer views are now in the search pane it is not possible to drag the file/folder view back into the explorer https://user-
verified since the empty explorer is gone


Testing have search view open drag the explorer icon onto it the explorer (and npm script) views show the explorer icon stays in the activity bar, the view is empty https://user-


Notice how in the step was stuck in the following line for at around 2 hours: This could either be from or from . Maybe we should put a log between those. In any case, my bets go against the former... which can be resolved with the  option. WDYT? cc
You're a PowerShell pro now!


Type: <bBug</bDev Container with default or the prefered profile a new profile from Current Profile Settings After reloading the window you get a message to install the remote containers extension and when opening the profile in a local workspace you can see that no extensions and no settings where copied from the old profile. VS Code version: Code - Insiders 1.70.0-insider (, 2022-07-08T05:20:13.606Z) OS version: WindowsNT x64 10.0. Modes: Restricted Connection to 'vscode-remote' could not be established No remote extension installed to resolve dev-container. <details<summarySystem Info</summary Connection to 'vscode-remote' could not be established No remote extension installed to resolve dev-container. </detailsExtensions: none <!-- generated by issue reporter --


Splitting from Clone mock-debug Run the tests Resize the window so the debug console has lots of wrapping Run the tests again After a few tests run, the Debug Console will stop scrolling down automatically and just remain part-way through. <img width="838" alt="Screenshot 2021-02-25 at 12 08 28" src="https://user-"
thanks for steps I can reproduce this. here I am hitting the limitation of what the tree gives me. Currently I use the following heurisitc to figure out if the last element is visible in the tree However that does not give the correct result when elements are wrapped and take additional lines. So I could either somehow update that check, or I could use the . I would just care if there are elements after the last visible element, but I could not figure out any tree api to get next neighbour of the last visible element. Might I be missing something? Let me know what you think, thanks.
What 3 values does it return in that case?
In this step we are good: In the next step we are no longer good:
and me investigated into this and it seems to be related to how async code is handled on the list side. Thus assigning this to on-deck and once finds time he can look into a fix or recommend a workaround for me on the Debug Console side.
Any progress on this issue? Would be great to not have to manually scroll down during the debug session.
Not to my knowledge. I've been told a small trick though In the debug console, hit Shift+Tab to move focus from the input box to the output list. Now you can just hit End once to move to the end of the list.
thanks for the tip, but going through all that hassle every single time I type in a command in the debug console or try to inspect a variable by printing out its type is simply not worth it. are there any viable workarounds to this? I believe it makes the debug console pretty much impossible to use for the average python developer.
Workaround is As for progress, we plan to fix this however not sure when. did an initial investigation and it proved more complex than anticipated.
Thanks for your valuable feedback. This works for me. I should probably add that should be to the and not the Just out of curiosity, doesn't that basically solve the problem?


What else is there to fix?
Setting wordWrap to false will not display all output. The line before print(True) is only partially visible. !
Setting to false also hide the last line (image). It happens when an exception is thrown (e.g., ) Please fix this! !
any update?
That () was a super annoying bug, but today i found this thread and turned off (turned on by default) and it scrolls down automatically!
Please god if you exists, please re-create the universe except this terrible bug. The bug makes us sad every minutes in Flutter-based development...
I want to have auto-scroll with word wrap functionality. This is very annoying bug.
Maybe this got worse recently, but I am seeing it happen with no wrapping involved, just the simplest single-line output. I think I have a fix. Basically add an item, call updateChildren list renders the item off screen. getHeight returns an estimate that is off by 1px dynamic height is not probed because it is offscreen in tries to scroll to the bottom, but using a scrollHeight measurement that is off by 1px item is rendered, dynamic height is probed, size is fixed, but that means the list is no longer scrolled all the way down, so stops autoscrolling I have an easy workaround to watch for content height change events from the list and update the scroll at this point. I think only Debug Console needs this feature - if it's ever needed anywhere else, we should implement it inside the List.
The issue still occurs. I have to manually scroll down to see the newest logs.
Yep, me too. I've turned off wordWrap and smartScrollin my and I still have to scroll down in the interactive console whenever I run code :( - specifcally, when I run code from the interactive console 'Type python code here and press Enter to run' line, as opposed to when I use a keyboard shortcut to send a selection of code to the interactive console (that seems to scroll okay, unless it is a long output - then it doesn't scroll either way). Print(5) for me, run directly from the interactive console, doesn't auto-scroll enough to see the output, even with these settings here:
can you share a code snippet that reproduces the issue? I don't see an issue.


it sounds like you might be using the interactive window which is not what this issue is about. If so, that is
I'm debugging Flutter apps with option which sometimes outputs a lot of lines of logs at once. I suspect that breaks it. When the log density is normal, it works.
How can the fix be tested? Do we need to build from source or is it in the Insiders version?
It went out in the latest stable update. If you're still seeing the issue I can reopen it and investigate a little more
I set up a flutter app and tried debugging it in verbose mode, but it doesn't do anything unusual and I don't see an issue. Also tried some other cases with different types of log messages printed very quickly. are you able to share the app? Or if not, a screen recording of the console, or screenshot of the point where it stops scrolling might help
So, basically wrapped lines considered as single line, therefore it miscalculating how many lines to scroll by?
I'm not seeing an issue with wrapped lines anymore
I'm not sure this is particularly helpful information (besides maybe helping confirm there's still an issue), but I was just able to reproduce this with a Flutter project (on current stable), but have been unable to repro again while recording. It happened while Flutter was doing checks (it prints a lot of very verbose output with all the HTTP requests to the Pub API). I've tried clearing my Pub cache and modifying my pubspec (with so Flutter would re-check Pub packages when the debug session starts), but have been unable to trigger it again (nor could I repro with the original steps using mock-debug above).
Oh, perhaps noteworthy, when it did happen (sorry I didn't take screenshot, I thought it would be easy to repro!), the last few lines printed were a very long line (a large JSON payload) followed by 1 or 2 short (unwrapped) lines.
Issue is still happening. I can't find a good pattern to suspect and reproduce it. All I remember is I had disabled the content wrap setting to give it a shot on my wide screen. Reverting it later did not help. I was doing Flutter development on VSCode for 3 years, and from that day, I'm getting this very annoying bug.


Can you share the project, or the exact log text that causes it so I can try to reproduce it?
I have a fix which I think only affects the case when wordwrap is disabled. From this thread, I'm not sure whether anyone was still seeing an issue with wordwrap enabled. It got a lot easier to repro after my fix for fixed an issue with sizing.
Here's the code I was using to repro the issue: and
I can't repro now, but I saw this again a few days ago, but I do not have wordWrap set, it's on the default (). If I see it again, is there any useful info I can get from it (other than a shareable repro ofc, assuming I can't make one).


<!-- 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.76.0 OS Version: Windows 10 The most recent VS Code update broke bracket colorization for PHP files, when you close a PHP tag then open it again before using a closing bracket. Steps to Reproduce: a PHP file a PHP open tag , open a bracket with , use an end tag , step 2, but with a closed bracket show as red, and the coloured line that joins the brackets doesn't show. Note: The red brackets are normally only used for errors, so it makes it look like there's errors in the file Screenshot: !
Same problem here on Unbutu! Could you fix it please?
Same error on ubuntu Ubuntu 22.04.2 LTS
Also happens if you just have the opening tag but no closing tag at the end: !
Hello, thank you to open this topic. I have the same issue while writing PHP code on VSC. It would be great if could be fixed. Have a nice day !!
Same issue here on Mac OS 13.2.1
Same here
For anyone who needs this fix before the next update: Add this to your settings JSON (fix via PR )
I have a similar issue using math equations in markdown, the image on the left is version 1.76 and the one on the right is 1.75.1, both of them with the same settings (by sharing them). The fix suggested by did not resolve my problem. Should I open a new issue since it is a different language and context? !


Possibly related on Stack Overflow:
Related: :
Same issue with me
You should scope it to language, otherwise the bracket setting applys to all languages
The update and modified settings as suggested by didn't solve the issue I mentioned in . Might be related to . Below is the today's insiders version w/o any extensions with the same issue despite even scoping the brackets as suggested by above. !
omh same here lol..


open test explorer notice that the input has the wrong background color, e.g it has two background colors <img width="455" alt="Screenshot 2023-11-15 at 14 29 05" src=""
What theme are you using? I can see the slight difference in your screenshot, but inspecting things I'm not seeing any backgrounds being applied to that action / menu bar
Like, any light theme?
Still confused on the latest Insiders for me in e.g. solarized light: <img width="725" alt="image" src=""Does it reproduce on a fresh user-data-dir for you? If so, are you able to do a quick devtools inspect and give a hint as to what styling is being applied that makes monaco input have a different background color?
I see. It doesn't show with an empty profile but I also don't have any setting that screams test explorer background color
Could you bisect your user settings or share them so I can play around?
This seems to be because I have the test explorer in the secondary sidebar. There is some settings that controls this but I have no clue which one it is <img width="2188" alt="Screenshot 2023-12-12 at 18 02 53" src=""
CSS is fun


<img width="603" alt="image" src="https://user-"
!


Testing Ctrl+[RightLeft] Ctrl+Up — put the cell in edit mode and focused the editor, I expected it to move the focus to the preview cell without changing the selection (like Windows Explorer) Ctrl+Down — seems to scroll down slowly. Again I expected it to move the focus to the next cell without changing the selection
It seems the ctrl+arrows are already being used by actions.
Meaning expand/collapse headers? Why? If I understand correctly, this is basically what arrow up/down by themselves are already doing, right? ctrl+up/down are matching the editor by scrolling without moving focus. Except that they are double-booked with focus in/out of output, which maybe should only happen when focus is in the editor
I think the only thing to fix here is that ctrl+up invokes when focus is not in the output, and focuses the editor.


VSCode Version: 1.41.1 OS Version: irrelevant Steps to Reproduce: : type Declaration: line 2316 [location links][#LocationLink] -(#LocationLink) Does this issue occur when all extensions are disabled?: Yes
Please remove it immediately and make it your top priority. To me this is almost equally offensive as a swastika.
He think it's funny to imitate .


Issue Type: <bBug</bSee the , which provides two tasks and and a README with these steps. the task the task again. that each failed in its own terminal, despite what the message in the terminal said. the terminal and press a key to close it. the task . the task again. that both failed in the same terminal, again not shared with the task. closing the terminal, run the task again. that the task reuses the terminal now, but doesn't fail. Instead it just produces no output at all, and doesn't seem to signal that it's finished. The task doesn't hang, it just fails. Its terminal gets reused like the one from . Ideally both tasks would emit the exact same sequence events, including both and so the listener can determine that the task failed. VS Code version: Code - Insiders 1.63.0-insider (, 2021-11-29T08:08:44.056Z) OS version: Linux x64 5.15.4-201.fc35.x8664 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions disabled<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
or I think the cause of the problem is that doesn't fire when a process task exits with an error like this. I don't think there's anything suspicious in the shell launch configs: ! Would you expect to fire if the process errors out early like this (the command to run doesn't exist)?
When the call to create/start the process fails, like when doesn't exist, it should fire the event here:
It does do that, but it seems that something is still not cleaned up somewhere as process tasks run in a re-used terminal don't output the message at all.
If you have this repro set up could you also log these? This is where the output happens:
In a non-reused terminal: is set to undefined there. is set to the expected message. gets run and gets hit. In a re-used terminal: None of those lines are hit. When I kill the terminal manually they are all hit, but all those values are undefined.
This looks much better than before! However, I still see the task's terminal have an . Is this expected?


Tasks expects the exit code to not be in this case because it indicates that the terminal is being disposed and cannot be reused: Because of this, tasks doesn't keep the terminal around in the task system for re-using, so subsequent tasks will get a new terminal, which is unexpected.
I think undefined for is expected here because a process never launches, instead it fails because the executable is missing before we try to launch the process. This is different to which would run something like and that would exit.
is there a way I can tell on the tasks side if a terminal is being disposed vs. just had the above situation happen? I'd like to reuse it if it's not being disposed so that the user experience is consistent. Just iterate though the and see if the instance with the same ID is still there?
Internally we use to differentiate these: I guess we could just expose that as a type in too, looks like tasks is still the only consumer that uses the value on the event I believe. If you want to try this, change this line: To this or similar:
I'll make the tasks changes in February:


I'm using the on a keybinding to quickly switch between different components in a project. A slightly frustrating behavior is that the window list appears in the same order in both windows. This means that when you do , the first window in the list is always selected. So, if you have 2 windows open and you're switching back and forth between them, you have to remember two key combinations, one for each window you're in: Switching from Window 1 to Window 2: Switching from Window 2 to Window 1: only I propose defaulting the selection to be the first entry that is not the current window. That way, it is a "quick switch" indeed. :) Thoughts? I will implement this when I have time if there is no objection.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.612 --<!-- potentialduplicatescomment --
Don't believe this is a duplicate - the other issues think this unexpected behavior is a bug, while this issue proposes a way to make the behavior closer to what the user expects.
Another way this could work is to by default, select the window after the current window in the window switcher. So you can quickly flip through 3 or more windows.


<!-- 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.82.3 OS Version: Ventura 13.6 This one was tricky to investigate and is impacting the and & scenario. In that scenario, VS Code is started from one application using the macOS command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue. When opening either from the macOS Finder or through , the VS Code application will expand the PATH of its subprocess so that extensions that depend on something in the path of the terminal will find it. So in my case, if I start VS Code from the Finder, the processes will look like this: This is expected and good. Extensions can find in the PATH. The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get: So in my second workspace, will not be found in the PATH.


For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal) Steps to Reproduce: Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI) the Sandbox for the project: <img width="562" alt="Screenshot 2023-10-03 at 10 33 02 AM" src=""the look like this: the variables and to point to 2 different workspaces. the project, I personally use in command line. all VS Code instances. the .app from the Finder, it will be in if you built from the command line by default. the button As you can see from the code, the .app will: set the PATH with a marker open a new VS Code workspace on workspace1 wait a bit open a new VS Code workspace on workspace2 activity monitor, find the child process ID: <img width="1045" alt="Screenshot 2023-10-03 at 10 40 50 AM" src=""the terminal, look at their path: (Your pid may vary) that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:
I think you're best equip to handle this issue? but feel free to reassign to whoever.
I can't repro this. To know more, please do the following: Quit VS Code From a Terminal, run , this should open VS Code In that window, run and set it to . Then, from a Terminal, run , this should open the second window On the second window, reveal the Output panel and the Window logs. Search for , what do you find?
the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS. As I said in the bug:
Using is the same as launching from Finder. Let me know the result.


I'm afraid it's not exactly the same as it exhibits a different behavior as it appears the second instance of the process will simply inherit the PATH of the process that started it, instead of expanding the PATH to be like a terminal Using twice will work as expected from the Terminal as the second instance of the process will inherit the PATH of the Terminal. Using the repro steps to create an app that will call on Visual Studio Code twice won't work as expected. If I close all VSC instances, and do twice on two different workspaces, I get: Things are visibility different as the main Code process seems to inherits the PATH from the Terminal. Whereas if I launch Code manually from the Finder, I get: So there is a difference.
Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), did not propagate environments. It seems like it does now. Can you try just once more with: , replacing with the path to the workspace? Thanks, I really appreciate it!
Version: 1.84.0-insider Commit: With from the Terminal I get the same behavior as :
Hi we're seeing a growing number of customer reports on this. I think I've provided all the info that was needed including a way to create a self-contained repro. How could we get this looked at? Thanks!
Same here guys. Just installed unity + vscode and have this message about missing net sdk. I came from here.
I came here from microsoft/vscode-dotnettools as well – and I'm glad I did! I've been banging my head against the " isn't on the PATH" issue (and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code. I generally open my Unity Projects is with the following: the project in Unity. "Open C# Project" from the Assets menu. <img width="253" alt="image" src=""If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find !" issues. a new VS Code window (keyboard shortcut/menu/palette/whatever).


the project from within VS Code. In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there. Regardless, if I open the project in VS Code in this manner, everything works as expected.
sorry for the silence here. Let's try to figure this one out. First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why... In any case, can I ask you for one more piece of info? from Finder (main process regular PATH, Code Helper with sourced PATH) a Terminal, call the command with the path to the second workspace. What's the of that second Code Helper process that comes up? Resolved?
Hey thanks for bumping this, happy new year, looking forward to having a resolution for this. That happened to me before I turned the sandbox off. See step 2 of the repro? We could also try the real world scenario with Unity, but it's going to be a slightly longer setup, I'd encourage you to reach out to my email at work to help get you setup. In that case: The main Visual Studio App inherits the PATH of the Finder (so just /usr/bin:/bin) The first process gets a PATH expended. The second process inherits the PATH of the Terminal, verified by doing: Just before calling in the Terminal.
Sorry about that. It runs correctly now! And I can repro! Funny: it seems to only affect the variable. If, say, one adds to , that gets properly propagated to both extension hosts (). Interesting, digging more...
Nice! Good luck :)
Got it!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Issue Type: <bBug The following does not indicate that this is from the universal Mac build: VS Code version: Code - Insiders 1.53.0-insider (, 2021-01-26T05:12:23.287Z) OS version: Darwin x64 19.6.0 Remote OS version: Linux x64 5.4.39-linuxkit <details<summarySystem Info</summary </details<details<summaryExtensions (35)</summaryExtensionVersion ------ unique-lines1.0.0 persona0.0.3 regex0.2.0 vscode-eslint2.1.14 ghlink1.2.0 remotehub0.5.0 tsl-problem-matcher0.3.1 EditorConfig0.16.4 vscode-npm-script0.3.13 codespaces0.6.0 vscode-pull-request-github0.22.0 vscode-mocha-test-adapter2.9.1 vscode-test-explorer2.19.5 rest-client0.24.4 graphql-for-vscode1.15.3 template-string-converter0.4.7 git-graph1.28.0 vscode-azureappservice0.20.0 vscode-docker1.9.1 vscode-kubernetes-tools1.2.3 remote-containers0.156.0 remote-ssh0.63.0 remote-ssh-edit0.63.0 remote-wsl0.53.1 azure-account0.9.4 azurecli0.5.0 hexeditor1.3.0 vscode-github-issue-notebooks0.0.60 debugger-for-chrome4.12.11 vscode-versionlens1.0.9 vscode-yaml0.14.0 music-time2.1.0 vscode-open-in-github1.14.0 vscodeintellicode1.2.10 vscode-test-resolver0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
To verify. check if the universal apps version information in about dialog as well as issue reporter details have it like <img width="564" alt="Screen Shot 2021-01-27 at 8 32 54 PM" src="https://user-"


I have a setting in my settings. Everytime I reload, I see a setting being . This keeps on happening, the old setting is never removed. ! Not sure if this should be a candidate. does this code look right to you? Or does migration also need to remove the old setting?
If you want to remove the old setting you should explicitly mention that in the migration like below
Can the migration function be made in a way that people do not forget this?


<!-- 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 <!-- 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: OS Version: Steps to Reproduce: Relatively niche but: refactor menu (action widget) over a disabled action either arrow keys or typing filter to select an item. that the disabled action becomes highlighted !


Type: <bBug</bI use the shell: When I start VS Code not from the terminal, I see a popup with the error: I know why this issue occurs - it's because VS Code is assuming bash semantics for launching the user's shell in order to solicit environment variables. I encountered the . In that report, I reached out to the xonsh project (xonsh/xonsh) to see if the shell might be able to support bash syntax for this purpose, but after some consideration, they rejected the idea, instead asking editors to honor the shell. Here I'm making the same request to VS Code, namely that if the shell is xonsh ("xonsh" appears in the user's shell path), to use a syntax specialized for xonsh to extract the user's environment, namely: If direct support for xonsh can't be , would you consider adding a configuration variable such that a user of xonsh could customize VS Code to honor xonsh as the default shell? VS Code version: Code 1.85.0 (Universal) (, 2023-12-06T18:18:04.614Z) OS version: Darwin arm64 23.1.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ copilot1.141.0 copilot-chat0.11.0 black-formatter2023.6.0 isort2023.10.1 python2023.22.0 vscode-pylance2023.11.10 sublime-keybindings4.0.10 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I acknowledge that starting VSCode from the CLI does work around the issue, but even then only for that launch. If I launch VS Code from the CLI, then it has to restart (such as due to an update), it once again is unable to resolve settings and the error appears.
I believe this is or ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!


This is a backlog candidate but still PRs are welcome. Here's where explicit xonsh support would need to be :
this is being in with minimal testing, could you track any comments/issues with it while I'm out in January? We mainly just need author verification
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verified by installing and starting insiders from the terminal. I didn't see the error mentioned above. would be good if you'd confirm this.
I can confirm, with 1.86.0-insider, the error is gone. I was unable to test on the original machine, but I've tested on a new, similarly configured machine (and confirmed that the default shell is configured for xonsh, same as reported above). I'm so delighted that it's fixed and that I was able to help. Thanks for the guidance and support. /verified


https://user- <img width="801" alt="image" src="https://user-"
I see the same, but figured it was down to the selected VS Code profile being enabled for that workspace?


Testing have a file that is empty run type the file is dirty close the window run !
This is tricky: on the main side we open one window as instructed from the command line with the file and we also open another window to restore backups. Since we do not actually know the files to restore on the main side (we just rely on the renderer side to do this), we are opening 2 windows without knowing that the same file ends up being opened 2 times. Imho what should happen is this: if we know that we are restoring empty windows with backups, we just add all the files (as instructed from the command line) to one of those empty windows to avoid that we open multiple windows. This should happen in method ideally. We do the same if we are about to open a window with a folder: all other files to open (or create) end up being opened in that window of the folder.
I have a PR up for this via though I am not sure this is the best fix :). Basically what it does is to see if upon startup we have windows opening with hot-exit files to restore (either folder or untitled). If we find any such window to open, we open files to open files to create files to diff inside the first of these windows that upon as a matter of restoring hot-exit data. So instead of getting an extra window opened for the files to open, they would open into the first window that is being opened as a matter of hot-exit restore. what do you think?
I think this is a pretty good fix. It seems to align with how the CLI works when windows are opened as well; instead of opening the files in the last active window, the first window to be restored is selected.
Ok, merged.


Type: <bBug</bWelcome - Learn the Fyndamentals Safely browse and edit code Workspace Trust Link 404 - page not found VS Code version: Code 1.91.1 (, 2024-07-09T22:06:49.809Z) OS version: Windows_NT x64 10.0. Modes: Restricted <!-- generated by issue reporter --
could you please provide a screenshot of where this broken link is? Thanks!
Got it - issue is in the walkthrough. Fix incoming. Thanks for signaling this
Is this a candidate? The change has been merged to the main branch but not the release branch, and so the fix is not in the latest Insiders.
IMO, it can go with the next one.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.47.0 OS Version: macOS Catalina 10.15.5 Steps to Reproduce: Every time when I click File -New File, vscode always asks to select an Editor, but in the list, there is only one Built-in Text editor. it's just a very annoying unnecessary click. I don't know since when this has been , I believe it's a recent change. Tried to remove all the User settings and start without extensions, didn't help. See the screenshot. <img width="1086" alt="Screen Shot 2020-07-12 at 9 35 03 pm" src="https://user-"<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No Yes
Hi, I would like to work on this issue if no one else is.
Sorry I did't claim before starting, I have fixed it, please correct me if the solution is not ok.
I removed all the User settings and extensions, useless
No worries. Go ahead


VS Code Version: 1.60.2 OS Version: Windows 10 Home 20H2 64bit Steps to Reproduce: the VS Code to 1.60.2. the cursor to the training process area, and watch the information. Actually I have completed 2 steps and there are 4 steps, but the information shows that there are 2 steps and I have completed 4 steps. !


Checkout the screen capture below which shows totally broken views. Notice the view title in the bottom panel and the missing icon the secondary sidebar (in my setup the secondary sidebar is left, the primary is right). I suspect this is due to setting/view sync because I have connected a windows VM <img width="1494" alt="Screenshot 2024-01-23 at 12 10 56" src=""
Have you tried clicking on those broken views and found out what those views are?
Analysed the data provided by and this is what happened Windows machine has some obsolete custom view containers state (in pane composite bar) which we are not cleaning up . When sync started, this machine has pushed this state, for eg:Mac machine has accepted this state and started rendering this obsolete view container even though this does not exist. This seems to be a bug in pane composite bar that render view containers - it is rendering obsolete view containers placeholders even though they do not exists in the model.
verified by code review


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --Same issue as , just on a different version. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48 OS Version: Windows 10 <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Edit Possible reason: In , is missing. imports this script but it is not there. This might explain why the submit action does nothing. Edit 2 Thanks, for the workaround:  it in
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.803 --- <!-- score: 0.503 --- <!-- score: 0.499 --- <!-- score: 0.459 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
FYI, I was able to get it working by downloading and placing the following file.
Confirm, an old bug returned.
Where to place it?
Not exactly an old bug. It's more like the devs team forgot to bundle the 1 single script. See my edit of the OP.
I think the easiest workaround is to install the downgraded VSCode from the following link.
same on MacOS. Makes the whole tool useless as you can't click anything than force quit the application.
looks like this file needs to be explicitly listed somewhere here to be included in the build (I think the does not exist anymore and can be removed):
Sorry about the breakage. Thanks for narrowing down the issue.
Steps to verify: Clone cd basic-auth && open code-insiders Settings Proxy http://127.0.0.1:3129 Open developer tools fetch('') or perform any network request play with the auth dialog verify the auth dialog can be opened again once proxy config is changed


On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


VSCode Version: Code 1.13.1 (, 2017-06-14T18:21:47.485Z) OS Version: Windows_NT ia32 10.0. Extensions: ; Steps to Reproduce: color theme "Quiet Light" F something !
What is the expected color? Is the color wrong for the text, the buttons?
I would expect that the color with the current status gets a little bit more contrast...
What do you mean by 'current status'? The box around the 'case sensitive' button?
You actually do not see it, 'cause its contrast is that bad :D ! I see that on a very old monitor, I'm curious it has more contrast than yours. :O
Same issue here. Confirm that the bug exists. It should be instead of Can I send a PR for this? EDIT - Looking at other light theme it should be more of a red color than a gray one. Example - Light( Visual Studio ) has


Testing Scenario: Have a webview editor extension installed that contributes for .txt. Create a new file. Enter something in it so it isn't empty. Save it as What should happen next? Currently, nothing happens. It stays in the default VS Code editor. It might make sense to have the choose editor quick pick open.
Fixing this was more challenging than expected, pushing to November
It looks like renaming works and opens in the custom editor per my preferences, but if I save an untitled file as in the issue, nothing happens.
Marking for April Custom editors use to open a custom editor in place of the default editor. When a untitled editor is saved, is called but this goes directly to which bypasses the . Let me know if there's some other event we can listen to to detect when an untitled editor is saved. I couldn't find anything while debugging through the code
I guess this needs to be wired in, PR welcome.
I believe this will also apply to notebooks. I'll let you know what I come up with
Assigning you since this seems like something we should think about for all editor types, including notebooks
I discussed this issue a bit with Kai and it doesn't sound like we will be fixing this any time soon. The main drive is for notebooks where you see "Hey this is a .ipnyb file, install the jupyter extension" and then the user clicks install but there ipnyb is still plain JSON. The goal for that is to allow rendering of those files without execution if no extension is installed. For the other cases it's not nearly as important as most files have a usable text editor type. We want to reduce the number of notifications as much as possible and switching the file for the user could be extremely jarring.
Since I just came across the relevant code, we have a way to replace an editor when it is saved (to a different path or when saving untitled): This code does not go through any override but rather takes the typed editor input as it was returned from the implementation. If we were to change that logic, we probably would have to ask method to return an untyped input without override, or at least make sure the text based editors don't set the override.
I think that there needs to be better UX if we were to implement this as a saveAs causing an editor type switch can be jarring.


I don't love the notification approach but maybe something along those lines. User gets prompted that there is an ew editor type for this resource -user can choose to switch or set automatic switching -editor switches. If automatic switching enabled we no longer prompt and just switch anyways for that resource type
Yup agreed, didn't mean to ask to solve this now, just wanted to keep track of the location in code where this is currently decided
To verify: an untitled file it as jupyter notebook should be created your setting to have the entry steps 1 and 2 with a different file name shouldn't switch to a notebook, it should stay as a text
I tried above steps with the GitHub issue notebook extension instead and when I come to step 5. and save an untitled editor as "", that editor actually closes.
My settings: My extensions: Video: !


Issue Type: <bBug</bThe cursor after pasting, I'd expect it to be at the end of the pasted text: ! VS Code version: Code - Insiders 1.26.0-insider (, 2018-08-02T05:12:16.245Z) OS version: Darwin x64 17.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ 999-pack10.12.6 ssh0.0.4 github-issues-prs0.9.0 vscode-open-in-github1.7.0 </details<!-- generated by issue reporter --


<!-- 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 <!-- 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: OS Version: Steps to Reproduce: Cloud Changes on the button: <img width="713" alt="image" src="https://user-"appears but no changes are made locally at least my change doesn't go away. Logs don't indicate anything interesting
I encountered this issue myself because I had branches that had the same name locally, but their upstream branches were set differently. My local workaround was to to get Cloud Changes to do the right thing, but the only way I figured this out was by looking at logs. It would be nice for Cloud Changes to at the very least show an error message or something when I click "Resume Working Changes" but it intentionally no-ops.
sorry, misclicked a label


While verifying I noticed that if I click on the warning I'm not taken to the size limit setting which I would've expected to be taken to. ! Version: 1.68.0-insider (Universal) Commit: Date: 2022-06-02T05:16:30.515Z Electron: 17.4.6 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 Jupyter Extension version (available under the Extensions sidebar): v2022.5. Python Extension version (available under the Extensions sidebar): v2022.7.
This link is specified in core code.
The issue doesn't seem to be fixed in the latest insiders. Reopening
The issue is now fixed for me in the latest Insiders, at least on Windows 11.


Type: <bBug from Marketplace which is a packaged version of fsprovider-sample Panel, switch to Output tab and choose Tasks channel. no folder or workspace open, run the command. the "Workspace folder was undefined" message. The message come from here: I think the task system is trying to do something (an onFolderOpen task?) for the memfs scheme before the task system for that scheme has been registered. As a minimum change I think the message should become "Task system for ${} is unavailable". Better, the message could be suppressed. Best, the sequencing could be revised so the task system registration for the FSP's scheme happens before it is first used. Further observation is that running does not produce the message again. VS Code version: Code 1.82.0 (, 2023-09-06T22:07:07.438Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
Note, this is not a new 1.82 problem. It also happened in 1.81.1.
I started looking at fixing this, but didn't find a path that calls for any schemes other than and . Should it also be getting called for schemes that s implement?
The "Workspace folder was undefined" message was introduced by Pinging and about what should happen for a scheme contributed by a FSP.
Scratch that - I believe I have answered my own question in the PR I just submitted.


Does this issue occur when all extensions are disabled?: I dont know VS Code Version: 1.88.0-insider OS Version: Windows 10 - 10.0. Build Steps to Reproduce: Start debugging python script. It creates a new "debugging terminal". This should work stop debugging debugging. If you look at the debugging terminal, you will see a input (generated by VS Code) then command for debugging the selected file. path of the is somehow truncated, hence cannot find the file. debugging is however starting: you will be prompted with the message: Timed out waiting for launcher to connect. As seen on the gif below: Path 1st time: (Correct path) Path 2nd time: (truncated path) !
I'm getting similar behaviour when using Git Bash as default profile. First time debugging the Python Debug Console opens and the application runs without issue: the subsequent times I sometimes get: ... which does in fact executes the code, but then I also sometimes get: I don't know what the call to comes from (possible the end of the directory name, but in in the last instance is not called. This inevitable gives this error. ! Which then starts a new Python Debug Console. Similar to what is above. I don't see this behaviour when using PowerShell or Cmd. IMO There's some weird truncation happening. Version: 1.88.0 (user setup) Commit: Date: 2024-04-03T13:26:18.741Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.
Thank you for adding details! This is the exact same problem that I experience: I didn't try with another terminal (Powershell or Cmd). I will see if that can fix my problem temporary using .
As mentionned by This issue is not here using . However, this is still adding extra command that could be the explanation behind it: ! The first run it is only using: On the second run, it : before the command.


There is still the before this line though (2nd blank line)
I am seeing the problem when I set my default terminal profile to any of the following and run my debug launch script twice. Each shell will fail on the second launch with the same mangled command line. bash command prompt powershell Work around: revert back to vs code 1.87.
I am having a similar problem launching Python from VS.Code with or without debugging (both cmd and wt as terminal.external.windowsExec). If the path to the Python executable contains space as in default I end up with and an error message in the launched terminal window: Yet this works fine if I pick a Python interpreter from venv or somewhere else such that there is no space in path e.g. Curiously - the internal terminal and internal console work with either path
it seems sending the ctrl+c in a separate is not sufficient -- any suggestions?
If you want to execute something again we have a helper on the render process side , this conditionally sends a ^C and may wait for a shell integration prompt. That might work?
It looks like that does the same thing with a 100ms delay. I'll adopt the delay as well, see if that fixes it
please could you confirm when this will be released? It doesn't seem to have gone out in the latest April release. I've tried the insiders version and can't debug anything so it's even worse.
This is available on Insiders. Please open another issue with the details for not being able to debug anything; that's probably not related to this fix...
Can any of you verify that this is fixed in the newest version of VS Code Insiders? Thanks!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
The external terminal launch is working with space in pythonInterpreter path () using both and as Windows Terminal in current: 1.89.1 and insiders 1.90.0 /verified
Running on version 1.90.0 I can not longer observe the truncation.


The execution command looks intact even after multiple runs. ! There's an extraneous whenever you start a run but I guess that's intentional.
I am experiencing this issue using Python Debugger: Current File with Arguments. I am using ver VSCode ver 1.9


Summary: The sign-in link for Github in VSCode running through serve-web rotates ports in the 54xxx range, breaking any pre-set port forwarding for users connecting via SSH. This occurs regardless of any port option set with --port (taken from my comment in ) Does this issue occur when all extensions are disabled?: Yes VS Code Version: Insiders 1.82.0 OS Version: Mac OS 13.3 Steps to Reproduce: to the device hosting code via SSH, with local port forwarding for port 8000 enabled the remote device, launch serve-web with a browser window and navigate to the URL given by serve-web on settings sync, showing a github sign-in URL. Note the port is different than the default, requiring you to reconnect and add a new forwarded port Expected behavior: Setting the port with --port should (a) also determine the port used for sign-in, or (b) be a separate option so that SSH port forwarding does not require updating SSH config and reconnecting each time you need to sign in
is the github sign-in URL in step 4 coming from you?
This flow shouldn't actually happen in the remote case and instead the user should get the device code flow. Fixed this by disabling the local server flow in
Verification: turn on Settings Sync using GitHub when you go through the auth flow, you should get the Device Code Flow first


Testing This is sort of unrelated to the TPI, but when I inspect context keys on my terminal area, I notice that it has , even when the active terminal isn't using git bash. Here are my repro steps (not sure if this can be simplified): a terminal profile using an extension and launch the extension. git bash, then close it and open the extension-provided terminal profile. context keys on the extension-provided terminal instance. :bug:
I would like to solve this problem, if it is still an issue. Do you mind if I start?
sure!
After scanning some source, there seems no good way to solve this. Because is no way for extension to specify terminal type when (AFAIK) extension register a terminal profile ( ), and Windows, shell type is determined by some heuristic logic, based on executable string, and default to return . (For WSL, the shell type is always "undefined" in my quick experiment.) When terminal service try to update context key, it fallback to NOP if the shell type is , that's the behavior noticed at first place. See: For this issue to be solved, probably there should be a way for builtin terminal profile to specify shell type (so it works for all bultin profile in all platform), and for extension provided terminal profiles, maybe we can add more optional fields to or method to . As for the wierd behavior noticed currently, maybe we can set to "unknown", to make this state less confusing. But since that this behavior is already state in , I wonder this can be changed.
I think the problem is here: It should check if first, then set it even if it's undefined if
do you want to submit a PR since you investigated and found the problem?
Yes, I can submit a PR for this. But, before doing this, I need to confirm some detail. The current behavior is From A. If new terminal instance is created, and shell type of the new terminal istance is defined, update From B. If active terminal instance change, and shell type of the new terminal istance is defined, update C. If there is no terminal instance, reset D. otherwise, do nothing so the editor keeps last known when shell type is undefined during new terminal creation or active terminal change. If so, what value should be set on this case? should we set it to or just call ?