Out of curiosity, any reason why settings.json's global values weren't moved automatically to the root level after the upgrade? You migrate the config on multiple occasions which is good, but not this time.

I myself had this problem and got into #5489 even though I scanned changelog before the upgrade, but haven't picked up that I have actually to change something in my config :slightly_smiling_face:

If you had settings hanging out in the globals dictionary, you'll want to move them out.
Failure to do so will cause us to ignore your default profile, launch mode, etc., etc.
THIS INCLUDES defaultProfile

You might want to reword that from "move them out" as that really doesn't say nearly enough to anyone. Be specific:

...you will need to move them to the root object of the settings.json.

@bmarkovic that’s a great suggestion, thank you. I appreciate that you edited your comment.

In my particular case this didn't restore functionality of keybindings, did something change about the format (or the JSON key name)?

Interesting. If you scroll down, do you happen to have a separate copy of keybindings? That may be an obnoxious gotcha on top of all this ☹️

Unfortunately, no.

I see in #3600 that "command" is an object now, is that mandatory (i.e. the old format where "command" is string no longer works)?

Also in my config, "keys" is an array, here it is a string.

E.g.

        {
            "command" : "newTab",
            "keys" : 
            [
                "ctrl+t"
            ]
        },

Nah, action+command (the object format) isn’t mandatory, and keys can be either a string or an array... Would you mind sharing a gist of your settings?

Off course not.

https://gist.github.com/bmarkovic/485363256672f4be66379c4d9a604c81

Edit: In case someone else comes along with an issue like this, the issue is that A LOT of these settings have changed and are no longer valid. If you are using VS.Code it will respect the new JSON schema, underline the things that are no longer valid, and you will have to refer to:

https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md

for the format of the new settings.

Ah, I'm gonna guess that the key bindings that aren't working are the Ctrl+Shift+# ones. Sorry our documentation failed you here -- those are included in the legacy settings removal from #5190. Right now, I think those old bindings are replacing the default bindings with their no-longer-effective legacy versions and you can just delete them.

Here's a better way out, though:

Judging by all the key bindings, the format, and the profiles containing every config option, it looks like that settings file predates 0.2. I really think it's great that you've been with us that long (since our first public release!) Thanks! Versions of Terminal after 0.5 lay down a cool new settings template that's more streamlined, and is a bit better-documented. There's a set of "default" settings now that live in the terminal package that your settings get applied on top of.

It's not a requirement by any means, but you might be a bit happier in general if you spend a couple minutes migrating.

