config folder is out of place on Linux

Ramblurr · GitHub ·

6 min read Original article ↗

Activity

  1. badlogic commented on Jan 7, 2026

    @badlogic

    Yeah, I regret not doing this from the beginning. However, since there are quite a few users of pi now, and since migrating this automatically for them is super icky, I'm afraid we'll have to live with it. The PI_CONFIG_DIR is your escape hook.

    Reacted by enprop, a1c9298 and podgorniy

    Reacted by Cole Neville, Óscar, Ben Bouillet, Maplefurr, Ivan Pankratov, Izzur Zuhri, VDawg, ruro, Gewi413, Jamie Hoover and 28 more

    Reacted by John Rey Rabosa

  3. Ramblurr commented on Jan 8, 2026

    @Ramblurr

    @badlogic thanks for the consideration, could I recommend just adding a backwards compat check after the check for PI_CONFIG_DIR?

    It would go like :

    1. Look for presence of PI_CONFIG_DIR
    2. Look for existence $HOME/.pi dir (whatever the current logic is).. if this dir exists just use it.
    3. then proceed with XDG_CONFIG_HOME and the defaults?

    No migration necessary.

    Many apps have been in this situation before and solved it this way.

    Reacted by Bill Mill, Tianshu Wang, Jefta van der Horst, Guillaume, quasigod, 汐, Casper, Mario Aichinger, Daemon, Maksym Hazevych and 26 more

  4. KenMacD commented on Mar 5, 2026

    @KenMacD

    PI_CONFIG_DIR didn't seem to do anything. Instead I had to set PI_CODING_AGENT_DIR=~/.config/pi/agent.

  5. aichingm commented on Mar 23, 2026

    @aichingm

    Hi @badlogic would you be willing to accept a PR for @Ramblurr proposal? It is not unusual to handle backwards compatibility like this. It would make a lot of linux (and maybe some mac) users happy 😃

    Reacted by clait, Maksym Hazevych, rough-street, Casey Link, Sandeep Dilip, Chris Lasher, Oliver Schrenk, VDawg, Felix Nordén, HPCesia and 6 more

  6. ewired commented on Apr 10, 2026

    @ewired

    It's really not clear what I have to do to get Pi to not pollute my home directory. Apparently I need to set PI_CONFIG_DIR and PI_CODING_AGENT_DIR? I like Pi and I hope you consider accepting a backwards-compatible PR for doing this correctly if one is made. This is offputting for many people. I would have written off Pi completely over this, especially given the ridiculing of the correct solution (#2870 (comment)) as AI psychosis, if I had not been forced to use it in a low-RAM environment. Opencode does it perfectly. I hope if the out-of-box behavior doesn't change, at least consider making it easy/clear to configure it.

    Reacted by Maksym Hazevych, Lucas Parzianello, daynbob, residentcat, blong, Kamil Babaev, Endrik Einberg, Mattias Petter Johansson, Casey Link, David Roman and 20 more

  7. mpj commented on Apr 19, 2026

    @mpj

    +1000 on @ewired, this made me sad to hear.

    It's quite important for developer ergonomics that XDG is followed - every single tool I have is in my .config, I really hate when config is sprawled out, makes me miss commiting stuff to my dotfiles etc, even worse when the config point is not changeable, really hard to deal with. XDG is amazing, but at the very least we should have a way to override with an ENV.

    I understand that this is not necessarily the most trivial and risk-free matter to fix in a backwards-compatible way (and perhaps the former #2870 wasn't taking the complexities into account and deserved dismissal IDK) but please do consider being open to accepting SOME fix.

    I really really want to have my configs in one place - if one has a setup that relies a lot on XDG this is maddening and will cause forks for a very bad reason to do forks.

    Reacted by Cole Neville, Chris Lasher, Ivan Pankratov, HPCesia, 0x62ash and Marcin M

  8. davdroman commented on Apr 20, 2026

    @davdroman

    I would have written off Pi completely over this

    I decided to set up Pi today from hearing good things about it and this is the first issue I came to. I'm on the verge of writing off Pi completely too based on this thread along with #2870 (comment).

    Reacted by Cole Neville, Chris Lasher, Boris Kaul, Óscar, Ivan Pankratov, Mariann Abshire, logari81, jspast, d-kretschmann-dotsource, HumanoidSandvichDispenser and 4 more

  9. HaleTom commented on May 11, 2026

    @HaleTom

  10. dotgreg commented on Jun 17, 2026

    @dotgreg

    temp workaround with symlink seems to work too:
    ln -s ~/.config/pi ~/.pi

    Reacted by Casey Link, HPCesia, logari81, Nathan JANCZEWSKI, François Lamboley, Josh Mock, Marek Lukáš and Astrozen

    Reacted by Delyan Lev. Neimand and 百地 希留耶

  11. HaleTom commented on Jun 20, 2026

    @HaleTom

    @dotgreg The work-around indeed works, but defeats the point of not polluting $HOME with a myriad of entries.

    Reacted by Delyan Lev. Neimand, HPCesia, Sami Ansari, Nathan JANCZEWSKI, Victor, Marek Lukáš and William McGann

  12. dotgreg commented on Jun 20, 2026

    @dotgreg

    Agree, not a silverbullet, I do use it as my .config is under git. Would be better having native support.

  13. overtongeist commented on Jun 20, 2026

    @overtongeist

    PI_CONFIG_DIR didn't seem to do anything. Instead I had to set PI_CODING_AGENT_DIR=~/.config/pi/agent.

    FYI, CONFIG_DIR_NAME has recently been born in 008c76f (v0.79.7).

  14. Ramblurr commented on Jun 20, 2026

    @Ramblurr

    @dotgreg I downvoted your symlink workaround because PI_CODING_AGENT_DIR works just fine to get .pi out of ~/

  16. manojnakp commented on Aug 6, 2026

    @manojnakp

    I have a readonly home dir (that's my intent; so that no app can create its own dirs behind my back). I'm currently going with PI_CODING_AGENT_DIR env var. But that is not separating config/state/data/cache. Especially a problem for me since I would like to version control my ~/.config/SOMETHING. So currently going with this:

    • XDG_DATA_HOME="$HOME/.local/share and PI_CODING_AGENT_DIR=$XDG_DATA_HOME/pi
    • symlink ~/.config/pi/settings.json -> $PI_CODING_AGENT_DIR/settings.json (or the other way;)
    • symlink ~/.local/state/pi/sessions/ -> $PI_CODING_AGENT_DIR/sessions/ (or should it be ~/.cache? Probably depends on whether need to be rm -rf safe or not)

    But still symlinking every extension-specific stuff is complicated. This is almost like fighting against pi coding agent to opt-in for a specific set of files (by symlinking them) to be tracked in my git!

    Relates to #2870

    XDG Base Dirs spec was thought out to separate config (long lived; usually git tracked for dotfiles), persistent data,state (risky to rm-rf but still user's choice if size is growing out of hand or something went corrupt and agent is crashing) and cache (safe to rm-rf).

    Reacted by John Dougan, Jack, Stuart Axon and Erik Terpstra

  17. rurban commented on Aug 17, 2026

    @rurban

    Reacted by Maksym Hazevych, Derek, beeman, Ben Dean, Xendak, Randy Syring, Jeff Casavant, Giang (Zach) Nguyen, AL Berez, Tim and 26 more

  18. JoshMock commented on Aug 18, 2026

    @JoshMock

    Is this not what semver is for? If it's a breaking change to fix this, bundle with a few other desired breaking changes (surely a few have amassed by now) and ship 1.0.0 when it hits critical mass.

    Or, more conservatively, deprecate ~/.pi/ with a logged warning, use @Ramblurr's backward compat check and ship that in 1.0.0, then remove the deprecated location whenever 2.0.0 ships.

    That said, I get why @badlogic is hesitant to ship a breaking change while the project's popularity is booming; being a maintainer of a popular project is not easy (source: I maintain the official Node.js client for Elasticsearch). Breaking dev flows for thousands of people at once is a recipe for a LOT of noise. Not shipping breakage during exponential growth is the easiest way to avoid it. Leveraging semver and shipping a handful of breaking changes at once (and planning to get very little other work done for a week during the fallout) is the next best thing.

    Reacted by ewired, Sibin Grašić, Binh Nguyen, HPCesia, Saurabh, Chi Cuong HA and Leo Thern