CommandPost: an Automator for video editors, written in Lua

A Mac app that exists to make an editor faster

CommandPost is described in one line as workflow enhancements for creatives, and it is a completely free and open source Mac application that lets you speed up your creative editing process through customisable automation tools. The README compares it to Automator, but for editors.

The focus is currently Apple's Final Cut Pro. The plan is to eventually add functionality for other tools used daily, such as Adobe After Effects and mocha Pro, and it is important to read that as a plan rather than as current coverage, because the documentation describes those as things the project intends to add.

The origin story explains the design. It started as a small proof of concept to make finding the Final Cut Pro browser playhead easier for Scott Simmons, and has since grown into a large collection of professional workflow tools and automation features. The stated ambition with the plugin architecture is to build an open platform where editors worldwide can easily create and share useful tools, so that everyone can get home earlier and spend less time in front of a computer.

That plugin architecture is the actual product. CommandPost is not a fixed set of shortcuts; it is a host that runs third-party extensions, and the value for most users is the extension someone else already wrote.

The primary language is Lua, the licence is MIT, the default branch is develop, and the homepage is https://commandpost.io. The recent releases are 2.1.0 on 2026-08-11, 2.0.5 on 2026-02-20 and 2.0.4 on 2026-02-10.

Extensions and plugins, loaded from two different places

The Makefile in the repository root is the clearest description of the plugin architecture, because it is the script that switches between the two loading modes.

In development mode, the devscripts target writes an MJConfigFile preference pointing at the source tree, and echoes that CommandPost will load extensions and plugins from the GitHub folders under src.

devscripts: $(PLUGIN_PATH)
	@defaults write $(BundleID) MJConfigFile "${PWD}/src/extensions/init.lua"
	@echo "CommandPost will load extensions and plugins from GitHub '${PWD}/src' folders."

In application mode, the appscripts target deletes that preference, and echoes that CommandPost will load extensions and plugins from the bundled sources.

appscripts:
	@defaults delete $(BundleID) MJConfigFile
	@echo "CommandPost will load extensions and plugins from the bundled sources."

So the plugin host reads a macOS preference to decide where its code comes from. That single preference is what lets a plugin author point the running application at a working copy of a plugin, and it is why a developer and an end user run the same binary.

The path constants tell you the layout on disk. Application Support holds a CommandPost directory, with Extensions and Plugins subdirectories, and the bundle identifier org.latenitefilms.CommandPost also has its own directory. Preferences live in a plist under the same bundle identifier, and the caches list shows the app writing to several places, including the Fabric SDK cache, Crashlytics and an NSURLSession downloads directory.

The Makefile is also the uninstaller

The remaining Makefile targets are about removal, and they are the part of this repository that is most unusual to find in a project like this.

The trashprefs target deletes the preferences file for the bundle identifier and removes it from disk, with the echo message that it is trashing CommandPost Preferences. The trashsupport target is meant to trash the application support directory, and although the two rm lines for the paths are commented out in the Makefile, the target and its message are there. The trashcaches target iterates over the cache paths and removes each one.

trashprefs:
	@echo "Trashing CommandPost Preferences..."
	@defaults delete $(PREFS_FILE)
	@rm $(PREFS_FILE)

The reason a build file carries an uninstaller is the plugin model. Extensions and plugins are loaded from Application Support, so uninstalling the application does not remove the things other people wrote for it, and the preferences file may point the app at a source tree. Leaving those behind means a reinstall picks up a state the user did not expect.

The build prerequisites are declared at the top of the Makefile as a list of executables required to run it, namely defaults, luarocks, unlink and busted, and the file errors out if any of them is missing from PATH. LuaRocks is the package manager for the Lua side, and busted is the test framework; the Makefile does not explain what unlink is for. There is a test target that runs busted --help, and the.luacheckrc in the repository root is the configuration for the Lua linter.

The build expects a specific set of tools and a writable Application Support

The Makefile header is worth reading as a specification of what a contributor needs, because it is stricter than a typical list of dependencies.

The shell is set to /bin/bash, and the required executables are checked with a foreach that errors out with a message naming the missing tool. The install paths are then derived rather than hardcoded. APP_SUPPORT_PATH is the user's Library/Application Support directory, CP_PATH is the CommandPost directory inside it, and the bundle identifier directory BID_PATH and the Extensions and Plugins subdirectories are derived from the same base. Preferences go to a plist in the user's Preferences folder under the bundle identifier.

The check is worth noting for a different reason. It means the build fails early and clearly if luarocks is missing, rather than later with a confusing error inside a Lua require. For a project whose plugin ecosystem is distributed through LuaRocks, that dependency is not optional.

The scripts/ directory at the repository root holds the build and packaging scripts, and the appcast/ directory holds update metadata, since the download is a Mac application rather than something you install from a package manager. There is an uninstall/ directory, and the docs/ directory is the documentation source that feeds the developer guide online.

The default branch being develop, with releases cut from it, is a common arrangement for a project whose branch stays ahead of the last tag. The last push was on 2026-08-11, the same day as release 2.1.0, so the two are in step.

Where CommandPost is the wrong tool

There are three limits, and the first is a platform limit rather than a design choice.

The first is that it is Mac only and Final Cut Pro only today. The platform badge in the README says MacOS, and the Final Cut Pro focus is stated plainly, with After Effects and mocha Pro named as plans. If your editing happens elsewhere, there is nothing here for you. Even on a Mac, a workflow that spans two applications gets no cross-application automation from this tool, because the plugin host is scoped to one application.

The second is the plugin trust problem, and it is the interesting one. The whole premise is that a community writes extensions and other editors install them, but a plugin is code running inside the editor with access to everything the editor can do. The repository layout shows that the plugin directory sits inside Application Support next to the extensions, and that a single macOS preference can redirect the whole host to a different source tree. That is exactly what makes plugin development pleasant, and it is also why a careless install of a plugin from an unknown author is a supply-chain decision rather than a preference.

The third is that the value depends entirely on the extension ecosystem, and the README describes that ecosystem as something the project aims to grow rather than something it guarantees. The first proof of concept solved one narrow problem, finding the browser playhead, and the collection of tools grew from there. That trajectory tells you the coverage is uneven, and that a workflow nobody has written an extension for stays manual. The project also asks for sponsorship to stay free and open source, which is a reasonable arrangement but does add a dependency on continued interest from users who want it to keep going.

For comparison, macOS Automator and Hammerspoon cover overlapping ground in different ways. Automator is what the project compares itself to, and it is general purpose with no Final Cut Pro knowledge baked in. Hammerspoon, which appears among the repository's topics, is the other Lua-based tool worth knowing about here.

Editorial conclusion

Adopt CommandPost if you edit in Final Cut Pro and keep hitting the same repetitive keystrokes, since a community extension already exists for most of those. Do not adopt it if you work in After Effects or mocha Pro today, because the documentation names those as plans rather than shipped support. Before you install, read the Developer Guide on installation and usage, and note the last push was on 2026-08-11 with release 2.1.0 the same day, so the develop branch is where the work happens.

Frequently asked questions

Official sources

1. CommandPost/CommandPost on GitHub
2. License: MIT
3. Project website
4. README
5. Releases