Can’t install shell command for remote scripting: “RoboFont is not allowed to open documents in Terminal.”

  • I’m hoping to code in an external editor and run the Python in RoboFont, but my roboFont -p command has stopped working. The error message is this, if that is useful:

     *  Executing task: robofont -p /Users/stephennixon/type-repos/name-sans/source/01-name_sans-robofont_scripts/italics/ 
    source /Users/stephennixon/type-repos/name-sans/vezsh:1: command not found: robofont
     *  The terminal process "/bin/zsh '-c', 'robofont -p /Users/stephennixon/type-repos/name-sans/source/01-name_sans-robofont_scripts/italics/'" terminated with exit code: 127. 
     *  Terminal will be reused by tasks, press any key to close it. 

    This has happened before, and usually my solution is to delete the roboFont symlink, then re-install it from the RF preferences. See

    However, the shell command will no longer install. Probably, this is due to me now using macOS Ventura (13.0 (22A380)). It seems like a permissions issue... but I don’t really know where to sort it out. Has anyone else had this issue before? How can I fix it?


    For added context, I am currently using RoboFont Version 4.3b (build 2205062222).

    Thanks for any pointers!

  • Hey @ArrowType! The 4.4 beta has a brand new shell scripting interface. Did you try it?

  • An additional hurdle is that I now have to use the full path to a script when I run it in the VS Code command line (rather than the relative path, which previously worked). Will update if I can figure out how to configure that in a VS Code "Task."

    Oh, hmm. Ha, after chasing that problem a bit, it seems like the last issue may have been a little bug with VS Code. Once I modified the tasks.json file and restarted, the task started working only once I reverted to how it was before my changes. So, maybe I just had to restart VS Code?

    In any event, I now have it working again!

  • Ah, nice, @jackson helped me find the answer!

    The relevant file is at Contents/Resources/roboFontShell, so I was able to cd to /usr/local/bin and make a symlink:

    ln -s "/Applications/" roboFont

    I did similar for my venv, and that seems to be working, as well.

  • As an update, I have granted both RoboFont and Terminal "Full Disc Access," and restarted both apps. Unfortunately, the problem persists.



  • Hmm, but unfortunately, even when I symlink that specific file into the bin, it doesn’t work as needed.

    ▶ ln -s "/private/var/folders/x0/q5zt3sx15ssdz5mjcm9rgvh40000gn/T/tmp51xeazy6" /usr/local/bin/roboFont

    If I open a new terminal window, here’s what I get:

    ▶ robofont -h
    zsh: command not found: robofont
    ▶ roboFont -h
    zsh: command not found: roboFont

    This may also be further complicated because I tend to operate from within virtual environments set up by venv... But I think I should be able to add a symlink there (i.e. venv/bin/roboFont) and have it work. I think I’ve done this in the past, but it isn’t currently working.

  • Ahh, if I click the "info" icon in the error popup, I can get to the exact file:


  • Hmm, I did search for the obvious, tmppjtodobh, but my current guess is that maybe this file is generated on the fly...

  • Hmm, everything seems to be allowed that I can allow:


    that the wrong file to symlink ;)

    Can you please tell me which file to symlink? ;)

  • admin

    that the wrong file to symlink ;)

    Check your permissions in for Terminal in your system preferences. (Privacy & Security --> Files and Folders --> Terminal)

  • Oh, also: based on Frederik’s comment that the command is a symlink, I tried to manually open the RF app’s package contents and find the file /Applications/, then make a new symlink for that in /usr/local/bin:

    ln -s "/Applications/" roboFont

    However, after that, running roboFont -h just gives me this:

    ▶ roboFont -h
    2023-01-18 21:13:45.133 roboFont[9700:168909] The Info.plist file must have a PyRuntimeLocations array containing string values for preferred Python runtime locations. These strings should be "otool -L" style mach ids; "@executable_stub" and "~" prefixes will be translated accordingly.

    I’m pretty confused at what that means... thanks for any help!

Log in to reply