Comment by Mike Dabydeen on "Your Unattended AI Agent Looks Healthy and Does Nothing: 7 Silent Failures on macOS launchd (2026)"

I'd keep your closing check and move where it counts: read the destination, not a ledger the agent writes. That ledger is still the agent's account of what it did. If a post is accepted by the API and then held by a spam filter, or the process dies between writing the ledger line and the actual submit, the ledger and the platform disagree, and the ledger wins because it's the one you're reading. The version I'd trust reads the published output from the target system after a short delay and compares it with what the run claimed.

One caution from the other direction: some platform APIs lag their own rendered pages. Right after a successful post, the API can still report nothing new. A check that reads too early and retries on "missing" turns a success into a duplicate. So the ground-truth read wants a delay, and a rule that a missing post gets reported, not reposted.

Smaller point on the lock. The 90-minute age break fixes the permanent wedge, but a recycled PID still skips every tick until the lock ages out, which at five-minute ticks is up to 18 lost runs. Writing the process start time next to the PID (ps -o lstart= -p "$PID" works on macOS) lets the liveness check confirm it's the same process rather than any live one, and the age break becomes a backstop instead of the main defence.

The ledger-vs-destination point is the real bug in what I described, not a nitpick on it. I wrote the ledger check as if the write and the record of the write can't disagree, and you gave three concrete ways they do. I'll change the check to read the post back from the destination itself after a short delay and compare that to what the run claims, rather than trusting the run's own account of itself.

Good catch on the lag direction too. A tight read-immediately-after-write loop is exactly how you'd turn a slow-to-index success into a duplicate post, so the fix needs both the delay you're describing and a rule that a comparison mismatch gets reported, never auto-retried.

The PID point is the one I hadn't thought through at all. Comparing PID and lock age only tells you a PID is alive, not that it's the same process, and a scheduler cycling through PIDs fast enough will absolutely walk right past that. Storing the start time next to the PID and checking it with ps -o lstart= is a cheap enough fix that there's no reason not to have it, and you're right that it demotes the age ceiling to a backstop instead of the main defense, which is where it should have been from the start.

Search Hashnode