Honor XDG Base Directory paths on Linux

Problem

T3 Code currently keeps most persistent files under ~/.t3. T3CODE_HOME / --home-dir makes that tree relocatable, but configuration, state, logs, worktrees, attachments, caches, etc. still share one root.

#748 / #826 solved the configurable-base-directory problem, but not XDG Base Directory separation.

On Linux, it would be useful for T3 Code to honor the standard XDG locations when T3CODE_HOME is not explicitly set.

Possible layout

The exact classification depends on the semantics of the existing files, but roughly:

$XDG_CONFIG_HOME/t3/   configuration
$XDG_STATE_HOME/t3/    database/state, logs, possibly managed worktrees
$XDG_DATA_HOME/t3/     durable application/user data and attachments
$XDG_CACHE_HOME/t3/    regenerable caches
$XDG_RUNTIME_DIR/t3/   sockets/other runtime-only files, if applicable

with the standard fallbacks (~/.config, ~/.local/state, ~/.local/share, ~/.cache) when those variables are unset.

T3CODE_HOME could remain as an explicit override/backwards-compatible way to keep everything under one root.

Worktrees are a special case: for T3-managed worktrees, $XDG_STATE_HOME/t3/worktrees seems like a reasonable default because they are persistent machine/project-specific application state rather than cache. However, they can contain user changes, so independently configurable placement is useful regardless of the default; #9681 is addressing that part.

Related

• #748 / #826 — configurable T3 base directory
• #9681 — configurable per-project worktree location

Drafted with GPT-5.6 Sol via ChatGPT.

Start by tracing the existing T3CODE_HOME and --home-dir path-resolution entry points, then inventory where configuration, state, logs, worktrees, attachments, caches, and runtime files are stored. Review #748, #826, and #9681 for existing constraints. Done means Linux uses the appropriate XDG locations with standard fallbacks while an explicit T3CODE_HOME preserves the unified-root behavior.