Every new zsh session on a machine prints `zsh compinit: insecure directories, run compaudit for list` and then asks whether to continue. What is compinit checking, why does it care, and how should you resolve it?

## Why a completion function is a security-relevant file zsh's completion system loads functions from the directories in `fpath` and runs them in your interactive shell whenever you press Tab against the matching command. There is no sandbox: a completion function can run any command, read any file you can read, and write anywhere you can write. That makes an `fpath` entry equivalent, in blast radius, to a line in your `.zshrc` — except that you never open it and never review it. That is why `compinit` does a permissions audit before it trusts what it finds. ## What the check actually tests For each directory on `fpath` and each completion file inside it, compinit considers it insecure if: - it is writable by group or by others, or - it is owned by neither root nor the effective user running the shell. Both conditions describe the same threat: some account other than you (or the system) can replace the contents. The check walks up as needed, so a securely-permissioned file inside a group-writable directory is still a finding — anyone who can write the directory can replace the file. When the check fails you get the `insecure directories, run compaudit for list` warning and, in an interactive shell, a prompt asking whether to ignore the insecure directories and continue or abort compinit. Abort leaves you with no completion system at all, which is why people reach for the silencing flags. ## compaudit `compaudit` is the function that performs and reports the audit. Run it on its own and it prints the offending paths: ```bash compaudit ``` Read the output before changing anything — it tells you which component of your setup created the problem. Typical causes are an installation that unpacked with a group-writable umask, a shared machine where a completion directory belongs to a service account, or a completion directory sitting inside a user-writable prefix that was created by a different account. ## Fixing it properly The repair is ownership and mode, applied to exactly what compaudit named: ```bash compaudit | xargs chmod g-w,o-w ``` and, where the owner is wrong, `chown` the path to root or to yourself, whichever matches how that directory is meant to be managed. Then start a new shell; the warning should be gone. If the offending directory is one you do not actually need, the cleanest fix is to remove it from `fpath` altogether. ## The flags, and what each one really means - `compinit -i` — silently **ignore** insecure files and directories. Completion from them does not load; everything else works. This is the safe silencer: you lose functionality rather than trust bad files. - `compinit -u` — **use** them anyway, no questions asked. This is the dangerous silencer, and it is unfortunately the one most widely copy-pasted, because it makes the warning disappear without losing any completions. - `compinit -C` — a different thing entirely: it skips the check for new or changed completion functions and reuses the dump file as-is, purely for startup speed. On a single-user laptop where the group in question is your own login group and no other human has an account, `-u` is a defensible risk decision — but it is a decision, and it should be made deliberately rather than pasted from an internet answer. On a shared host, a build machine, or anything with more than one interactive account, treat the finding as real: a group-writable `fpath` directory is a privilege-escalation path from any member of that group to every user who tabs a command. ## The recurring-warning trap Because many setups fix the modes but leave the original creator in place, the warning comes back the next time that component reinstalls itself. If you find yourself re-running the same `chmod` every few weeks, fix the umask or the install step that produces the bad modes rather than repairing the symptom on a schedule.