Feature Request: store profiles.json in a more sensible location for syncing #5012

Closed
opened 2026-01-31 00:02:53 +00:00 by claunia · 5 comments
Owner

Originally created by @blaineventurine on GitHub (Nov 15, 2019).

Description of the new feature/enhancement

Moving profiles.json to C:\Users\xxx\AppData\Roaming\WindowsTerminal would allow it to make use of the Roaming folder, and also put it in an easier and more consistent place for people to create symlinks to sync it across several machines using OneDrive/Google Drive/NextCloud/etc.

Originally created by @blaineventurine on GitHub (Nov 15, 2019). # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> Moving profiles.json to C:\Users\xxx\AppData\Roaming\WindowsTerminal would allow it to make use of the Roaming folder, and also put it in an easier and more consistent place for people to create symlinks to sync it across several machines using OneDrive/Google Drive/NextCloud/etc.
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-31 00:02:53 +00:00
Author
Owner

@JustinGrote commented on GitHub (Nov 15, 2019):

Why don't you just symlink it to that folder? That said, having a search "hint" to prioritize a path like this would be totally fine I'd say.

@JustinGrote commented on GitHub (Nov 15, 2019): Why don't you just symlink it to that folder? That said, having a search "hint" to prioritize a path like this would be totally fine I'd say.
Author
Owner

@blaineventurine commented on GitHub (Nov 15, 2019):

I do have a symlink, but making use of the Roaming folder would be an easier location to find, rather than C:\Users\xxx\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState, and it would also allow the profiles.json file to make use of the intended purpose of the Roaming folder.

Another option would be to put it under Documents\WindowsTerminal, to keep it consistent with the location of the PowerShell profile.

@blaineventurine commented on GitHub (Nov 15, 2019): I do have a symlink, but making use of the Roaming folder would be an easier location to find, rather than C:\Users\xxx\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState, and it would also allow the profiles.json file to make use of the intended purpose of the Roaming folder. Another option would be to put it under Documents\WindowsTerminal, to keep it consistent with the location of the PowerShell profile.
Author
Owner

@JustinGrote commented on GitHub (Nov 15, 2019):

Yeah this one is a bit tricky, because UWP will sync the roaming across devices which can be desirable, it may not be for some people (say you have different profiles/shells installed on different systems)
https://blogs.windows.com/windowsdeveloper/2016/05/03/getting-started-with-roaming-app-data/#YbkdOulevCwxQVz0.97

As such, I still like the idea that the "default" should be localstate, but it should first look in the following locations for a config (in order of precedence) and use it if present:
%LocalAppData%\WindowsTerminal
%AppData%\WindowsTerminal
%ProgramData%\WindowsTerminal (to allow for GPO organization deployments)
appx-roaming://

@JustinGrote commented on GitHub (Nov 15, 2019): Yeah this one is a bit tricky, because UWP will sync the roaming across devices which can be desirable, it may not be for some people (say you have different profiles/shells installed on different systems) https://blogs.windows.com/windowsdeveloper/2016/05/03/getting-started-with-roaming-app-data/#YbkdOulevCwxQVz0.97 As such, I still like the idea that the "default" should be localstate, but it should first look in the following locations for a config (in order of precedence) and use it if present: %LocalAppData%\WindowsTerminal %AppData%\WindowsTerminal %ProgramData%\WindowsTerminal (to allow for GPO organization deployments) appx-roaming://
Author
Owner

@zadjii-msft commented on GitHub (Nov 18, 2019):

Thanks for the suggestion! We actually intentionally don't put the settings there, because as others have mentioned, it caused more problems than it solved. We're considering adding an option to re-enable that feature optionally, and you can track and discuss that feature here:

/dup #2933

@zadjii-msft commented on GitHub (Nov 18, 2019): Thanks for the suggestion! We actually intentionally _don't_ put the settings there, because as others have mentioned, it caused more problems than it solved. We're considering adding an option to re-enable that feature _optionally_, and you can track and discuss that feature here: /dup #2933
Author
Owner

@ghost commented on GitHub (Nov 18, 2019):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Nov 18, 2019): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5012