Creating a Zip & Encrypt Quick Action for macOS

Sunday, March 1, 2026 • 6 min read

It’s easy enough to right-click a file in Finder and compress it into a zip archive, but if you’ve ever wanted to password protect that archive, you need to either use an application or jump into Terminal to run a command. Neither of those approaches matches the speed and simplicity of just right-clicking a file and hitting the “Compress” button. Here’s how I went about trying to make something similar possible.

The Goal

I wanted a Quick Action in Finder’s right-click menu that would:

• Prompt for a password
• Create an encrypted zip archive
• Drop the archive in the same folder as the original file or folder
• Work on both files and folders

Simple enough, right?

Attempt 1: Apple Shortcuts

I really wanted to accomplish this with the Shortcuts app. Shortcuts supports Quick Actions in Finder, has a “Run Shell Script” action, and it looked like exactly the right tool for the job.

Setting Up the Shortcut

The basic plan was:

1. Configure the shortcut to receive files and folders as input
2. Prompt for a password using “Ask for Text” actions
3. Pass the file path and password into a shell script that calls zip -er

The shell script itself was straightforward:

#!/bin/zsh
INPUT="$1"
INPUT="${INPUT%/}"
PARENT_DIR=$(dirname "$INPUT")
BASE_NAME=$(basename "$INPUT")
OUTPUT="${PARENT_DIR}/${BASE_NAME}.zip"
zip -er --password "«Password»" "$OUTPUT" "$INPUT"

Problem 1: Empty Archives

The shortcut ran without errors, but the resulting zip file was empty. Adding debug logging revealed the culprit:

adding: Users/me/Downloads/secrettext.txt
zip warning: could not open for reading: Users/me/Downloads/secrettext.txt

Two things stood out: zip was stripping the leading / from the path, treating it as relative rather than absolute, and there was an “Operation not permitted” error suggesting a permissions problem. Switching to cd "$PARENT_DIR" && zip ... "$BASE_NAME" fixed the leading-slash issue by making the path relative on purpose — but the permissions error persisted.

Problem 2: Sandbox Permissions

Even after I granted Shortcuts Full Disk Access in System Settings, the shell script still couldn’t read files from the Downloads folder. The error was consistent:

zip warning: Operation not permitted
zip warning: could not open for reading: secrettext.txt

This is a known macOS sandbox restriction: Shortcuts' “Run Shell Script” action runs in a sandbox that can block file reads from TCC-protected directories like Downloads, regardless of what permissions you grant in System Settings.

Attempted Workarounds

I tried several approaches to get around the sandbox:

Writing to /tmp first — By having the script write the zip to /tmp and then move it to the destination, I got past the write permission issue. But the read permission problem remained — the script still couldn’t open the source file.

Base64 encoding — I used Shortcuts' native “Base64 Encode” action to read the file, encode it as a string, and pass the string into the shell script to decode back into a file in /tmp. Unfortunately, it seemed like the Base64 Encode action in Shortcuts couldn’t pipe its output subsequent actions.

Passing via stdin — Configuring “Run Shell Script” to receive input as stdin rather than arguments causes Shortcuts to read the file itself and pipe the contents in, bypassing the shell script’s read restriction. This didn’t work reliably either.

After exhausting these options, the sandboxing issues made Shortcuts seem like a dead-end. So I ended up abandoning Shortcuts, and trying an app I’ve never used before.

Attempt 2: Automator

Automator is older and less flashy than Shortcuts, but it has more permissive file access and its Quick Actions integrate into Finder just as well.

Basic Setup

1. Open Automator and create a new Quick Action
2. Set “Workflow receives current” to files or folders in Finder
3. Add a “Run Shell Script” action

Problem: The Pipeline Interruption

The first Automator attempt was similar to what I’d been trying to do with Shortcuts—It used an “Ask for Text” action to collect the password, followed by a “Run Shell Script” to do the zipping. The script received the password as $1 but the file paths were gone:

PASSWORD: astrongpassword
Number of files: 0

Automator’s actions form a linear pipeline, and “Ask for Text” consumes the input. By the time the shell script runs, the file paths have been replaced by the password string.

Restructuring the workflow to capture file paths first didn’t cleanly solve the problem either, because passing them through subsequent actions got messy.

The Solution: osascript for the Password Dialog

