Add support for roaming settings.json or storing it elsewhere #4101

@patriksvensson commented on GitHub (Sep 30, 2019):

@zadjii-msft Would it help if I (or someone else) drafted up a spec to get the ball rolling?

@patriksvensson commented on GitHub (Sep 30, 2019): @zadjii-msft Would it help if I (or someone else) drafted up a spec to get the ball rolling?

claunia commented

@zadjii-msft commented on GitHub (Sep 30, 2019):

I think that would be very helpful :)

@zadjii-msft commented on GitHub (Sep 30, 2019): I think that would be _very_ helpful :)

claunia commented

@jpetkau commented on GitHub (Nov 11, 2019):

As a workaround for this, it's possible to make profiles.json a symlink to a shared settings file in Roaming or OneDrive or Dropbox or whatever.

This mostly works, except terminal doesn't notice changes to the actual file. It only watches the symlink. So hot-reloading of changes doesn't work.

Of course roaming just magically working would be better.

@jpetkau commented on GitHub (Nov 11, 2019): As a workaround for this, it's possible to make `profiles.json` a symlink to a shared settings file in Roaming or OneDrive or Dropbox or whatever. This mostly works, except terminal doesn't notice changes to the actual file. It only watches the symlink. So hot-reloading of changes doesn't work. Of course roaming just magically working would be better.

claunia commented

@chwarr commented on GitHub (Mar 9, 2020):

There's a related issue in this space, #4566 "Consider adding a WT_PROFILE env var pointing to settings file for 1.0 release".

It proposes setting the environment variable WT_PROFILE to the path of the user's settings file. Copying a comment that I made on that here:

My expectation of a variable like WT_PROFILE would be that I could [also] use it to change where Windows Terminal reads user settings from. ...

