From ZSHs website on what compaudit does:

For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by the current user. If such files or directories are found, compinit will ask if the completion system should really be used. To avoid these tests and make all files found be used without asking, use the option -u, and to make compinit silently ignore all insecure files and directories use the option -i. This security check is skipped entirely when the -C option is given.

This issue sounds similar to #433, where a few methods were proposed to solve the issue. There is also a SO post with a few solutions here.

My guess is zsh thinks potentially dangerous files could be loaded and is, therefore, taking steps to try and prevent that. I'd give the threads above a look to see if any of the solutions work for you based on what files or directories are being designated as insecure when you run compaudit.

@MaximDevoir
Thank you for your answer. I have tried #433 but it won't work. I have also been struggling amount other solutions for weeks.
I don't have this issue with my normal user. It only pops up when I run sudo zsh.
Also, I was using zsh on MacOS before the latest version, it didn't have the problem neither.
I only see this problem on Catalina.

But, still setting ownership to /usr/local/share/zsh does sound strange to me, cause it suppose to be a PUBLIC directory, not only belongs to one account.

Best regards,

Yeah, I guess it makes sense for ZSH to complain about insecure files while executing as root; zsh sourcing public/writable files and directories.

You could set the ZSH_DISABLE_COMPFIX flag in your ~/.zshrc config:

ZSH_DISABLE_COMPFIX="true"

From Marc in ohmyzsh/ohmyzsh#6835 (comment):

The way zsh completions are loaded, you will get the message even if there is no real security risk. So just enable [the ZSH_DISABLE_COMPFIX] flag to ignore it.

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

compaudit | xargs chmod g-w

Wow, I just tried this and my Mac instantly rebooted. Now it's stuck in an endless reboot cycle.

I guess that's a lesson in not trying random things one finds online...

UPDATE: Well, after about 2 or 3 dozen restarts, it finally booted. Maybe this was unrelated and just very unlucky timing with entering that command. I had agreed to a software update about an hour or two prior to this, but I find it strange it rebooted exactly as I pressed enter on this command.

Anyway, the "insecure directories" warning is gone now, lol. Mac OS is not my primary OS so I am not used to its peculiarities.

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

This worked for me! Thanks @pvinis

Interesting. In my case I had some homebrew installed stuff is /usr/local/share/zsh directory. When I removed that as zsh is native to MacOS the problem went away. The other solutions above did not work. Anyone know what I will be missing if anything deleting the above. Much of what was complained about were soft links to somewhere in homebrew managed stuff.

I am not sure what initially added these. Something I did over a month ago.

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

like @nandorojo, this also solved my problem

As my user is the owner of the files which compaudit complains about, I only get the warnings when running as root, ie. after sudo -s. The proposed solutions in #433 all entail changing the owner of files. I want my user to own files in /usr/local/share, but also want to occasionally run things as different users, or root. Why zsh doesn't support this I don't understand. Only solution appears to be to disable compaudit. This is undesirable

@benorgera I have the same issue. My machine has a profile for my own projects, and for my job. ZSH_DISABLE_COMPFIX="true" doesn't fix it for me. I can either have one profile working, or the other.

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

This worked for me! Thanks @pvinis

Worked for me too

As my user is the owner of the files which compaudit complains about, I only get the warnings when running as root, ie. after sudo -s. The proposed solutions in #433 all entail changing the owner of files. I want my user to own files in /usr/local/share, but also want to occasionally run things as different users, or root. Why zsh doesn't support this I don't understand. Only solution appears to be to disable compaudit. This is undesirable

I have the same issue. My machine has a profile for my own projects, and for my job. ZSH_DISABLE_COMPFIX="true" doesn't fix it for me. I can either have one profile working, or the other.

@benorgera @nldoty I have a similar situation. I have admin and non-admin user accounts on my macOS work machine. For security purposes (supposedly), I have to do my day-to-day-work with the non-admin account, and only use the admin account for tasks which require those perms, like software upgrades. This means my Zsh installation, and all related directories, are owned by the admin account, and I can't simply chmod and chown to the non-admin account as described in all the other posts.

The solution is to ignore the insecure directories for the non-admin account, as described in the zsh docs and zsh-users/antigen@4c4f805:

# ~/.zshrc
autoload -Uz compinit
if [ "$(whoami)" = "YOUR_NON_ADMIN_USER" ]; then
  compinit -i # Ignore insecure directories
else
  compinit
fi

The non-admin account doesn't have permissions to perform any actions on the pertinent directories, so ignoring them doesn't pose a security risk that I'm aware of.