launchctl plist has a stderr that talks about how getcwd operation not permitted so how do I fix it?


TLDR for those who googled and found this

In Catalina, launchd can't read files or run scripts located inside your ~/Documents folder. Just avoid putting your scripts there and rewrite your scripts not to read files in ~/Documents. Creating a new file or symlink will work, though. See the answer below for details.

Original question

I came via this answer to help me create a script that will update a symlink every day.

And there was an article it links to teaching me how to use plist and launchctl

SO this is my plist which is installed in ~/Library/LaunchAgents

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">









When i check the stderr I saw the below

shell-init: error retrieving current directory: getcwd: cannot access parent
  1 bash: ./ Operation not permitted

stdout.log was empty

How do I solve this?

My original script

#!/usr/bin/env bash

date=`date +"%Y-%m-%d %A"`
folder="." # replace with full path to desired folder

if [ ! -f "$file" ]; then
    touch "$file"
    echo "Created file: $file"

ln -sf "$file" "$folder/"
echo "Created link to file: $file"

After trying out jksoegaard answer, the last part of my plist looks like this:


Latest change after taking jaume comment


Latest change

in the bash script

folder="$1" # replace with full path to desired folder

in the plist

  <string>/Users/kim/journals/ /Users/kim/journals</string>

I have also tried


And now I get this

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
/bin/bash: /Users/kim/journals/ Operation not permitted

thanks to @jaume with great patience, he/she/they have helped me get to the point where I realized that the only thing that worked was to move away from the Documents folder in Catalina.

I did find this link suggesting to create a fake bash clone, but I didn't try.

Also a big thank you to @nohillside

One useful thing I learn is to load and unload plist without restarting laptop

first unload

launchctl unload ~/Library/LaunchAgents/

then load

launchctl load -w ~/Library/LaunchAgents/



After a long chat session, it turns out that the root of the problem was that bash can't fully access the Documents folder. The OP had shortened the actual path for instead of being located in /Users/kim/journals, the script resides in a subfolder of ~/Documents.

The Documents folder is sandboxed, as explained in this Apple document:

In macOS, data in critical areas is itself sandboxed — which ensures that users remain in control of access to files in Desktop, Documents, Downloads and other areas from all apps, whether the apps attempting access are themselves sandboxed or not.

and bash can't read its contents from within the .plist file.

Two solutions

Place the script outside of ~/Documents

Interestingly enough, although bash can't read the contents of the Documents folder, it can write to it.

So one solution is to move outside of ~/Documents. For instance, if placed in /Users/kim/bin/, this should work:

  <string>/Users/kim/bin/ /Users/kim/Documents/Apps/CompanyLevelApps/OILD/16-journals</string> 

(Tested on macOS 10.15.5 Catalina.)

Grant full disk access to bash

Another solution is give bash full disk access. Just add /bin/bash to System Preferences>Security & Privacy>Privacy>Full Disk Access.

Note that even with full disk access, permissions would prevent bash from reading arbitrary files in the file system, but you have one fewer level of protection.

(Tested on macOS 10.15.5 Catalina.)

Two suggestions

I'd suggest that you do the following two changes to your configuration:

Remove reference to working directory

I've noticed that setting a working directory in the .plist file:


causes this error:

job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted

Your script doesn't need the WorkingDirectory key to successfully create the symlink, so you may want to remove it to get rid of the error.

Create symlink with relative path

Your script creates the symlink:

ln -sf "$file" "$folder/"

with an absolute path:

[email protected] -> /Users/kim/Documents/Apps/CompanyLevelApps/OILD/16-journals/2020-06-10

To may want to use:

ln -sf "$(basename "$file")" "$folder/"

instead to create a relative symlink that is easier to read:

[email protected] -> 2020-06-10

Full path in plist file

It's important to note that providing the full path for (as explained in jksoegaard's answer) was a necessary change for the .plist to work properly, as relative paths are not supported.