The task was small: make the local file-cache directory configurable instead of fixed inside the code. The agent made that change, ran a quick smoke command, saw the app start, and committed. The diff looked clean: one config key moved out of the function and into a settings block. What the smoke test could not see was the value the agent wrote into that key, its own scratch path from the current session, an absolute directory under its home that existed for the agent but nowhere else.

On the agent's machine the directory was there, so the app started and the write path resolved. The reviewer reads a one-line config move and approves. The failure only shows up on the next machine: a different developer's home has no such folder, the Linux CI runner cannot create it under the expected parent, and the app either crashes on the first cache write or silently falls back to a location nobody monitors.

Never commit an absolute user path as a default

Portable defaults resolve from the environment, not from the author's disk. Read a base directory from an environment variable when it is present, and fall back to a portable location the runtime guarantees: the platform temp directory for ephemeral cache, or a path relative to the repo root for project data. A committed default should work on any OS and any user, which rules out /Users/<name>, /home/<user>, C:\Users\<name>, and a hand-written /tmp/<random> directory.

Catch it cheaply before review

A lint rule, or a simple grep gate in CI, that flags absolute home prefixes and hardcoded session scratch paths in config turns this into a one-line rejection instead of a broken-on-Monday report. Even cheaper: after writing the default, start the app from a clean checkout or a different user account and perform the write operation once. A path that resolves only on the author's disk fails that check immediately.

Agents optimize for the environment they are running in, not the one the code will live in. Where does your build catch a value that only works on the author's machine?