Getting "NSCocoaErrorDomain Code=259" on Export Script

I get the following error (per argument) on any sample export script from GitHub.


localhost Hype4[58360]: error creating task file:///Users/MYUSERNAME/Library/Application%20Scripts/com.tumult.Hype4/ Error Domain=NSCocoaErrorDomain Code=259 "Die Datei „“ konnte nicht geöffnet werden, da sie nicht das korrekte Format hat." UserInfo={NSURL=file:///Users/MYUSERNAME/Library/Application%20Scripts/com.tumult.Hype4/, NSFilePath=/Users/MYUSERNAME/Library/Application Scripts/com.tumult.Hype4/}

Just downloaded a fresh copy.

Not getting an issue.

“could not be opened because it does not have the correct format”

could your copy have been corrupted?

The errors apple gives for application scripts are horrendous… If you just download a script from github, you will need to change permissions on the file to be executable:

chmod 755 ~/Library/Application Scripts/com.tumult.Hype4/

This is part of the reason we distribute them with installers, which can change the permissions.

1 Like

Funny enough I have never had to change permissions using the github ones. Even earlier I did not need to.

Thanks @jonathan, Permission! I could have though of that… but I hadn’t have to do it before like @MarkHunte. Maybe because of an older version of Mac OS (X)? Or some horrendously insecure default settings I had enabled. This is on a new machine. Latest OS etc.

Maybe… it has been a problem* as long as I’ve been testing the export scripts :smiley:.

* problem used loosely here, I think macOS is doing the right thing

1 Like

Hmm, my version of the Organized Assets, seemed to have stopped working.
Not sure why as I could have sworn I tested it during this thread?.

Any way I thought I would simply run the installer, then copy paste from the beta version into the v4 version. ( I did try the chmod but that did not seem to work in my case and I do not know if this was the same permission error )

Word to the wise. The installers look for ALL com.tumult.xxxx folders and will overwrite any files it finds that are named the same.

Yes that means it bloody overwrote the beta version…

Lucky for me I use Time machine and was able to get my version back.
The copy and past was done all worked ok.

Be nice if the installers gave you a warning it has found more than on com.tumult folder and give you options…

Well, an installer’s purpose is to install… If you just want the script you can get them directly from the git repository and manually place them.

If you encounter issues again, the readme section on debugging might give better logs to what is happening.

I know and was not really complaining, just wish installers could be more inteligent.

But mainly just a heads up for those of us who may have written our own but not renamed them and also like me have them in the beta and v3 ( still used to drop files for anyone here who “gasp…” has not upgraded ) and run the installer with the intention of only installing for v4.

As I mentioned I was relying on being able to copying the .py text content from one of the others to the new installed file which should have the correct permissions.

I only went for the installed one because chmod in this case did not work and I saw no point in digging deep to see why. Just assumed it was a permission issue and constrained to my system.

C’est la vie

I found this .scpt script for a folder action. It still isn’t quite right as it changes all the files in the folder it’s attached to and not only the to the new files (but that isn’t bad for the purpose).

You would configure it as a folder action when dropping/adding files to script folder:

permission - make executable

on adding folder items to this_folder after receiving added_items
	tell application "Finder"
		set fold_name to the name of this_folder
			repeat with i from 1 to number of items in added_items
				set new_item to item i of added_items
				set the item_path to the quoted form of the POSIX path of new_item
				do shell script ("/bin/chmod +x " & item_path)
			end repeat
		end try
	end tell
end adding folder items to

BTW: couldn’t Hype just make sure that any .py-file in that folder is +x or is this disallowed by Apples Sandbox?


I write my own daemons or more often use Hazel for stuff like that , I find the built in folder actions un reliable and Hazel is a wicked app.

Correct; as the point of Application Scripts is to be a sandbox “hole” to allow any operation to happen on your computer, Hype cannot ever have write access to the files to correct for these problems. (Otherwise an app can do anything it wants!)