When I try to login as root, this warning comes up.

luvpreet@DHARI-Inspiron-3542:/$ sudo su
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? 

If I say yes, it simply logs in, and my shell changes from bash to zsh.

If I say no, it says that ncompinit: initialization aborted and logs in.

After login, my shell changes to zsh.

All I ever did related to zsh, was download oh-my-zsh from github.

What is happening and why ?

Using - Ubuntu 16.04 on Dell.


7 Answers 7


You can list those insecure folders by:


The root cause of "insecure" is these folders are group writable.

There's a one line solution to fix that:

compaudit | xargs chmod g-w

Please see zsh, Cygwin and Insecure Directories and zsh compinit: insecure directories for reference.

  • 1
    This one-liner fixed my problem 👍 Apr 16, 2018 at 0:29
  • My insecure directory was also other-writable, so I had to use "chmod o-w" in addition.
    – Ezra
    Jan 28, 2019 at 2:40

I encountered the same problem after following https://docs.npmjs.com/getting-started/fixing-npm-permissions, and I solved it using:

% cd /usr/local/share/zsh
% sudo chmod -R 755 ./site-functions
% sudo chown -R root:root ./site-functions

I found the answer here: https://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories


I'm using WSL and the above solutions didn't fix it for me, but they did lead me towards this incantation which did fix it:

cd ~
compaudit | xargs chown -R "$(whoami)"
compaudit | xargs chmod -R go-w
  • Fixed my issue in wsl
    – nick-s
    Jul 15, 2019 at 5:32
  • this works for WSL2 Arch just fine :) thanks
    – zfogg
    Aug 5, 2021 at 4:06

This morning, some packages in my system updated, and left me with this error message.

Apparently, something in the update changed the username and group to numbers, instead of root, as so:

# There are insecure files: /usr/share/zsh/vendor-completions/_code
# sudo ls -alh
-rw-r--r-- 1  131  142 2.6K 2019-10-10 16:28 _code

I simply changed the user and group for this file back to root and the problem went away. I did not need to change any permissions, and would caution against doing so unless the underlying cause of the problem is understood.

sudo chown root _code && sudo chgrp root _code

After switching 131 and 142 back to root, this error message from zsh went away.

  • This worked for me too. Nov 16, 2019 at 0:30
  • I had to cd into /usr/share/zsh/vendor-completions and this worked. :) Nov 16, 2019 at 13:14
  • One should also be investigating the underlying cause of why installing stuff is giving away root's ownership of global scripts.
    – JdeBP
    Mar 4, 2020 at 10:25

When I would run compaudit, I would get the insecure directories error from the plugins directory of oh-my-zsh. So I changed the permissions in the plugins directory:

  • cd /home/${usr}/.oh-my-zsh/custom/
  • sudo chmod -R 755 ./plugins

fixed the issue for me.

Ubuntu 16.0.4 on WSL.


Neither compaudit | xargs chmod g-w nor ZSH_DISABLE_COMPFIX=true worked for me when trying to solve this issue for a non-sudo user on macOS.

What did help was to use compinit -u.

From the docs here: https://zsh.sourceforge.io/Doc/Release/Completion-System.html

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, provided the dumpfile exists.

The odd thing for me was that the files did fulfill the requirements (owned by root and not group writable) but I still kept getting the error. Using -u solved that.


There are multiple solutions on how to fix the problem in this question. However I stumbled upon this thread due to an issue with antigen bundle installs on Windows 10 Ubuntu WSL. I solved it by setting the umask 022 within my .zshrc to ensure that new directories are created with the correct umask.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .