Competing automations fighting over config (drift)

Symptom: a setting keeps changing back. One automation sets an old default, a newer automation changes it, then a legacy script reverts it again — so two (or three) systems are fighting and the change won't stick.

How to pin it down:

1. Capture the flip. SSH in and read the running config repeatedly (or on a schedule) and watch the value change. The Activity log time-stamps each check so you can see the cadence of the flips.

2. Correlate timing. The interval between flips usually matches one automation's run schedule — that points at the culprit.

3. Find ALL the actors. The modern trap: some tooling has been migrated to MCP/agentic access while legacy scripts still run. Both are live. You have to track down each one and reconcile them to a single source of truth — that's the real fix, not just re-setting the value.

Today this is a known industry problem: drift comes from competing configs and an unclear source of truth. The durable fix is one authoritative source of truth with drift detection, not more one-off changes.