There's growing consensus in the developer community about where coding agents like Claude Code, Cursor, or GitHub Copilot truly shine: writing throwaway scripts and prototypes. Code with a limited blast radius. Code you can afford to be wrong about.
I've embraced this myself. When I got tired of managing git worktrees manually, I asked my coding agent to write a shell script that handles just my specific workflow. Nothing fancy. It works, and I use it every day.
But then came the question that's probably bothered you too: where do you put this thing?
The Overhead of "Proper" Solutions
You could build a proper CLI tool and install it to /usr/local/bin. You could wrap it in an npm package with a bin field. You could use Homebrew's tap system. All valid options, all weirdly ceremonial for a 30-line script that might not exist next month.
These approaches feel like driving a forklift to move a cardboard box.
XDG to the Rescue
When I asked ChatGPT about this, it pointed me to the XDG Base Directory Specification—the standard that defines where applications should store config, cache, data, and state files on Linux systems.
The key insight: ~/.local is the user-managed counterpart to system directories. It's not owned by your OS. It's not owned by your package manager. It's yours.
And ~/.local/bin is where your personal executables belong.
The Setup Is Almost Nothing
Add one line to your .zshrc or .bashrc:
export PATH="$HOME/.local/bin:$PATH"
That's it. Your scripts are now in your PATH.
What I love about this is the reversibility. Delete that line, and it's like nothing ever happened. No packages to uninstall. No symlinks to hunt down. No residue.
Why This Pairs Well with Coding Agents
This lightweight setup is exactly what makes delegating to a coding agent feel safe. When the infrastructure is this thin, you don't worry about "what if the agent messes up the build system" or "what if this breaks my global npm installation."
The answer is: nothing bad happens. The worst case is a broken script in a folder you control completely.
I keep ~/.local/bin as a git repository. When I ask my agent to add a feature to one of my scripts, I can commit before and after. If it doesn't work out, I roll back. Simple version control for simple scripts.
Practical Tips
- Initialize git in ~/.local/bin — Track changes to your scripts with zero friction
- Use descriptive names — You won't have tab-completion conflicts with system commands
- Keep scripts focused — If it grows beyond a hundred lines, maybe it deserves a proper home
- Add a README — Future you will thank present you
The Takeaway
The best infrastructure for experimental scripts is almost no infrastructure at all. ~/.local/bin gives you a clean, standard, reversible place to put your coding agent's output. No ceremony, no lock-in, no regrets.
It's a small thing, but it removes just enough friction to make "let me write a quick script for that" a genuine option instead of an aspirational phrase.