Migrating from DISABLE_AUTO_UPDATE to zstyle ':omz:update': which settings actually take precedence

Short answer

When both are present, the legacy environment variables are evaluated unconditionally on every Oh My Zsh release that supports them, so DISABLE_AUTO_UPDATE="true" keeps auto-update fully disabled even if a zstyle ':omz:update' mode line sits next to it. The zstyle keys are only meaningful on versions whose update library actually reads them; older installs silently ignore the zstyle block entirely. Because the exact precedence between UPDATE_ZSH_DAYS and zstyle ':omz:update' frequency is not uniformly documented across releases, treat the variables as the safe baseline and zstyle as an enhancement — and verify on each machine rather than assuming.

Why this is version-dependent

The zstyle-based update configuration was introduced after the variable-based one, and the framework's update code only consults zstyle ':omz:update' ... when that conditional logic exists in your local ~/.oh-my-zsh. On a pre-zstyle install, the zstyle lines are harmless no-ops: zstyle itself is a zsh builtin and setting a style nothing reads has no effect. On current installs, the update path may privilege the zstyle mode over the legacy day-count variable. That asymmetry is exactly why a shared dotfiles repo works: the intersection of both mechanisms is "legacy variables always apply, zstyle applies where supported." Note the framework never rewrites your .zshrc, so nothing migrates the keys for you — you confirmed this already.

A cross-version .zshrc pattern

Keep the legacy variables as the unconditional baseline, then layer zstyle on top. Both blocks must appear before source $ZSH/oh-my-zsh.sh:

# Baseline: honored by every OMZ release
DISABLE_AUTO_UPDATE="true"
UPDATE_ZSH_DAYS=7

# Enhancement: ignored harmlessly on older releases
zstyle ':omz:update' mode disabled   # or: auto / reminder
zstyle ':omz:update' frequency 7

For your non-interactive constraint (cron, CI), keeping DISABLE_AUTO_UPDATE="true" unconditionally is the important line: it is the mechanism with the longest support history, so it is the one you can trust to suppress startup prompts everywhere. Setting the zstyle mode to disabled to match keeps intent consistent on newer installs rather than leaving a contradictory auto in place.

Confirming what your install supports

Do not guess from documentation — inspect the local copy, since each machine may differ:

1. Check the version: omz version (or read the version marker in $ZSH).
2. Grep the update library for the zstyle interface: grep -n "omz:update" ~/.oh-my-zsh/lib/*.zsh ~/.oh-my-zsh/tools/*.zsh. If nothing matches, that install only honors the legacy variables.
3. Read the surrounding conditional in the matching file to see the actual precedence order on that version — this is the authoritative answer for that machine.

Behavioral verification

After editing, start a fresh interactive shell (exec zsh) and confirm no update prompt appears. For the non-interactive case, run zsh -i -c 'echo ok' from a cron-like context and check that startup is silent and fast. If you want to confirm which mechanism is active on a newer install, temporarily remove the legacy variables, leave only the zstyle block, and observe startup behavior — then restore the belt-and-suspenders configuration above for the shared repo.

One caveat

The precise interaction when UPDATE_ZSH_DAYS and zstyle ':omz:update' frequency disagree on a current release is the least-documented part of this transition; the grep-and-read step above is the reliable way to settle it per machine. If your grep output shows precedence logic that contradicts the pattern here, that local source wins — and it would be worth noting the version where you saw it.