This drives me mad, I believe Ollama and Claude Code also do this. Seems to be rife in the LLM world. IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
This 11 year old, open issue is very symptomatic of this IMHO: https://github.com/rust-lang/cargo/issues/1734
.cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
for new installations going forward, why not put the folder in XDG_CONFIG_DIR and an optional symlink from ~/.cargo that can be opted in
Which is not the behaviour most people would think is sensible, especially for CLI programs.
Agreed, and also, tinfoil hat time:
I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?
I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle.
(Disclaimer: I work on Pi but I dislike XDG in all settings)
I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views.
And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible.
Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
For example:
- .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var
- .gitkraken has: logs, notif, profiles, repohooks, service, themes
- .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad
- .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events
- .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam
- .xpipe has: cache, logs, settings, shell, storage, webview
...etc
I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever.
It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc...
I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.