Keep dotfile-managed settings separate from machine-local changes

[colonelpanic8]

TL;DR: I want to keep T3 Code settings in a dotfiles repo while still changing things from the UI on one machine, without those changes landing in the repo. Today a single settings.json holds both. Would you accept a layered settings model, and which of the shapes below do you prefer?

Problem

• Each settings file (settings.json, keybindings.json, client-settings.json, desktop-settings.json) is both the configuration and where UI changes are written.
• If you symlink the file into a dotfiles repo, which fix(settings): symlinked settings files stay linked when saved #15009 now preserves, every UI change becomes a dotfiles diff. Values that only make sense on one machine get committed, such as a provider binary path or a debug wrapper.
• If you don't symlink it, the dotfiles copy and the live copy drift apart, which is the problem fix(settings): symlinked settings files stay linked when saved #15009 describes.
• The managed overrides in [Feature] Enterprise managed configuration overrides #16883 / feat(server,web,desktop): enforce organization-managed settings #16931 address a different need. They enforce values and lock them in the UI. I want shared defaults that one machine can still override.

Shape A: fixed layers

Like Claude Code's settings.json and settings.local.json.

• Load order: defaults, then shared settings.json, then machine-local settings.local.json, then managed.
• UI changes are written only to the local layer.
• The settings UI shows which layer each value comes from and offers "reset to shared".

Shape B: imports plus a write target

Like git's include and Alacritty's import.

• A settings file can import others. For example, a machine's settings.json imports ~/dotfiles/t3code/settings.json.
• A setting chooses which file UI changes are written to, defaulting to the importing file.

Either way

• The local layer stays sparse and records only keys changed on that machine. Server settings are already written sparsely, so a dotfiles change still takes effect on a machine unless that machine overrides the same key.
• This needs every setting to have a file form (Every setting should be expressible in a config file #19592) and config kept apart from data (Separately configurable locations for server config, server data, and client files #19591).

Questions

1. Is separating shared settings from machine-local changes a direction you want?
2. Do you prefer fixed layers (A), imports (B), or something else?
3. Should the same model cover keybindings and client settings, not only server settings?

Prior art

• Claude Code settings: shared settings.json, personal settings.local.json kept out of git, and managed-settings.json, with a documented precedence.
• git config: include and includeIf.
• Alacritty: general.import, with later files overriding earlier ones.
• VS Code: machine and machine-overridable scoped settings are never synced to other machines.

Related

• Separately configurable locations for server config, server data, and client files #19591: separately configurable locations for server config, server data, and client files
• Every setting should be expressible in a config file #19592: every setting should be expressible in a config file
• A rule for which settings the client owns and which the environment owns #19593: which settings the client owns and which the environment owns
• fix(settings): symlinked settings files stay linked when saved #15009: symlinked settings files stay linked when saved
• [Feature] Enterprise managed configuration overrides #16883 / feat(server,web,desktop): enforce organization-managed settings #16931: managed configuration overrides
• [Feature]: Per-project local settings outside the repository #8871: per-project local settings outside the repository
• [Feature]: Provide proper files to move the configuration between environments #6802: configuration files that can live in a dotfiles repo

[colonelpanic8]

A proposed implementation is on my fork, not opened here: colonelpanic8#5. It adds an optional read-only shared settings file (--server-shared-settings-file / T3CODE_SERVER_SHARED_SETTINGS_FILE) layered beneath settings.json: defaults < shared file < settings.json. Changes from the UI keep going to settings.json, which stores only differences from the shared values, so a dotfile-managed file stays untouched and machine-local edits stay out of source control. Shared secrets are never copied into settings.json. Happy to open it here if you want it.