Repository navigation
Make Hex settings easy to share between devices #802
Description
What are you trying to do?
I use Hex on macOS and would like to keep a consistent setup across my devices. When setting up Hex on another device, recreating my preferences and customizations by hand takes time and makes it easy for the setups to drift apart.
For example, I would like to carry over settings such as dictation preferences, shortcuts, and custom vocabulary or corrections where supported. This is related to #390, but I am asking about sharing settings more broadly.
What would help?
A straightforward way to transfer or sync Hex settings between devices would make setup much easier. Two possible approaches:
- Optional iCloud sync for settings between Macs signed in to the same Apple account.
- A manual export/import or copy-and-restore feature for transferring settings between devices, including when cloud sync is not desired.
Ideally, the feature would make clear which settings are included and handle device-specific choices, such as microphone selection, appropriately. Either approach would help; I am open to whichever fits Hex best.
Activity
thdxr commentedon Nov 1, 2026
everything lives in one
settings.jsonin~/Library/Application Support/hex, so copying it to another mac while hex is quit already carries shortcuts, vocabulary, modes and corrections, and transformations are a plain~/.config/hex/hex.config.tsyou can keep in dotfiles. a saved microphone that isn't on the other mac just falls back to system default without changing the setting, and a bad or unknown field falls back to its default instead of blocking launch.hex settings list --jsonwithhex settings setandhex vocabulary addcan also script a setup if you only want some of it.settings.jsonmixes portable settings with per-machine ones (model selection, keyboard source mappings, folder paths, migration markers), so an export needs a clear list of what's included.would a manual export/import between macs be enough for you, or is automatic sync the part that matters?
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
bcoffee0630 commentedon Nov 1, 2026
@thdxr Thank you for the quick and thoughtful reply!
I agree with your point about keeping Hex local-first and avoiding a cloud dependency. A manual export/import feature between Macs would be enough for my use case; automatic sync is not essential.
I understand that most settings are already available in local files, and I appreciate you explaining how to transfer them. However, those paths may be difficult for many users to discover or access, so an export/import option in the app would make moving a setup much more approachable.
It might be even more useful if users could choose which settings to export or import. That would provide some flexibility when moving between devices, especially given the device-specific settings you mentioned.
These are just my thoughts as one user, so please take the time to consider and design the feature carefully before deciding how it should work. Thanks again for the quick response!
thdxr commentedon Nov 1, 2026
manual export/import between macs, no icloud, is a clear scope and fits hex staying local. the likely shape is a labs toggle that adds export settings… and import settings… to general › advanced: export writes a portable subset of
settings.json(shortcuts, modes and corrections, vocabulary, output and recording behavior), and import lists what it will change, grouped, before saving it through the window's normal settings save.desktop/file_dialogonly opens files and folders today, so export needs a save dialog added first.an import has to go through the same checks a saved setting does (shortcut conflicts, labs-gated keys like mouse shortcuts), or a file from another mac could save something this one can't run.
modes, corrections and vocabulary are lists, so import has to either replace or merge them, and merging means deciding what counts as a duplicate.
would picking whole groups (shortcuts, modes and corrections, vocabulary, output) be enough, or do you need to choose single settings?
when you import onto a mac that already has some vocabulary or modes, would you expect them replaced or merged?
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
bcoffee0630 commentedon Nov 1, 2026
For me, choosing whole groups such as shortcuts, modes and corrections, vocabulary, and output would provide enough flexibility. That said, this is just my perspective as one user, so I think the final design should also take other users’ needs and experience into account.
For vocabulary or modes that already exist on the destination Mac, perhaps the import flow could let the user choose whether to merge the imported items with the existing ones or replace them.
thdxr commentedon Nov 1, 2026
that settles the shape: export writes the four groups (shortcuts, modes and corrections, vocabulary, output) to one file, and import lets you tick groups and pick merge or replace for modes and vocabulary, behind a labs toggle. it's still more than a quick change: export needs a save dialog, import needs a picker screen, and merging needs its own rules. until then
hex settings list --jsonandhex settings setcover every setting, andhex vocabulary list/hex vocabulary addalready merge terms, so it can be scripted between macs today.desktop/file_dialogonly opens files and folders, so export needs a save dialog added first.hex vocabulary addalready does, but modes have no obvious key (app, website, name?).if a mode uses transformations from
~/.config/hex/hex.config.ts, would you expect that file to come along too, or is copying it yourself fine?— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
bcoffee0630 commentedon Nov 1, 2026
I would expect to have the option to include custom transformations and their configuration when exporting, while also being able to leave them out—similar to choosing which other settings groups to export.
If a transformation depends on other files, it would be helpful to consider how those could be included so it can work on another Mac. I understand this may require additional design, and I would leave the details to the team.
thdxr commentedon Nov 1, 2026
makes sense: transformations become a fifth group you can leave out, like the others. a transformation script can only import
hex/commandsand files inside~/.config/hex, so the export can takehex.config.tsplus everything it imports from that folder, and it works on the other mac without anything else. until this exists, copying~/.config/hexbetween macs works today: hex reloads the config when it changes andhex commands checktells you if it loads.is replacing the whole transformations folder on import fine for you, or do you keep transformations on each mac that you'd want left alone?
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
bcoffee0630 commentedon Nov 1, 2026
Replacing the whole configuration folder sounds reasonable for my current use, but I’m only on my second day using Hex, so I can’t be sure it would still work for me as my setup evolves. Other users may also have different needs and might not be comfortable with their existing folder being replaced.
If that is the approach you choose, it would be helpful to clearly inform users during import that the entire existing configuration folder will be replaced. Of course, the right way to present and handle this depends on how the feature is ultimately designed.
thdxr commentedon Nov 1, 2026
that settles transformations: import replaces the whole
~/.config/hexfolder, says so plainly before it does, and keeps a backup of the old folder. until there's an in-app export,hex settings list --jsonon one mac andhex settings seton the other moves settings, and copying~/.config/hexover moves transformations (hex commands checkconfirms they load). the in-app version would ship in labs, off by default.for modes and corrections, should an import replace the whole list like the config folder, or add to what's already on the other mac?
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
bcoffee0630 commentedon Nov 1, 2026
My earlier thought was to let users choose when importing modes and corrections: either merge them with what’s already on the destination Mac or replace the existing list. That way, users can choose whichever approach fits their setup.