Can global config follow xdg convention？

[dacec354]

project level configuration keeps the same .reasonix.

or provide environment variables to customize config dir, cache dir, persistence dir and so on?

[esengine]

@dacec354 thanks — fair ask, especially on Linux where everything-in-~ is unidiomatic.

Three shapes I considered, and where I'd land:

1. Strict XDG split — $XDG_CONFIG_HOME/reasonix/ for config, $XDG_DATA_HOME/reasonix/ for sessions+skills+memory, $XDG_CACHE_HOME/reasonix/ for caches.

The faithful answer, but it's a breaking change for everyone on upgrade and forces me to ship a migration tool. The split is also genuinely awkward on macOS (Apple says ~/Library/Application Support/) and Windows (%APPDATA%), so going XDG-pure means I'd need three different default conventions per platform. Not worth the complexity for a config preference.

2. Auto-detect XDG when $XDG_CONFIG_HOME is set

Tempting but I don't like it — same install behaves differently depending on a shell-env side effect. Silent default changes are how you get "reasonix lost my session" bug reports. Pass.

3. Env-var overrides, opt-in — what I'd actually merge.

• REASONIX_HOME — relocates everything (sessions / skills / memory / config / cache) under one root. Easiest knob, solves the "please don't dump in my homedir" case.
• Optional finer split: REASONIX_CONFIG_DIR, REASONIX_DATA_DIR, REASONIX_CACHE_DIR — only if the single-knob version turns out to leave someone unhappy. Default falls through to $REASONIX_HOME, then ~/.reasonix.

Linux users who want pure XDG just set:

export REASONIX_HOME="${XDG_CONFIG_HOME:-$HOME/.config}/reasonix"
# or split it via the optional vars when those land

…and they get the layout they want without me forcing a default change on every user.

Project-level .reasonix/ stays put — that's intentionally co-located with the repo (per-project skills / hooks / settings.json travel with the code). XDG is a homedir-layout convention, not a project-tree one.

Want to open an issue with the REASONIX_HOME shape? I'll tag it good first issue — it's a one-day patch (helper that resolves the data root once at process start, all call sites already go through a couple of helpers in src/config.ts / src/memory/session.ts / src/skills.ts so it's not scattered).