The cleanest fix was to skip Automator’s “Ask for Text” action entirely and use a single “Run Shell Script” action that shows a native password dialog using osascript:

#!/bin/zsh

# Show a native password dialog
PASSWORD=$(osascript \
  -e 'Tell application "System Events" to display dialog "Enter encryption password:" default answer "" with hidden answer' \
  -e 'text returned of result')

for INPUT in "$@"; do
    INPUT="${INPUT%/}"
    PARENT_DIR=$(dirname "$INPUT")
    BASE_NAME=$(basename "$INPUT")
    TMPOUT="/tmp/${BASE_NAME}.zip"
    FINALOUT="${PARENT_DIR}/${BASE_NAME}.zip"

    cd "$PARENT_DIR" && zip -r -e --password "$PASSWORD" "$TMPOUT" "$BASE_NAME"
    mv "$TMPOUT" "$FINALOUT"
done

This approach:

• Uses osascript to show a proper native macOS dialog with a hidden (password-style) input field
• Keeps everything in a single action, so the file paths arrive cleanly as $1, $2, etc. via "$@"
• Writes the zip to /tmp first (sidestepping any write permission quirks) then moves it to the final destination
• Loops over all inputs, so it works if you select multiple files at once

Installation

Save this Automator workflow via File → Save, give it a name, and then it’ll be saved automatically to ~/Library/Services/. It appears immediately in Finder’s right-click Quick Actions menu, there’s no additional configuration needed.

Lessons Learned

The Shortcuts sandbox is still too restrictive when it comes to shell scripts accessing files in TCC-protected directories like the Downloads folder—More restrictive than I’d expected given that I had granted Full Disk Access to Shortcuts. For a Quick Action that needs to read arbitrary files from the filesystem, Automator is the better choice. Shortcuts excels at chaining native macOS actions, but the moment you need a shell script to touch files, you’ll likely hit a wall.

Automator’s pipeline model has its own quirks (the “Ask for Text” interruption problem being a good example), but osascript is a powerful escape hatch that lets you show native UI from within a shell script, keeping the entire workflow in a single action and avoiding pipeline issues altogether.

Despite this being my first time using Automator, the final workflow was quick to set up. Shortcuts clearly seems to be the direction that Apple is moving in, but given it’s shortcomings, let’s hope they don’t get rid of Automator any time soon.

System Data and OmniDiskSweeper

Sunday, July 27, 2025 • 3 min read

Recently when checking my Mac’s storage usage, I noticed that the System Data category had ballooned to over 250GBs. Even with 1TB of storage, this seemed excessive and I wanted to get the the bottom of what was taking up so much space.

After some research online, I learned that I had many prior versions of Xcode simulators sitting around that were no longer available to be used. These were easily pruned, and doing so freed up a dozen or so gigabytes of space, but not nearly enough to make much of a difference in the reported amount of of disk space belonging to System Data.

Next, I took a look at local Time Machine snapshots. I didn’t really want to mess with these, but I did find that deleting some large and no longer needed files that were sitting on my drive also helped reduce the size of these snapshots. Nevertheless, I still had over 200GB devoted to System Data.

I continued by looking through my ~/Library folder and its many subdirectories, convinced that the reason for the bloat must be found there, but the numbers just weren’t adding up. Finally, I tried installing OmniDiskSweeper after seeing it recommended a few times during my online searches. I ran it and within a few minutes it had indexed all of my directories and organized them more or less by size.

At first I wasn’t sure what to do with this information, because I still didn’t know what was safe to delete. But soon I saw something that I hadn’t before—OmniDiskSweeper was showing a hidden com.apple.podcasts directory within my ~/Library folder. That directory in turn had a tmp folder with many snippets of previously-streamed podcast episodes. Over 100GB worth of snippets, in fact.

I know enough about stream buffering to know that generally speaking, the way it works is that small 15 second or so pieces of a larger stream are downloaded ahead of time. The snippets I found were undoubtably of this nature, which is why they were found in such an obscure location. What still isn’t clear to me, however, is why over a year's worth of these segments were kept on my disk well after the episodes they belonged to had been listened to, deleted from the podcasts app, and otherwise forgotten.

I deleted all 100GB of these old podcast snippets and restarted my Mac. I’m happy to report that after doing so, I'm now consistently only seeing ~90GB devoted to System Data. That still feels like more than necessary, but it’s a major improvement.