Sticking to OmniAutomation means it will not break when OmniFocus changes its storage, at the cost of some rough edges the README names outright: a created task returns a temporary id, tag assignment is limited to tags that already exist, and moving a project between folders has constraints. Project ids are alphanumeric, so look them up with list_projects rather than typing a number.
An OmniFocus server built on OmniAutomation, the official scripting interface, rather than by reading the database. It filters tasks and projects, creates and updates them, and caches read results so a follow-up question does not re-query the app.
- list_tasks — filter by completion, flag, project, tags, dates and search terms, including inbox and availability, with pagination metadata
- get_task_count — the same filters returning only a count, when you do not need the tasks themselves
- create_task — a task in the inbox with note, flag and due or defer dates; tags must already exist
- update_task — change name, note, flag and dates, or move a task to another project or back to the inbox
- complete_task and delete_task — close a task out or remove it
- list_projects — filter by status (active, on hold, dropped, completed), flag and folder
- create_project — a project with note, dates, flags and a parent folder, creating the folder if it does not exist
- update_project — change name, note, status, dates and flags
- complete_project and delete_project — mark a project done or remove it
- Task reads are cached briefly and project reads for longer, so repeated queries return quickly
macOS with OmniFocus 3 or later, and Node.js 18+. Clone the repository, install and build, then point the client at the built entry file. On first use macOS asks for permission to control OmniFocus. LOG_LEVEL controls logging verbosity.