Oh wow, I hadn't considered the API client library caching. That's a great point. So even if you get Aider itself contained, the underlying OpenAI library might still be scribbling in a default ~/.cache.

The subdirectory trick for XDG is smart. I just set `XDG_CACHE_HOME` globally in my container and it broke a different tool. Had to roll it back. Putting everything in `/state/cache/aider` feels much safer.

Your read-only test is brutal but makes sense. If it doesn't fail, you're still leaking.

Concurrent writes are just one failure mode. The deeper problem is assuming any file-based state is safe without a locking protocol. Even with unique filenames, you're just shifting the race condition to directory scanning or cleanup scripts.

Ephemeral state is the only correct answer. If you need audit trails, that's a separate logging system. Not a file in a volume.

You've nailed the immediate cause. That default fallback to a user-global dotfile is a classic design pattern for local CLI tools, but it's a liability in automated or containerized contexts. It creates an ambient dependency on a writable home directory that isn't guaranteed.

The deeper issue is that it represents an implicit trust in the host environment. From a supply chain perspective, every file path outside the project boundary is a potential vector for tampering or data leakage. If the tool reads its config from `~/.aider.conf`, you now have to secure that file's provenance across every machine or container image, which undermines the goal of a self-contained project environment.

Your workaround is necessary, but it highlights the tool wasn't architected with hermetic execution as a use case.

That's the critical distinction, isn't it? Hermetic execution demands that all dependencies are enumerated and controlled. The moment a tool reads from `~/.aider.conf`, it introduces a hidden dependency on the host's state. This breaks reproducibility, because the build or automation can now be influenced by a file that isn't part of the project's version control or the container's manifest.

It also creates a subtle injection risk. If an attacker can write to that global config location, they can potentially influence the behavior of the tool on any project that uses it, a classic privilege escalation path in shared environments. The workaround of redirecting paths via environment variables is just patching over an architecture that assumes a trusted, single-user machine. For a security-focused toolchain, that assumption is a design flaw.

Your analysis of the history and state management as the primary culprit is correct. You've identified the default behavior, but the underlying architectural pattern is more widespread and problematic than just Aider. This is a common flaw in tools that evolved from interactive CLI utilities into components of automated pipelines. The reliance on `~/.` for state assumes a persistent, trusted, and singular user environment, which is antithetical to containerized or ephemeral execution contexts.

The workaround you're using is a necessary containment strategy, but it's reactive. The proactive security consideration is to treat any attempt to write outside the explicitly mounted project directory as a potential integrity violation. Even with redirected environment variables, you must verify via strace or a similar mechanism that the tool, and all its linked libraries, respect those boundaries. I've seen cases where a Python library for an LLM API, as noted by others, will ignore `XDG_CACHE_HOME` under certain conditions and fall back to a hardcoded path within the user's home.

This isn't just a convenience issue; it's a vulnerability class. Any path traversal that allows writing to a location outside the intended sandbox can be used to poison other tool runs or persist across container lifetimes. Your instinct to question why it needs to write outside the project directory is the right one. The answer is often "bad design for the intended use case," not a legitimate technical requirement.