Eight shell and git mistakes our agents made, and the rule for each

📓 Why keep a list of your own mistakes

General advice about shell safety is easy to find and easy to ignore. A rule that names a date, a command and a consequence is read differently. We keep one short list in the file every agent loads at the start, and each entry is a real failure. When a new one happens, one line is added: what broke, and the rule.

🔟 The eight

1. A whole crontab replaced. On 12 October 2026 the root crontab was overwritten with three lines and 59 jobs, including backups and database dumps, disappeared. It was noticed a day later. Rule: never rewrite the crontab. Add a new job as its own file under the cron directory, and run a guard that compares the job list.
2. ssh inside a read loop. In while read ... < file, ssh reads the rest of the file from standard input. Only one of five writers ran. Rule: read the list into an array first, or call ssh -n.
3. Killing yourself with a pattern. pkill -f and pgrep -f match the command line of your own shell if the pattern appears in it. An agent killed its own shell, and a watcher waited for itself. Rule: kill by process id, and check that the pattern does not appear in the launching line.
4. An empty list means everything. git reset HEAD --pathspec-from-file= with an empty file reset the whole shared index. Rule: before any command that takes a list from a file or from xargs, check that the list is not empty.
5. Reserved shell names. Assigning to GROUPS, RANDOM, SECONDS, UID or HOSTNAME is silently ignored. Rule: give your own variables a prefix.
6. && and set -e. cmd && echo ok does not stop a script when cmd fails under set -e, and in our agent tool set -e did not work at all, because the command is wrapped. A commit went out with ten red tests. Rule: check the exit code explicitly with if ! cmd; then exit 1; fi.
7. The pipe takes the exit code. pytest | tail -1 && git commit commits on red, since the exit code of a pipe belongs to its last command. Rule: run tests without a pipe, or set pipefail.
8. A command that never ran. A chmod +x inside a command that was blocked did not execute, and nobody checked. Rule: check the file mode before you commit.

🛠️ Practice: build your own list

1. Open the last five incidents caused by an agent or by a script. Write one line each: date, command, consequence.
2. For each, write one rule that a script could check. If it cannot be checked, rewrite it until it can.
3. Put the list in the file your agents read first, and keep it under thirty lines.
4. Add a checker for the rules that can be tested: for example a script that refuses a commit when the staged list is empty or a mode is wrong.
5. After every new incident, add one line the same day.
6. Once a quarter, delete rules that a tool now enforces.

✅ Check yourself

• Pick any rule at random. You can name the incident behind it.
• Run a loop with ssh inside it on two hosts. Both hosts are reached.
• Make a test fail under a pipe and confirm that the commit is refused.
• An agent that has never seen your system reads the list and avoids at least three of the eight on its first task.

🚧 When this does NOT work

• A list nobody loads. If the file is not in the agent's start context, the rules do not exist.
• Rules without a trigger. "Be careful with cron" is not a rule. "Add jobs as files, never edit the crontab" is.
• Too many rules. Past thirty lines the important ones disappear. Remove what a tool already enforces.
• Different shells. Some of these behave differently in other shells. State the shell the rule is about.
• Rules instead of permissions. An agent that must not touch production should not hold production credentials, whatever the list says.

📊 Evidence

➡️ Next

Put recovery steps in place with Recovery after a failed, stuck or uncertain run, and read how to write the instructions agents load in AGENTS.md and rules files.

Sources

• AGENTS.md and rules files: set a coding agent’s scope: where the list lives.
• Recovery after a failed, stuck or uncertain run: recovery steps.
• An AI incident playbook for a small team: what to do when an agent gets it wrong.
• Permissions and data flow: what an agent may touch.