Trace the control flow in order and the one-shot property does not live where the title puts it. The gate's `exit 0` sits above both the rewrite and the unload [17]. Every firing before 2026-07-07 therefore leaves the agent loaded, and the first firing at or after the date detaches it, whether it rewrote the value or found it already changed [1]. That ordering also covers the case an equality test would drop: the gate compares `-lt 20260707`, a lower bound [6], so a Mac that was powered off on the 7th gets its rewrite on the first slot after it comes back [2].
The rewrite half is careful work. `jq ... settings.json > settings.json` truncates the original the instant the shell opens the redirect target [10], so the output goes to a temp file, gets re-parsed by `jq .`, and reaches the real path only through an `mv` that the `&&` chain skips if verification fails [11]. The `.bak` copy is taken before any of that [9]. Three jq invocations, one of which exists only to check the previous one's work [4]. The case-insensitive `grep -qi 'fable'` on the current value is the idempotency that duplicate calendar slots require, since there is no way to ask for one firing at one datetime [5][12].
The two lines after that chain are where I would send this back. The script sets `-uo pipefail` and not `-e`, and neither the `switched model` log line nor the `launchctl unload` is conditioned on the chain having worked [20]. Two paths follow. If jq is not on the PATH launchd hands the job, the read returns empty, `grep` matches nothing, the else branch logs that the model is already fine, and the unload runs anyway [3]. If the read succeeds and the write fails, the log records a switch that did not happen, and the unload still runs [3]. Both paths retire the agent with `settings.json` untouched. The script already thinks about paths in one place, calling `/usr/bin/osascript` in full while jq, grep, cp and mv stay unqualified [22]. I would set PATH in the plist and gate the unload on re-reading `.model`.
The post's title promises four pitfalls; what the walkthrough spells out is three script-level guards, the planting-day misfire, the self-truncating redirect and unloading a job that is already unloaded, on top of launchd's expressiveness limit [5]. The already-unloaded guard is the cheap one, `2>/dev/null || true` so a second pass cannot abort the script [15].
For this shape to fit somewhere else, three things have to hold: the end date is known when you plant the job [1], the change is one scalar in a JSON file [2], and the replacement value is stable enough to write down now for a firing in July 2026, which for this author means the alias `opus` rather than a model ID, per the policy in his CLAUDE.md [13]. The job is a per-user LaunchAgent under `~/Library/LaunchAgents` [18], so it only exists on a machine somebody logs into.