Based on how other, similar software works, I think it would make sense if Windows Terminal only read this environment variable at process start up and then monitored the path for changes. It would also be reasonable for Windows Terminal to detect changes to the environment "template" by handling WM_SETTINGCHANGE notifications. (Though, there are some subtle details to consider about when changes are applied. Lots of thoughts in #1125, "Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates".)

@chwarr commented on GitHub (Mar 9, 2020): There's a related issue in this space, #4566 "Consider adding a WT_PROFILE env var pointing to settings file for 1.0 release". It proposes setting the environment variable `WT_PROFILE` to the path of the user's settings file. Copying a comment that I made on that here: > My expectation of a variable like `WT_PROFILE` would be that I could \[also\] use it to change where Windows Terminal reads user settings from. ... > > Based on how other, similar software works, I think it would make sense if Windows Terminal only read this environment variable at process start up and then monitored the path for changes. It would also be reasonable for Windows Terminal to detect changes to the environment "template" by handling [`WM_SETTINGCHANGE`](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-settingchange) notifications. (Though, there are some subtle details to consider about when changes are applied. Lots of thoughts in #1125, "Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates".)

claunia commented

@patriksvensson commented on GitHub (Mar 9, 2020):

If anyone is interested in an interim solution to this, I've written some instructions here: https://www.patriksvensson.se/2019/12/roaming-profiles-with-windows-terminal

@patriksvensson commented on GitHub (Mar 9, 2020): If anyone is interested in an interim solution to this, I've written some instructions here: https://www.patriksvensson.se/2019/12/roaming-profiles-with-windows-terminal

claunia commented

@DavidGamba commented on GitHub (Apr 27, 2020):

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

@DavidGamba commented on GitHub (Apr 27, 2020): If the file watcher that monitors `profiles.json` can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

claunia commented

@DavidGamba commented on GitHub (Apr 27, 2020):

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

@DavidGamba commented on GitHub (Apr 27, 2020): If the file watcher that monitors `profiles.json` can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

claunia commented

@zadjii-msft commented on GitHub (Apr 29, 2020):

From @MartinSGill in #5638

Proposed technical implementation details (optional)

The common linux practice of using a settings.d style folder and loading all files in that folder seems like a good approach to me.
* Settings.json defines an "include" directory (environment variables permitted)

* Settings loads all files in that folder in alphabetical order.

* Settings adds/overrides settings based on loaded files.

* Additional files would all have the same structure/schema as the default settings.json

* [Extra Credit] Support multiple folders, allow shared/user settings.

@zadjii-msft commented on GitHub (Apr 29, 2020): From @MartinSGill in #5638 > # Proposed technical implementation details (optional) > > The common linux practice of using a `settings.d` style folder and loading all files in that folder seems like a good approach to me. > > * Settings.json defines an "include" directory (environment variables permitted) > > * Settings loads all files in that folder in alphabetical order. > > * Settings adds/overrides settings based on loaded files. > > * Additional files would all have the same structure/schema as the default settings.json > > * [Extra Credit] Support multiple folders, allow shared/user settings.

claunia commented

@MartinSGill commented on GitHub (May 3, 2020):

Advantages I see for my proposed implementation:

it would support tools such as chef/ansible to install "features".
It would also allow sharing of themes/keyboard-maps etc without upsetting the current settings. Add the file you want to try out to load last, try it out, if you don't like it, just delete the file.
It would allow you to make profiles portable (e.g. CloudDrive/Dropbox)

@MartinSGill commented on GitHub (May 3, 2020): Advantages I see for my proposed implementation: - it would support tools such as chef/ansible to install "features". - It would also allow sharing of themes/keyboard-maps etc without upsetting the current settings. Add the file you want to try out to load last, try it out, if you don't like it, just delete the file. - It would allow you to make profiles portable (e.g. CloudDrive/Dropbox)

claunia commented

@scottwillmoore commented on GitHub (Dec 5, 2020):

As a non-ideal workaround for any that want to sync settings.json into their dotfiles while preserving the ability to hot reload, you can a hard link instead of a symbolic link. The file will remain synchronised with your dotfiles and a hard link will still trigger the filesystem events required to trigger a hot reload provided that you edit settings.json from the original path (just press Ctrl+, in the terminal).

An alternative approach that I have read somewhere else (but cannot remember where...) is to create a junction or symlink for the LocalState folder (the folder that contains settings.json) and I believe this will detect and trigger a hot reload in all cases.

@scottwillmoore commented on GitHub (Dec 5, 2020): As a *non-ideal* workaround for any that want to sync `settings.json` into their dotfiles while preserving the ability to hot reload, you can a [hard link](https://stackoverflow.com/questions/9042542/what-is-the-difference-between-ntfs-junction-points-and-symbolic-links/48586946#48586946) instead of a symbolic link. The file will remain synchronised with your dotfiles and a hard link will still trigger the filesystem events required to trigger a hot reload provided that you edit `settings.json` from the original path (just press `Ctrl+,` in the terminal). An alternative approach that I have read somewhere else (but cannot remember where...) is to create a junction or symlink for the `LocalState` folder (the folder that contains `settings.json`) and I believe this will detect and trigger a hot reload in all cases.

claunia commented

@patricknelson commented on GitHub (Dec 14, 2020):

An alternative approach that I have read somewhere else (but cannot remember where...) is to create a junction or symlink for the LocalState folder (the folder that contains settings.json) and I believe this will detect and trigger a hot reload in all cases.

I use Link Shell Extension for this. Also, I just tried your recommendation (dropping LocalState folder as a symbolic link) and it worked for me! Initially it didn't work since I only symlinked the settings.json. Now I can save it in Google Drive, edit it from either location and it'll update live.

@patricknelson commented on GitHub (Dec 14, 2020): > An alternative approach that I have read somewhere else (but cannot remember where...) is to create a junction or symlink for the `LocalState` folder (the folder that contains `settings.json`) and I believe this will detect and trigger a hot reload in all cases. I use [Link Shell Extension](https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html) for this. Also, I just tried your recommendation (dropping `LocalState` folder as a symbolic link) and it worked for me! Initially it didn't work since I only symlinked the `settings.json`. Now I can save it in Google Drive, edit it from either location and it'll update live.

claunia commented

2026-01-30 23:38:08 +00:00

@Firehawke commented on GitHub (Dec 16, 2020):

I'll second Link Shell Extension. It's a really useful tool for a lot of different purposes. I don't want to get too far off topic, but I'll just briefly add that I used junctions via LSE to have Steam stuff on a non-C drive before Steam supported multi-drive libraries. I still use a lot of junctions to keep large parts of my system config on private cloud storage.

@Firehawke commented on GitHub (Dec 16, 2020): I'll second Link Shell Extension. It's a really useful tool for a lot of different purposes. I don't want to get too far off topic, but I'll just briefly add that I used junctions via LSE to have Steam stuff on a non-C drive before Steam supported multi-drive libraries. I still use a lot of junctions to keep large parts of my system config on private cloud storage.

claunia commented

@bavis-m commented on GitHub (Jan 16, 2021):

It appears like a Junction point to LocalState allows settings.json to dynamically update, but not a symlink (either to LocalState or settings.json). Can anyone else confirm these behaviour? A couple of replies here seem to suggest a symlink will work (which I would like, since I can't put a junction to my config repo which I usually have checked out in WSL).

@bavis-m commented on GitHub (Jan 16, 2021): It appears like a Junction point to LocalState allows settings.json to dynamically update, but not a symlink (either to LocalState or settings.json). Can anyone else confirm these behaviour? A couple of replies here seem to suggest a symlink will work (which I would like, since I can't put a junction to my config repo which I usually have checked out in WSL).

claunia commented

2026-01-30 23:38:08 +00:00

@razamatan commented on GitHub (Feb 5, 2021):

so i'm here b/c i just switched to wsl2, and i have a setup where my dotfiles are for linux and replicated by git. therefore, my dotfiles live in wsl. under wsl1, since the wsl rootfs was readily accessible via windows, i had my %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json linked to the file in wsl (dir output: <SYMLINK> settings.json [\\wsl$\Ubuntu\home\razamatan\.dotfiles\settings.json]).

since wsl2 switched to vhd's, if i try to open terminal w/o starting wsl to load the vhd, i get the "Encountered errors while loading user settings" error dialog. i have to remember to always start wsl to allow wt to be able to read from that symlink.

it would be great to load wsl if trying to access any symlink that points to wsl paths. don't know if this belongs to wsl (https://github.com/microsoft/WSL/issues/6524) or wt as an issue, but posting here just in case.

*edit: just tried making settings.json a junctioned symlink, but that never works, even w/ wsl loaded...

@razamatan commented on GitHub (Feb 5, 2021): so i'm here b/c i just switched to wsl2, and i have a setup where my dotfiles are for linux and replicated by git. therefore, my dotfiles live in wsl. under wsl1, since the wsl rootfs was readily accessible via windows, i had my `%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json` linked to the file in wsl (dir output: `<SYMLINK> settings.json [\\wsl$\Ubuntu\home\razamatan\.dotfiles\settings.json]`). since wsl2 switched to vhd's, if i try to open terminal w/o starting wsl to load the vhd, i get the "Encountered errors while loading user settings" error dialog. i have to remember to always start wsl to allow wt to be able to read from that symlink. it would be great to load wsl if trying to access any symlink that points to wsl paths. don't know if this belongs to wsl (https://github.com/microsoft/WSL/issues/6524) or wt as an issue, but posting here just in case. *edit: just tried making settings.json a junctioned symlink, but that never works, even w/ wsl loaded...

claunia commented

2026-01-30 23:38:08 +00:00

@ghost commented on GitHub (Mar 12, 2021):

Add Cloud sync support with our Microsoft account.

@ghost commented on GitHub (Mar 12, 2021): Add Cloud sync support with our Microsoft account.

claunia commented

@thernstig commented on GitHub (Apr 6, 2021):

If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have User settings as well as Machine settings (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different Authentication providers that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account.

Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc.

@thernstig commented on GitHub (Apr 6, 2021): If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have _User settings_ as well as _Machine settings_ (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different _Authentication providers_ that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account. Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc.

claunia commented

@Falven commented on GitHub (May 20, 2021):

If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have User settings as well as Machine settings (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different Authentication providers that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account.

Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc.

Any ideas if this is being implemented? I see the thread being closed and reopened multiple times but no work item linked or anything.

@Falven commented on GitHub (May 20, 2021): > If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have _User settings_ as well as _Machine settings_ (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different _Authentication providers_ that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account. > > Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc. Any ideas if this is being implemented? I see the thread being closed and reopened multiple times but no work item linked or anything.

claunia commented

@zadjii-msft commented on GitHub (May 20, 2021):

I see the thread being closed and reopened multiple times but no work item linked or anything.

???

This thread has remained open since it was first filed. Maybe you posted on the wrong thread?

We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The original roaming settings were a pain, but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon.

@zadjii-msft commented on GitHub (May 20, 2021): > I see the thread being closed and reopened multiple times but no work item linked or anything. ??? This thread has remained open since it was first filed. Maybe you posted on the wrong thread? We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The [original roaming settings were a pain](https://github.com/microsoft/terminal/issues/2933#issuecomment-536652883), but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon.

claunia commented

@Falven commented on GitHub (May 20, 2021):

We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The original roaming settings were a pain, but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon.

Why not? It could be developed with community support. The source code to do this is already available in the VS Code repository, it is production-tested, and it includes tests...
As an aside I would hope that at a minimum WT should have extensibility as a major milestone in the roadmap to allow people to develop plugins such as this.

@Falven commented on GitHub (May 20, 2021): > We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The [original roaming settings were a pain](https://github.com/microsoft/terminal/issues/2933#issuecomment-536652883), but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon. Why not? It could be developed with community support. The source code to do this is already available in the [VS Code repository](https://github.com/microsoft/vscode), it is production-tested, and it includes tests... As an aside I would hope that at a minimum WT should have extensibility as a major milestone in the roadmap to allow people to develop plugins such as this.

claunia commented

@zadjii-msft commented on GitHub (May 20, 2021):

I would LOVE to have community help implementing this!

Just because we don't have time on the schedule to design/implement a feature ourselves, doesn't mean we aren't willing to help the community with such a feature. I just don't want to commit to anything, if we haven't explicitly allocated engineers to finishing it ☺️.

<aside>
Yep, extensions is totally something we've been working on. #4000 is tracking that. That's probably the big 3.0 milestone feature. We still need to get some OS support worked out to help us - it's a little bit trickier to load actual native code extensions rather than just blobs of javascript 😆

@zadjii-msft commented on GitHub (May 20, 2021): ### I would LOVE to have community help implementing this! Just because _we_ don't have time on the schedule to design/implement a feature ourselves, doesn't mean we aren't willing to help the community with such a feature. I just don't want to commit to anything, if we haven't explicitly allocated engineers to finishing it ☺️. \<aside> Yep, extensions is totally something we've been working on. #4000 is tracking that. That's probably the big 3.0 milestone feature. We still need to get some OS support worked out to help us - it's a little bit trickier to load actual native code extensions rather than just blobs of javascript 😆

claunia commented

@awakecoding commented on GitHub (Oct 12, 2021):

I'm taking a chance here to suggest exactly what I intend to patch on my own builds to fit my needs: modify GetBaseSettingsPath to check for an environment variable "WT_BASE_SETTINGS_PATH" and use it if it's present instead of the default path. I really don't need anything more than that, as I would just launch Windows Terminal with different environment variables to make it point to different directories with injected settings.

Is there any chance that such a small change could be considered? I don't care about the environment variable name, just that we can use an environment variable (or command-line parameter) to override the base settings path.

@awakecoding commented on GitHub (Oct 12, 2021): I'm taking a chance here to suggest exactly what I intend to patch on my own builds to fit my needs: modify GetBaseSettingsPath to check for an environment variable "WT_BASE_SETTINGS_PATH" and use it if it's present instead of the default path. I really don't need anything more than that, as I would just launch Windows Terminal with different environment variables to make it point to different directories with injected settings. ![image](https://user-images.githubusercontent.com/295841/136984446-24106e8f-4ba6-4273-8152-176753b6d3a3.png) Is there any chance that such a small change could be considered? I don't care about the environment variable name, just that we can use an environment variable (or command-line parameter) to override the base settings path.

claunia commented

@DHowett commented on GitHub (Oct 12, 2021):

I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at https://github.com/microsoft/terminal/issues/6687#issuecomment-650382579 😄

@DHowett commented on GitHub (Oct 12, 2021): I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at https://github.com/microsoft/terminal/issues/6687#issuecomment-650382579 :smile:

claunia commented

@awakecoding commented on GitHub (Oct 12, 2021):

I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at #6687 (comment) 😄

This looks good to me, is there a branch with a prototype for the suggested change? Also, while settings.json is the primary file used by Windows Terminal, would it better to override the directory containing settings.json rather than the full path to settings.json, such that if Windows Terminal decides to store more files in the future, we wouldn't need to modify it again to override additional paths? Overriding the base path containing all files appears to be the safest option long term.

@awakecoding commented on GitHub (Oct 12, 2021): > I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at [#6687 (comment)](https://github.com/microsoft/terminal/issues/6687#issuecomment-650382579) 😄 This looks good to me, is there a branch with a prototype for the suggested change? Also, while settings.json is the primary file used by Windows Terminal, would it better to override the directory containing settings.json rather than the full path to settings.json, such that if Windows Terminal decides to store more files in the future, we wouldn't need to modify it again to override additional paths? Overriding the base path containing all files appears to be the safest option long term.

claunia commented

@patricknelson commented on GitHub (Oct 19, 2021):

Thanks for calling that out @DHowett

Hmm… since some of us want to synchronize profiles and others want the ability to parameterize via CLI which profile to use, have we considered separating this into two components? i.e.

Directory to load profiles from
The actual JSON file to load (must be a file, not a path and cannot be relative)

I say this since it might help to abstract away our concerns of allowing it to be roaming whilst also facilitating parametrized variability without being too tightly bound to the actual path. For example, both wt -c profile1.json and wt -c profile2.json would still work and are separate from where we decide to put them. This also suggests of course that, if the directory itself isn’t provided as a parameter as well (or some kind of env var, cringe I know) that you’ll have to devise a sane default. Presumably it’d still be in the current directory where this file is already stored and/or also configurable at some higher global level, wherever that may be.

I’m just trying to offer a concept that might help reconcile these two features amicably without it getting too complicated later on. 🤞

@patricknelson commented on GitHub (Oct 19, 2021): Thanks for calling that out @DHowett Hmm… since some of us want to _synchronize_ profiles and others want the ability to parameterize via CLI _which_ profile to use, have we considered separating this into two components? i.e. 1. Directory to load profiles from 2. The actual JSON file to load (must be a file, not a path and cannot be relative) I say this since it might help to abstract away our concerns of allowing it to be roaming whilst also facilitating parametrized variability without being too tightly bound to the actual path. For example, both `wt -c profile1.json` and `wt -c profile2.json` would still work and are separate from where we decide to put them. This also suggests of course that, if the directory itself isn’t provided as a parameter as well (or some kind of env var, cringe I know) that you’ll have to devise a sane default. Presumably it’d still be in the current directory where this file is already stored and/or also configurable at some higher global level, wherever that may be. I’m just trying to offer a concept that might help reconcile these two features amicably without it getting _too_ complicated later on. 🤞

claunia commented

@DanielLaberge commented on GitHub (Feb 9, 2022):

Please consider making this issue higher priority, or #6687, whichever is easier to implement.

I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age.

The amount of comments and duplicated issues in this and #6687 should be a good indication of the interest.

@DanielLaberge commented on GitHub (Feb 9, 2022): Please consider making this issue higher priority, or #6687, whichever is easier to implement. I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age. The amount of comments and duplicated issues in this and #6687 should be a good indication of the interest.

claunia commented

@thernstig commented on GitHub (Feb 10, 2022):

Take inspiration from VS Code, the same way you took inspiration for the command pane from VS Code. They have authentication providers that can be used to sync settings. With logs, conflict resolution etc. etc. They spent a good chunk of UX on this already so I believe there is much to gain to just look at their solution UX-wise.

@thernstig commented on GitHub (Feb 10, 2022): Take inspiration from VS Code, the same way you took inspiration for the command pane from VS Code. They have authentication providers that can be used to sync settings. With logs, conflict resolution etc. etc. They spent a good chunk of UX on this already so I believe there is much to gain to just look at their solution UX-wise.

claunia commented

@stevenvolckaert commented on GitHub (May 5, 2022):

What is the status on this feature request?

Is it possible somehow to roam the settings across several computers at the moment, and if so, what's the most recommended way to do it?

Is the symbolic link workaround mentioned here still the way to go?

Thank you very much for your insights!

@stevenvolckaert commented on GitHub (May 5, 2022): What is the status on this feature request? Is it possible somehow to roam the settings across several computers at the moment, and if so, what's the most recommended way to do it? Is the symbolic link workaround mentioned [here](https://github.com/microsoft/terminal/issues/2933#issuecomment-552544098) still the way to go? Thank you very much for your insights!

claunia commented

@hapylestat commented on GitHub (May 21, 2022):

@jpetkau the whole purpose of roaming settings.json, to make it auto-pickable on another systems and not bother with reconfiguring each system manually. I have like 3-4 systems and it is a headache to make same changes x4 times

@hapylestat commented on GitHub (May 21, 2022): @jpetkau the whole purpose of roaming settings.json, to make it auto-pickable on another systems and not bother with reconfiguring each system manually. I have like 3-4 systems and it is a headache to make same changes x4 times

claunia commented

@hapylestat commented on GitHub (May 21, 2022):

@thernstig UX wise it's really easy, if you use MS enabled account and OneDrive, just use "Documents" folder or whatever to keep the settings, as those folders already are used in a way, that it auto-synced via OneDrive.

In my case, I'm keeping oh-my-posh in an OneDrive, and when I'm opening the terminal on another PC/VM - it automatically download everything and setting up it for me. (thanks for Powershell able to autoload user profiles)

@hapylestat commented on GitHub (May 21, 2022): @thernstig UX wise it's really easy, if you use MS enabled account and OneDrive, just use "Documents" folder or whatever to keep the settings, as those folders already are used in a way, that it auto-synced via OneDrive. In my case, I'm keeping `oh-my-posh` in an OneDrive, and when I'm opening the terminal on another PC/VM - it automatically download everything and setting up it for me. (thanks for Powershell able to autoload user profiles)

claunia commented

@4wk- commented on GitHub (Jan 4, 2023):

Hello. Sorry for "thread bumping" this issue but it's been some time since the last update, same in #6687.

Like a lot of users, I came here to see if there was a way to just store the settings.json file elsewhere, so it can be synced and backed-up by Dropbox/Onedrive/Drive (or even backup manually to a hard drive for instance).

The only workaround we might have is using a windows `hardlink as described here

@4wk- commented on GitHub (Jan 4, 2023): Hello. Sorry for "thread bumping" this issue but it's been some time since the last update, same in #6687. Like a lot of users, I came here to see if there was a way to just store the `settings.json` file elsewhere, so it can be synced and backed-up by Dropbox/Onedrive/Drive (or even backup manually to a hard drive for instance). The only workaround we might have is using a windows `hardlink as [described here](https://superuser.com/a/1761046/146357)

claunia commented

@zadjii-msft commented on GitHub (Jan 4, 2023):

Nope, no real updates to share at this time. I had half a thought about it that I edited into a comment above, just trying to enumerate the edge cases, but didn't get farther than that.

@zadjii-msft commented on GitHub (Jan 4, 2023): Nope, no real updates to share at this time. I had half a thought about it that I edited into a comment above, just trying to enumerate the edge cases, but didn't get farther than that.

claunia commented

@ghost commented on GitHub (Jan 4, 2023):

Hello. Sorry for "thread bumping" this issue but it's been some time since the last update, same in #6687.

Like a lot of users, I came here to see if there was a way to just store the settings.json file elsewhere, so it can be synced and backed-up by Dropbox/Onedrive/Drive (or even backup manually to a hard drive for instance).

The only workaround we might have is using a windows `hardlink as described here: https://superuser.com/questions/1667853/how-to-change-the-location-of-settings-json-file-in-windows-terminal

referring to the Superuser question, that's not where my Windows Terminal's settings file is located, it's here

C:\Users\UserName\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState

and I can easily use PowerShell to automate the process of copying my personalized settings file from my OneDrive to that location after every time I clean install Windows.

PowerShell is like the God of automation lol

@ghost commented on GitHub (Jan 4, 2023): > > Hello. Sorry for "thread bumping" this issue but it's been some time since the last update, same in #6687. > > Like a lot of users, I came here to see if there was a way to just store the `settings.json` file elsewhere, so it can be synced and backed-up by Dropbox/Onedrive/Drive (or even backup manually to a hard drive for instance). > > The only workaround we might have is using a windows `hardlink as described here: https://superuser.com/questions/1667853/how-to-change-the-location-of-settings-json-file-in-windows-terminal referring to the Superuser question, that's not where my Windows Terminal's settings file is located, it's here `C:\Users\UserName\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState` and I can easily use PowerShell to automate the process of copying my personalized settings file from my OneDrive to that location after every time I clean install Windows. PowerShell is like the God of automation lol

claunia commented

@4wk- commented on GitHub (Jan 4, 2023):

@lulMeow My json file is located like yours. I've commented SO for the sake of it. Actually, I've add another answer with more details.
Yes, PowerShell can do a lot, but storing the file elsewhere would allow us to set it once and forgot about it, and still being always synced.

@4wk- commented on GitHub (Jan 4, 2023): @lulMeow My json file is located like yours. I've commented SO for the sake of it. Actually, [I've add another answer with more details.](https://superuser.com/a/1761046/146357) Yes, PowerShell can do a lot, but storing the file elsewhere would allow us to set it once and forgot about it, and still being always synced.

claunia commented

@RollsChris commented on GitHub (Sep 8, 2023):

hey, bump, i cant really see why this is an issue to implement?

@RollsChris commented on GitHub (Sep 8, 2023): hey, bump, i cant really see why this is an issue to implement?

claunia commented

@et304383 commented on GitHub (Oct 2, 2023):

In 2023 (nearly 2024), having to copy a settings file manually from one machine to the other should NOT be a thing.

Considering this and VSCode are the two core dev tools from Microsoft, this task should be higher priority. We should have settings sync in the cloud just like VSCode.

@et304383 commented on GitHub (Oct 2, 2023): In 2023 (nearly 2024), having to copy a settings file manually from one machine to the other should NOT be a thing. Considering this and VSCode are the two core dev tools from Microsoft, this task should be higher priority. We should have settings sync in the cloud just like VSCode.

claunia commented

@RollsChris commented on GitHub (Oct 28, 2023):

I really like how PowerShell do their profile, you can source another file in "Their profile file".

So I do this at the top of my profile:

. "$env:GITHUB_REPOS_PATH\machine\powershell\Microsoft.PowerShell_profile.ps1";

Me casa su casa 😎

@RollsChris commented on GitHub (Oct 28, 2023): I really like how PowerShell do their profile, you can source another file in "Their profile file". So I do this at the top of my profile: ```powershell . "$env:GITHUB_REPOS_PATH\machine\powershell\Microsoft.PowerShell_profile.ps1"; ``` Me casa su casa 😎

claunia commented

@huenrong commented on GitHub (Mar 2, 2024):

Hi, Is it possible to add an option to each configuration file to choose whether to synchronize the configuration file?

@huenrong commented on GitHub (Mar 2, 2024): Hi, Is it possible to add an option to each configuration file to choose whether to synchronize the configuration file?

claunia commented

https://github.com/microsoft/terminal/issues/17277#issue-2300424002

@carlos-zamora commented on GitHub (Jul 3, 2024):

Dupping a few issues to this one:

#17277

Description of the new feature/enhancement

I use many different machines on a daily basis, for example my work laptop, my development laptop, my testing laptop, my private laptop, my private Tower etc.

On each Device I need to import the full Config of Windows Terminal. A way to synchronise all the Terminal Config files would be insanely great and would really hype up this terminal soo much more!!!

PowerToys already has a Backup option, could similar thing be done for windows-terminal?
I'd even consider github integration a nice idea, as this would allow for easy fetching from a raw.githubusercontent link.
(I wouldn't mind the config being public).

Also something like fully remote fetching would be nice, for example the machine fetches the config from remote github repository and on no internet it fallbacks to a cached version.

Proposed technical implementation details (optional)

The Github Integration to the initial Backup + Restore would be like a nice-to-have addon to keep in mine, but could also be done through scripts.

Add a way to Backup and restore the Config
- Backup to a specfic Path
- Restore from Path
Github Integration would be nice-to-have
- User can enter a URL to a github file, where config is fetched from.
- User can connect windows terminal to github account, select a repo and the accoring file, where windows terminal pushes changes to.

#17513

https://github.com/microsoft/terminal/issues/17513#issue-2389401309

Description of the new feature/enhancement

It would be ideal to back up Terminal settings to a different folder (for example, C:\Users\username\OneDrive\Documents\Terminal). Every time that we want to back up Terminal settings, we have to navigate to the folder like %LocalAppData%\packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState and copy and paste the settings.json file to another folder. Also, every time that we want to restore Terminal settings, we have to navigate the settings.json file to a folder and copy and paste it to %LocalAppData%\packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState.

Proposed technical implementation details (optional)

Add Backup and Restore buttons in the Terminal settings.

@carlos-zamora commented on GitHub (Jul 3, 2024): Dupping a few issues to this one: ## #17277 https://github.com/microsoft/terminal/issues/17277#issue-2300424002 ### Description of the new feature/enhancement I use many different machines on a daily basis, for example my work laptop, my development laptop, my testing laptop, my private laptop, my private Tower etc. On each Device I need to import the full Config of Windows Terminal. A way to synchronise all the Terminal Config files would be insanely great and would really hype up this terminal soo much more!!! PowerToys already has a Backup option, could similar thing be done for windows-terminal? I'd even consider github integration a nice idea, as this would allow for easy fetching from a raw.githubusercontent link. (I wouldn't mind the config being public). Also something like fully remote fetching would be nice, for example the machine fetches the config from remote github repository and on no internet it fallbacks to a cached version. ### Proposed technical implementation details (optional) The Github Integration to the initial Backup + Restore would be like a nice-to-have addon to keep in mine, but could also be done through scripts. - Add a way to Backup and restore the Config - Backup to a specfic Path - Restore from Path - Github Integration would be nice-to-have - User can enter a URL to a github file, where config is fetched from. - User can connect windows terminal to github account, select a repo and the accoring file, where windows terminal pushes changes to. ## #17513 https://github.com/microsoft/terminal/issues/17513#issue-2389401309 ### Description of the new feature/enhancement It would be ideal to back up Terminal settings to a different folder (for example, C:\Users\username\OneDrive\Documents\Terminal). Every time that we want to back up Terminal settings, we have to navigate to the folder like %LocalAppData%\packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState and copy and paste the settings.json file to another folder. Also, every time that we want to restore Terminal settings, we have to navigate the settings.json file to a folder and copy and paste it to %LocalAppData%\packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState. # Proposed technical implementation details (optional) Add Backup and Restore buttons in the Terminal settings.

claunia commented

@wolf99 commented on GitHub (Jul 4, 2024):

Small word of caution; if the synchronisation is via git repo, then there should also be some way to abstract secrets, such as usernames on paths, SSH creds, etc.

@wolf99 commented on GitHub (Jul 4, 2024): Small word of caution; if the synchronisation is via git repo, then there should also be some way to abstract secrets, such as usernames on paths, SSH creds, etc.

claunia commented

@TomLewis commented on GitHub (Jul 24, 2024):

This should be a higher priority, why can this not sync with a windows account, its a widows product.

@TomLewis commented on GitHub (Jul 24, 2024): This should be a higher priority, why can this not sync with a windows account, its a widows product.

claunia commented

@awakecoding commented on GitHub (Jul 24, 2024):

FYI - we went for a simple patch in our Windows Terminal distribution that accepts the WT_BASE_SETTINGS_PATH environment variable to override where WT stores its settings, and we've been using it for the past two years without issue. I haven't submitted a pull request for the simple reason that there doesn't seem to be consensus on how this should be fixed upstream, but for our needs, we needed a way to create isolated, injectable configurations to launch WT from Remote Desktop Manager, and an environment variable worked well.

@awakecoding commented on GitHub (Jul 24, 2024): FYI - we went for [a simple patch](https://github.com/Devolutions/wt-distro/blob/master/patches/add-wt-base-settings-path-env-var.patch) in our [Windows Terminal distribution](https://github.com/Devolutions/wt-distro) that accepts the WT_BASE_SETTINGS_PATH environment variable to override where WT stores its settings, and we've been using it for the past two years without issue. I haven't submitted a pull request for the simple reason that there doesn't seem to be consensus on how this should be fixed upstream, but for our needs, we needed a way to create isolated, injectable configurations to launch WT from Remote Desktop Manager, and an environment variable worked well.

claunia commented

@mu88 commented on GitHub (Aug 1, 2024):

@carlos-zamora / @zadjii-msft is there any news about that?

@mu88 commented on GitHub (Aug 1, 2024): @carlos-zamora / @zadjii-msft is there any news about that?

claunia commented

@abelfubu commented on GitHub (Jan 2, 2025):

🎄 Adding this feature would help me fulfill one of my New Year’s resolutions.

@abelfubu commented on GitHub (Jan 2, 2025): 🎄 Adding this feature would help me fulfill one of my New Year’s resolutions.

claunia commented