1. move your old settings file aside
2. let Terminal make a new one (automatic on startup)
3. copy over key bindings that you care about (since you're using pre-0.2 settings, you might care that Ctrl+W and Ctrl+T are bound to close/open tab (which was a bad decision we made almost a whole year ago).
4. copy over some profiles you care about.

The settings model change from 0.5 means you don't need to specify every option in every profile, and you don't need to be quite so aggressive in customizing everything.

I took a stab at it -- this should be equivalent to your old settings, but with a whole bunch of the legacy cruft removed.

https://gist.github.com/DHowett-MSFT/ec2d24cf2b84e1555fb56a1192e4fb94

I didn't know if you used alt+N for switching tabs, but those were some of the old key bindings in your settings and I didn't want to go stomp them :smile:
A bunch of your "duplicated" settings got moved into the "defaults" group.. cuts down on repetitive lines for sure.

The hallmark of an old (version 0.2) settings file is ctrl+w being bound, and being bound to closeTab (it closes the whole tab, even if there's panes inside it). The modern binding is Ctrl+Shift+W for closePane, which only closes the active focused pane.

Hah, I've done it myself too in the meantime (I updated the alt+ tab switches, as I did use them) as well. I will take a look at your take on it too. This machine is not really my day-job driver (contrary to, I guess, most people, the Windows box is a play thing, and I earn my bread and butter on a Linux desktop) so that might be why I've not updated all this before.

Here is a pretty verbatim translation of my settings file to new schema (with a change here and there to make use of some new, previously unavailable settings), from my quick test they all do work after I change the target commands and format. I'll look at the "no-legacy cruft" version you pasted as well (I don't want get attached my non-standard bindings) and probably make some combo for future use.

Thank you for the help, and I do love the program. It has completely replaced ConEmu as the go-to terminal emulator on Windows for me.

Thank you for the help, and I do love the program. It has completely replaced ConEmu as the go-to terminal emulator on Windows for me.

Happy to hear that, and I'm sorry it's been a bit of a bumpy ride here on the preview train 😅

When starting the update it asked 'Close all Windows', i pressed 'Cancel'..
It Closed WT anyway.... 😡😡😒

That's unrelated to this issue, but also something I don't think we can avoid. I looked hard for an API to tell the system that we should not be killed for updates ☹️

So, how do I remove Azure Cloud Shell now ? "disabledProfileSources" has been removed.

It's not a requirement by any means, but you might be a bit happier in general if you spend a couple minutes migrating.

1. move your old settings file aside

2. let Terminal make a new one (automatic on startup)

3. copy over key bindings that you care about (since you're using pre-0.2 settings, you might care that Ctrl+W and Ctrl+T are bound to close/open tab (which was a bad decision we made almost a whole year ago).

4. copy over some profiles you care about.

I followed this procedure and it worked great, thank you 🙏

P.S. Comments in json files, I HAVE SEEN THE FUTURE!

@Naomi010Sentzke

"hidden": true,

Or, just continue to use disabledProfileSources under the requirements described at the top of this thread.

after this update, my default font was changed and the most importantly I can't use switchToTab0, switchToTab1... keybindings

I set ctrl+Num to switch tab, but it doesn't work. Only the default setting, ctrl+alt+Num can switch tabs...

@GrayXu you just need to open your settings.json and move all your setting under the globals key to the top level.

@GrayXu you just need to open your settings.json and move all your setting under the globalSettings key to the top level.

I followed UsingJsonSettings.md#key-bindings, and I think I put keybindings under Global Settings.
here is my config:

{
"$schema": "https://aka.ms/terminal-profiles-schema",
...
"keybindings": [
        ...
        {
            "command": "switchToTab0",
            "keys": [
                "ctrl+1"
            ]
        },
        ...
]
...
}

Some keybinding in this config works normally, including nextTab, closePane and so on. But switchToTab0 didn't work.

switchToTab0..switchToTab9 in keybinding were broken

@TeoTN Sure was - Check this post for more details: https://github.com/microsoft/terminal/issues/3600#issuecomment-608654738

Deprecated Setting | Replacement Setting
-- | --
switchToTab0 - switchToTab8 | { "command": { "action": "switchToTab", "index": NUMBER }, "keys": "ctrl+alt+NUMBER" }

@TeoTN Sure was - Check this post for more details: #3600 (comment)

Deprecated Setting
Replacement Setting

switchToTab0 - switchToTab8
{ "command": { "action": "switchToTab", "index": NUMBER }, "keys": "ctrl+alt+NUMBER" }

Thanks! I didn't know the new settings. But when I tried to use { "command": { "action": "switchToTab", "index": 1}, "keys": "ctrl+2" }, it didn't work.
And it's werid that { "command": { "action": "switchToTab", "index": 0}, "keys": "ctrl+1" } works

@TeoTN Sure was - Check this post for more details: #3600 (comment)

Deprecated Setting
Replacement Setting
switchToTab0 - switchToTab8
{ "command": { "action": "switchToTab", "index": NUMBER }, "keys": "ctrl+alt+NUMBER" }

Thanks! I didn't know the new settings. But when I tried to use { "command": { "action": "switchToTab", "index": 1}, "keys": "ctrl+2" }, it didn't work.
And it's werid that { "command": { "action": "switchToTab", "index": 0}, "keys": "ctrl+1" } works

Thanks for bringing up.

I too experienced strange behavior with the switchToTab action. However, this boiled down to my mistake. I ended up finding a single deprecated key (unrelated to the switchToTab action) accidentally copied over (by me). After removing all deprecated settings, everything (incl. switchToTab is good to go on my end. IMO the new command structure is clearer 👍

I will say that needing to increment the NUMBER value for the "keys" key versus the "index" key, e.g.

// working snippet
   { 
        "command": {
            "action":  "switchToTab", 
            "index": 0 
        }, 
        "keys": "alt+1"
    },
    {
        "command" :  {
            "action": "switchToTab",
            "index": 1
        }, 
        "keys" :  "alt+2"
    },
    ...

is a tad strange, however, I suspect there's a good reason underlying that choice. Documenting here in the event that's not the case.

I will say that needing to increment the NUMBER value for the "keys" key versus the "index" key, ... is a tad strange, however, I suspect there's a good reason underlying that choice.

There is! We wanted 0-indexed arguments because _we're not monsters_, but we also wanted to use alt+1 as "go to the first tab", because (at least on en-us keyboard layouts) 1 is the _first_ number key on the left. This way, the first tab is on the first number key, the second tab is on the second number key, etc.

@TeoTN Sure was - Check this post for more details: #3600 (comment)

Deprecated Setting
Replacement Setting

switchToTab0 - switchToTab8
{ "command": { "action": "switchToTab", "index": NUMBER }, "keys": "ctrl+alt+NUMBER" }

So that's the experience that Windows Terminal promotes? Do you imagine, for instance, iTerm2 on MacOS silently breaking your settings with an autoupdate and saying "yea, we've broken that, off you go"? Why don't you migrate that automatically for users?

So that's the experience that Windows Terminal promotes?

_iTerm2 is not preview software. Windows Terminal (Preview) is._

So that's the experience that Windows Terminal promotes?

_iTerm2 is not preview software. Windows Terminal (Preview) is._

So you don't have users trying to get used to that and you can break their environments silently because "that's a preview" and perhaps "you could have found that if you were reading all comments and updates on our GitHub page"?

Even this thread's name... You knew that you will break people's environment, and there was no warning before update, no message to help get onboarded, no effort to _auto-migrate_. It's just "we break things and deal with it". I think this is a terrible user experience.

just thought id say that whilst my profile hasnt been broken - the behavior of ctrl-shift-v now results in a crash. the wsl keeps running in the background but the terminal crashes and tahts a little annoying hahaha. as a linuxy person ctrl shift v is muscle memory :( lol

Wow, that definitely should not happen.

want me to do anything ?

can reproduce it consistently currently (havnt rebooted tho)

Please file a separate issue. Thanks! If possible, please include a feedback hub link.

actually nvm - its my bad! i just realised its caused as a result of my unsuported use case. it doesnt do it on first run - it does it as a result of copying and pasting from inside an x session on xming into the console with ctrl shift v. ill hold back on a bug report for now until i have precise info. thanks for your fast reply!

@DHowett-MSFT (re: issue title) lol that's exactly how I felt but i found this and got it all sorted. The reorganization seems to be much cleaner.

after this update, my default font was changed and the most importantly I can't use switchToTab0, switchToTab1... keybindings

I set ctrl+Num to switch tab, but it doesn't work. Only the default setting, ctrl+alt+Num can switch tabs...

by ref https://raw.githubusercontent.com/microsoft/terminal/release-0.11/doc/cascadia/profiles.schema.json

following config can start new tab successfully

{
       "command" : {
        "action": "newTab",
        "index": 0
    },
        "keys" : ["ctrl+shift+1"]
},

Any reason why my WSL Ubuntu console theme/colors disappeared?

I deleted the settings file but still:

This looks like an issue in your shell configuration. WT hasn't changed how it launches WSL, and WSL hasn't changed how it spawns your shell.

See this page for more information... Meanwhile this page doesn't have any documentation on how to fix the warning error.... #3145

Meanwhile this page doesn't have any documentation on how to fix the warning error

Huh?

???

File location?

The same place you would usually configure your settings -- in the file opened by the Settings menu item, or %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json.

We omitted that from the documentation here because we assumed people knew how to get to their settings files.

I guess I'm retarded then that I don't know the in's and out's of Windows terminal 0.11.1191.0 or you could just do better documentation.. #justsayin

How can I determine what user settings file that Windows Terminal is trying to load that contains the deprecated global setting? I have searched for Profile.ps1 and Microsoft.PowerShell_profile.ps1 to no avail.

You can get to the terminal settings file by opening up the +v menu (by clicking the v)

You can get to the terminal settings file by opening up the +v menu (by clicking the v)

Thank you for the prompt reply. However the settings.json file looks fine. The error prompted with is when I launch Windows Terminal and presented with the following.

The "globals" property is deprecated - your settings might need updating. For more info, see this web page.

So, if you have never edited your settings in Terminal you might be happier just deleting the contents of that file. If you have, and you want to keep your customizations, you can delete the “globals {“ line and the equivalent “}” at the end of the globals. Check out the “if your file looks like this...” section at the top of the page.

So, if you have never edited your settings in Terminal you might be happier just deleting the contents of that file. If you have, and you want to keep your customizations, you can delete the “globals {“ line and the equivalent “}” at the end of the globals. Check out the “if your file looks like this...” section at the top of the page.

Resolved, thank you for your prompt support!

This warning dialog really could have used a direct link to the settings file to make it more seamless to open for editing. Also, a detection of when the only change to the settings file needed to make it valid again was to hoist the stuff from globals up could have been implemented and the settings file auto-patched. Not a big deal overall, but feels like a miss in terms of UX/DX.

This warning dialog really could have used a direct link to the settings file to make it more seamless to open for editing. Also, a detection of when the only change to the settings file needed to make it valid again was to hoist the stuff from globals up could have been implemented and the settings file auto-patched. Not a big deal overall, but feels like a miss in terms of UX/DX.

You can also just access it from the Terminal tab down arrow and click settings.

This warning dialog really could have used a direct link to the settings file to make it more seamless to open for editing. Also, a detection of when the only change to the settings file needed to make it valid again was to hoist the stuff from globals up could have been implemented and the settings file auto-patched. Not a big deal overall, but feels like a miss in terms of UX/DX.

You can also just access it from the Terminal tab down arrow and click settings.

This is the piece that helped me and I wish would be mentioned in the original post. Thank you.

I have the Terminal from Microsoft Store and managed to fix this while keeping the console themes by copying the original settings.json content, deleting it and pasting lines from "profiles" block into the new JSON:

[
        {
            "acrylicOpacity" : 0.5,
            "background" : "#012456",
            "closeOnExit" : true,
            "colorScheme" : "Campbell",
            "commandline" : "powershell.exe",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 10,
            "guid" : "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "historySize" : 9001,
            "icon" : "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png",
            "name" : "Windows PowerShell",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : "%USERPROFILE%",
            "useAcrylic" : false
        },
        {
            "acrylicOpacity" : 0.75,
            "closeOnExit" : true,
            "colorScheme" : "Campbell",
            "commandline" : "cmd.exe",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 10,
            "guid" : "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "historySize" : 9001,
            "icon" : "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png",
            "name" : "cmd",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : "%USERPROFILE%",
            "useAcrylic" : true
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": false,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure"
        }
    ],
    "schemes" : 
    [
        {
            "background" : "#0C0C0C",
            "black" : "#0C0C0C",
            "blue" : "#0037DA",
            "brightBlack" : "#767676",
            "brightBlue" : "#3B78FF",
            "brightCyan" : "#61D6D6",
            "brightGreen" : "#16C60C",
            "brightPurple" : "#B4009E",
            "brightRed" : "#E74856",
            "brightWhite" : "#F2F2F2",
            "brightYellow" : "#F9F1A5",
            "cyan" : "#3A96DD",
            "foreground" : "#CCCCCC",
            "green" : "#13A10E",
            "name" : "Campbell",
            "purple" : "#881798",
            "red" : "#C50F1F",
            "white" : "#CCCCCC",
            "yellow" : "#C19C00"
        },
        {
            "background" : "#282C34",
            "black" : "#282C34",
            "blue" : "#61AFEF",
            "brightBlack" : "#5A6374",
            "brightBlue" : "#61AFEF",
            "brightCyan" : "#56B6C2",
            "brightGreen" : "#98C379",
            "brightPurple" : "#C678DD",
            "brightRed" : "#E06C75",
            "brightWhite" : "#DCDFE4",
            "brightYellow" : "#E5C07B",
            "cyan" : "#56B6C2",
            "foreground" : "#DCDFE4",
            "green" : "#98C379",
            "name" : "One Half Dark",
            "purple" : "#C678DD",
            "red" : "#E06C75",
            "white" : "#DCDFE4",
            "yellow" : "#E5C07B"
        },
        {
            "background" : "#FAFAFA",
            "black" : "#383A42",
            "blue" : "#0184BC",
            "brightBlack" : "#4F525D",
            "brightBlue" : "#61AFEF",
            "brightCyan" : "#56B5C1",
            "brightGreen" : "#98C379",
            "brightPurple" : "#C577DD",
            "brightRed" : "#DF6C75",
            "brightWhite" : "#FFFFFF",
            "brightYellow" : "#E4C07A",
            "cyan" : "#0997B3",
            "foreground" : "#383A42",
            "green" : "#50A14F",
            "name" : "One Half Light",
            "purple" : "#A626A4",
            "red" : "#E45649",
            "white" : "#FAFAFA",
            "yellow" : "#C18301"
        },
        {
            "background" : "#002B36",
            "black" : "#073642",
            "blue" : "#268BD2",
            "brightBlack" : "#002B36",
            "brightBlue" : "#839496",
            "brightCyan" : "#93A1A1",
            "brightGreen" : "#586E75",
            "brightPurple" : "#6C71C4",
            "brightRed" : "#CB4B16",
            "brightWhite" : "#FDF6E3",
            "brightYellow" : "#657B83",
            "cyan" : "#2AA198",
            "foreground" : "#839496",
            "green" : "#859900",
            "name" : "Solarized Dark",
            "purple" : "#D33682",
            "red" : "#DC322F",
            "white" : "#EEE8D5",
            "yellow" : "#B58900"
        },
        {
            "background" : "#FDF6E3",
            "black" : "#073642",
            "blue" : "#268BD2",
            "brightBlack" : "#002B36",
            "brightBlue" : "#839496",
            "brightCyan" : "#93A1A1",
            "brightGreen" : "#586E75",
            "brightPurple" : "#6C71C4",
            "brightRed" : "#CB4B16",
            "brightWhite" : "#FDF6E3",
            "brightYellow" : "#657B83",
            "cyan" : "#2AA198",
            "foreground" : "#657B83",
            "green" : "#859900",
            "name" : "Solarized Light",
            "purple" : "#D33682",
            "red" : "#DC322F",
            "white" : "#EEE8D5",
            "yellow" : "#B58900"
        }
    ]

What a pain. Appreciate the commenting in the new generated settings.json but a straight copy/paste from the older version doesn't work. Cannot get color schemes working and now they are forcing you to have an enabled Azure Cloud Shell profile enabled. Comment it out, save, and it pops right back in.

From #5611

Wow, if you had colorscheme in your settings file, you must have installed the Terminal an exceptionally long time ago. Thanks for sticking with us for so long through the preview process ❤️!

As you've found out, the colorscheme key was deprecated in favor of colorScheme. Largely, we're tracking all the "upgrade to 0.11 broke my settings" bugs with #5458, so I'm gonna close this thread as a duplicate.

Thanks!

Maybe try changing "hidden": false 🤔 from #5684:

👉 NOTE: On launch, if a dynamic profile generator is enabled, it will always add new profiles it detects to your list of profiles. If you delete a dynamically generated profile from your list of profiles, it will just get re-added the next time the Terminal is launched! To remove a dynamic profile from your list of profiles, make sure to set "hidden": true in the profile.

Is black the new default? The regenerated settings.json does not contain any color schemes.

@tomm1e That's entirely intentional. We figured that every user didn't need to see a full copy of every default scheme in their settings file, so we moved them to defaults.json. You can still use the schemes in that file.

So upon a fresh install of Terminal the settings.json file contains a bunch of URL references. However, most of them lead nowhere useful. Can these changes be made for the sake of people actually trying these URLs since 1.0 is approaching? :)

| ref URL | leads to | should be |
| --- | --- | --- |
| https://aka.ms/terminal-documentation | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md |
| https://aka.ms/terminal-global-settings | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#global-settings |
| https://aka.ms/terminal-profile-settings | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles |
| https://aka.ms/terminal-color-schemes | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#color-schemes |
| https://aka.ms/terminal-keybindings | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#key-bindings |
| https://aka.ms/terminal-selection | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md#selecting-and-copying-text-in-windows-terminal |
| https://aka.ms/terminal-panes | https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md | ? |

Those links are _going_ to go somewhere useful Soon^TM. Please bear with us as we put the finishing touches on the actual docs 😉

@zadjii-msft Thanks for that update. Being a technical writer myself I always gets antsy when documentation seems to be forgotten. 😅

I noticed the blog article talks about using things like { "command": { "action": "copy", "singleLine": true ), "keys": "ctrl+alt+c" } to restore the single line copy functionality, but no indication on how to restore it to copy on select as it was previously done by copyFormatting. Is it possible to copy as single line but leave copyFormatting: false?

eg.

• Select text that breaks into multiline due to window size
• Paste with ctrl-shift-v
• It breaks into newlines

We should document this as IMO its not clear that copyFormatting affects single line paste and if possible, how to fix it.

copyFormatting doesn't impact single-line paste _or_ copy on select. copyOnSelect impacts copy on select.

Text that is broken into newlines due to window size is doing so because of a _bug_, and the solution isn't to set singleLine to true.

Do you have a specific repro that causes broken multiline text?

(There are three independent copy flags. copyOnSelect determines whether text is copied when you release the left mouse button, copyFormatting determines whether text is copied with color information and singleLine determines whether _all newlines are deleted, even if they were intentional_.)

@DHowett-MSFT I understand that to be the case regarding the different options, but it seems then there is a bug that affect that and its "fixed" by setting copyFormatting to true.

Repro for me is really simple for me and I can even dynamically toggle that and have it broken/fixed.

~
❯ echo this is a really long command that shouldnotbe breaking when copy paste
this is a really long command that shouldnotbe breaking when copy paste

~
❯ echo this is a really long command that shouldnotbe breakin

this is a really long command that shouldnotbe breakin

~
❯ g when copy paste
git: 'when' is not a git command. See 'git --help'.

The most similar commands are
        clean
        clone
        prune
        shell

~
❯

As you can see on that output, the line when pasted is split into multi line and ran as 2 commands.

• Type a really long line that breaks to multi-line in your console (or make a smaller console)
• Select text
• Paste as ctrl+shif+v or ctrl-v or right click or whatever is your paste

• It runs 2 commands

• Toggle copyFormatting to true

• Do the same
• Does not break

Please note im not copying with ctrl+c or ctrl+shift+c but with copy on select.

For reference, this is my relevant config:

{
  "$schema": "https://aka.ms/terminal-profiles-schema",
  "defaultProfile": "{01751d96-d6f8-573f-8029-e581f2f7c955}",
  "copyFormatting": false,
  "profiles": {
    "defaults": {
      "historySize": 9001,
      "fontFace": "Fira Code",
      "fontSize": 12,
      "useAcrylic": true,
      "acrylicOpacity": 0.85
    },
    "list": [
      ...
    ]
  },
  "schemes": [
    ...
  ],
  "keybindings": [
    {
      "command": {
        "action": "copy",
        "singleLine": true
      },
      "keys": "ctrl+c"
    },
    {
      "command": {
        "action": "adjustFontSize",
        "delta": -1
      },
      "keys": "ctrl+-"
    },
    {
      "command": {
        "action": "adjustFontSize",
        "delta": 1
      },
      "keys": "ctrl+="
    }
  ]
}

Ok, oddly enough while I just did this while creating this comment and it caused the output I pasted (broken line) and it happened multiple times since the update. I just ran it once again after, just to check other cases and it worked correctly, which has me really confused now.

Any reason why we haven't gotten a GUI for changing settings yet?

@ScribbleNerd because that will take months of work that we couldn't complete until we nailed the basics of actually being a terminal? That work is being tracked in #1564.

yeah not meaning to sound condescending but its a cli tool for cli competent people, so it makes far more sense to work on the core functionality and cli user features rather than trying to make it easy point and click to make pretty - at least until all the main things are done, upvote for html link handler haha

I only changed the default profile to cmd.exe in last version. then today after update it showing me global deprecated error over and over again.

How about automatically converting the file if older format is detected: seeing the format changes it appears to be possible.

Seeing how full of comments is this issue I think this could solve problems for a lot of people.

Got to say, I found this extremely jarring for a product that that is at GA status.
Auto-migrating such things seems a pretty bare minimum for a breaking change release.

is at GA status

Only people who were using the Preview build will encounter breaking changes. The preview build was offered with no warranties (express or implied.)

I’m sorry it was jarring. Settings migration is planned for any updates to the stable channel that require settings model changes.