Add support for roaming settings.json or storing it elsewhere

[patriksvensson]

---

Note: 📌 Pinned comment: #2933 (comment)

---

Description of the new feature/enhancement

I have three different computers that I use for work. I keep my PowerShell profile in a GitHub repository and dot source it in my local PowerShell profile. That way I will only need to do a git pull on my profile repository to get all changes propagated on each computer.

It would be great if I could do something similar with my Windows Terminal settings by simply stating in my local settings.json file that the "real" settings could be found somewhere else.

(It could even be that the loaded profile acts like a base for the settings on the computer so things could be overridden, but that is a completely different issue that remains to be opened)

I'm aware that I might have overlooked something here, but would love to start a discussion about this since I suspect that I'm not the only one with this "problem".

Proposed technical implementation details (optional)

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "globals": {
        "loadProfileFrom": "C:/Source/git/profiles/terminal_profile.json"
    }

[brandonh-msft]

any reason we can't just use the UWP Roaming data store?
https://docs.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data#roaming-data

I know this isn't a true UWP app, but Centennials can still use the UWP APIs, right?

[DHowett-MSFT]

We actually used to roam your settings using those exact APIs, but it caused us way more headache than it was worth. There’s a couple things we need to nail before we consider turning roaming back on.

[brandonh-msft]

yeah was just coming back to edit.

looks like per here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance
and here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

we can't simply use RoamingFolder as I'd hoped? In lieu of this, then, @patriksvensson's approach is probably the best we'll get and users - well I, for one - could simply point at a OneDrive (or similar) location.

[zadjii-msft]

I'm more using this issue as a tracker for "add a way to import settings from other paths" than a "re-enable settings roaming". Using RoamingState for storing the settings was a pain. However, I think that we all agree adding support for importing settings from another location is a good idea, but one that needs careful thought and preferably a spec to go with it.

This is even a scenario referenced in the original cascading settings spec, as something we could consider in the future.

#1770 was the original bug tracking disabling roaming settings. Note the pile of other issues that were dupe'd to it.

---

April 15, 2022 edit:

I'm sneaking in here to add some notes about what re-enabling this again might look like. I'm reusing this old comment to avoid pinging folks till I have a plan.

What went wrong the first time

Plan for this time

• When we load the settings, look first in roamingstate, then fall back to localstate.
• Write the settings back out to roaming state.
• Should state.json's get written to roaming? Quite surely not.
  • ⚠️ if they've deleted a WSL profile from their settings, then the file gets roamed, and that distro is on the new machine (where there's not yet a state.json), the profile will come back to their settings file. It'll also then get roamed BACK to the machine that had originally deleted it.
• If we load from roaming, and see that there's a dynamic profile in there that we don't have locally, prompt the user to install it.
  • How does this combine with the "whoops we couldn't find your default profile" warning?
  • Make it an infobar maybe?
  • Can we easily just winget install {pwsh}, winget install {pwsh preview} in a new tab? that would be crisp
• What do we do about fragments?
• What how do we deal with symlinks? Do we need to do anything?
  • I suppose, if a user today has their localstate symlinked elsewhere, then they want the file to live elsewhere. They want it written to the elsewhere.
  • ⚠️ If we add a new symlink to the roamingstate folder, will it roam the contents of the link target to the roamingstate on a new machine?
  • If they add a symlink in roaming state, that'll probably get blown away if the settings roam back, yea?
    • It's probably okay to let them just symlink in LocalState though, and that'll prevent us from loading the roamed file.
  • Is just not roaming settings for folks with a symlink a reasonable UX? "I've taken things into my own hands"
• more....

Other things to keep in mind

• "Store settings elsewhere" - like, load additional files into the settings. IIRC my original imagination for this was something like "include": [ "{path-to-file.json}" ] as a global setting that would load cascade additional paths.
  • This was originally Feature Request - use a directory for profiles #2303, but we thought fragments sufficiently addressed that. It might not have.
  • Surely, the paths for additionally included settings files won't work on the machine they were roamed to. May be okay to silently ignore those failures though.
• Consider adding a WT_PROFILE env var pointing to settings file #4566
  • in general I hate this. Loading settings based on the value of an env var that's set seems fragile or prone to not working as expected, esp. given the number of issues we've had with env vars in the past.
• Command line argument to start up using a specified configuration file #6687
  • Much less fragile than the above, but still comes with issues. We'd have to make sure that the window that's started with those settings then only writes back to that file?
• Are there other roaming types that we might want to deal with? If the user has multiple MSA's logged in, is that an issue? Something like the "merge" mentioned here
• Generated profiles of "Developer cmd/pwsh for VS" have different guid for even same distribution #12807
  • We'll need to document this, cause it'll never work.
  • This will obviously be annoying.

[patriksvensson]

@zadjii-msft What's the process for creating a spec for something? Do you have an RFC-process or similar?

[zadjii-msft]

@patriksvensson We don't have an official "RFC" process, but we do have a semi-formal spec review process. This helps us ensure the entire team is on-board with more complicated features, and for scenarios like this one, some of the more complicated edge cases have been thought out. I'd refer to the following:

• Contributing-to a Spec
• The spec template
• completed specs
• all spec PRs

[patriksvensson]

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

[zadjii-msft]

I think that would be very helpful :)

[jpetkau]

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.

[chwarr]

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".)

[patriksvensson]

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

[DavidGamba]

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]

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.

[zadjii-msft]

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.

[stevenvolckaert]

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!

[hapylestat]

@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]

@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)

[4wk-]

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

[zadjii-msft]

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.

[ghost]

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

[4wk-]

@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.

[RollsChris]

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 😎

[huenrong]

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

[carlos-zamora]

Dupping a few issues to this one:

#17277

#17277 (comment)

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

#17513 (comment)

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.

[wolf99]

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.

[TomLewis]

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

[awakecoding]

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.

[mu88]

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