notion-search-alfred-workflow: Notion quick find inside Alfred

What the workflow actually calls

The workflow is described as an Alfred workflow to search Notion.so with instant results. The behaviour is stated plainly: type your keyword into Alfred, default keyword ns, and you get instant search results from Notion that mimic the Quick Find function in the Notion webapp. Pressing enter on a result takes you to that page in Notion in your default browser or the Notion app, and holding Cmd and pressing enter copies the url to your clipboard.

The important detail is how it gets the results. It does not use the Notion public API, and it does not use a personal access token. The setup instructions tell you to open the Notion webapp, open the browser developer tools, look at the Network tab, and find a request called search. You copy the cookie value from the request headers and the notionSpaceId from the request payload, and paste both into the workflow as variables.

So the workflow is a thin client for the same internal endpoint the webapp calls, authenticated with the same session cookie your browser holds. That is why the results match Quick Find exactly, including the things Quick Find can find and a search box cannot.

The repository layout confirms the shape of the implementation. There is a notion.py at the root, a payload.py for the request body, a searchresult.py for the result model, an info.plist which is the Alfred workflow definition, an emojiicons directory, and the screenshots referenced by the README. The primary language is Python, and there is a README for the Alfred 4 build alongside a separate repository for Alfred 5.

The audience is a specific and identifiable group: someone who keeps their notes in Notion, uses Alfred as their launcher on macOS, and is willing to do a little setup work in exchange for not switching applications to find a page.

The variables that decide what you see

The workflow variables are where the behaviour is configured, and the defaults are sensible enough that most people change almost nothing.

There are three required values. The cookie is needed for your Notion token, notionSpaceId is your organisation identifier, and useDesktopClient defaults to False and determines whether to open Notion links in the desktop client rather than the web app.

Then there are the ones the README recommends leaving alone unless you are confident. isNavigableOnly defaults to False, and it controls whether you can search objects within a page, that is Notion objects that cannot be found through the left hand side navigation pane. Setting it to True only returns results reachable through the navigation pane, and as a side effect it removes subtitles from the Alfred search results. That is a genuine trade, since the richer results come from the wider search.

enableIcons defaults to True and toggles support for Notion icons shown natively in the Alfred results, with custom Notion icons downloaded on demand. iconCacheDays defaults to the recommended value of 365 days for the best performance and defines how many days custom icons are cached, with a minimum of 0 and a maximum of 365. And showRecentlyViewedPages defaults to True, which controls whether recently viewed pages appear when you provide no query, with the caveat that a user id in the supplied cookie is needed for the API call that lists them.

That last caveat is the one to remember. The recently viewed feature needs a user id in the cookie, and the Safari workaround described in the setup instructions, where you copy only the token_v2 value, will not have one. So a Safari user gets search but not the recents list.

Getting the cookie and space id out of the browser

The setup step is the awkward part of this project, and the documentation is unusually detailed about it, which tells you how many people have hit friction here.

The recommendation is to use Chrome. You visit the Notion webapp, open developer tools with View in the toolbar, then Developer, then Developer Tools, and select the Network tab. You type something into the quick find search bar, and a request called search appears. The cookie value is in the request headers, and the notionSpaceId is in the request payload.

If you can only use Safari, the instructions say to copy the token_v2 value and populate the cookie variable so it looks like token_v2=XXXXXXXXXXXX, and they note that this means the recently viewed pages feature will not work for you. The trade is explicit: a Safari user can search but loses the recents panel.

The cookie value in the documentation looks like a long string of analytics and session cookies, of which only one part matters:

notion_browser_id=1bcfbfb9-e98c-9f03; logglytrbckingsession=eb1c82cb-fd; bjs_bnonymous_id=%22bdbf1088-b33c-9bdb-b67c-1e; _fbp=fb.1.12821; intercom-id-gpfdrxfd=b61ec62d-; token_v2=b39099...

The space id is a single identifier in that shape:

celcl9aa-c3l7-7504-ca19-0c985e34ll8d

There is a known issue worth knowing about. Some users have had trouble copying these values straight out of developer tools, and have had better results copying and pasting them into TextEdit or another text editor first, which probably strips out problematic formatting. That is a small detail that saves an afternoon.

Once you have the values, you install the workflow by downloading the appropriate release and double clicking it, then click the [x] icon in the upper right corner of the workflow in Alfred and fill in the matching variable fields.

Optional SVG icon rendering and the Apple silicon problem

Most of the setup is the cookie. The optional part is the icon rendering, and it has a known rough edge on modern Macs.

The workflow needs Python 3. Many people will already have it, and if not, running python3 from a Terminal window prompts the installation of the Xcode CLI tools, which include Python. A more detailed guide is linked for anyone who wants it.

The optional dependency is cairosvg, which allows svg icons to be shown in Alfred search results. It is installed with pip3 install cairosvg, and it needs the cairo library, which with Homebrew is brew install cairo. The README is relaxed about this, saying that if you have not used homebrew before you may want to skip the optional step or install homebrew.

The rough edge is Apple silicon. The documentation records that there seems to be an issue with cairosvg on apple silicon and gives a fix, at your own risk, that worked for the author:

brew install cairo pango gdk-pixbuf libxml2 libxslt libffi
sudo mkdir /usr/local/lib/
sudo ln -s /opt/homebrew/lib/libcairo-2.dll /usr/local/lib/libcairo-2.dll
sudo ln -s /opt/homebrew/lib/libcairo.so.2 /usr/local/lib/libcairo.so.2
sudo ln -s /opt/homebrew/lib/libcairo.2.dylib /usr/local/lib/libcairo.2.dylib

That fix is worth understanding before you run it. It creates symlinks from the Intel Homebrew path in /usr/local/lib to the native arm64 libraries in /opt/homebrew/lib, so a program looking for cairo in the old location finds it. The net effect is that a 64-bit-only workflow can load the cairo shared library, which is why the symlink has to point at the dylib rather than at the .dll name, which is a Windows convention that happens to be the file name Homebrew uses here.

The alternative is to accept the default behaviour, which is that icons are not rendered as SVG in Alfred results. Everything else about the workflow works without it. That is a reasonable trade for a search utility, and it is why the README frames the whole thing as optional.

The Alfred 4 build is frozen, and where to get the current one

The most important practical fact about this repository is that you probably should not install from it.

The README opens with a notice: please only use the Alfred 5 version of this workflow, as found below, because the Alfred 4 version has not been updated with the latest bug fixes and will not receive these updates in the future. The Alfred 4 version will not receive further updates. The current version lives in a separate repository, wrjlewis/notion-search-alfred5-workflow, with its own releases.

This repository is the Alfred 4 build. The listed releases are v0.6-alfred4 from 2023-09-02, v0.5.3-alfred4 from 2023-06-16 and v0.5.2-alfred4 from 2023-06-02, and the repository is not archived with the last push on 2026-04-08. So there has been some recent activity on the old branch, but no tagged release since 2023 and no commitment to more.

The version split matters more than it might appear, because Alfred 5 changed how workflows are distributed and how some script filters behave, and a workflow that was built for Alfred 4 is not automatically compatible with the newer Alfred. Downloading the release for your version of Alfred is the instruction, and the two download links at the top of the README point at the matching repository for each.

For anyone evaluating the project as a dependency, the practical conclusion is that you should look at the Alfred 5 repository, not this one. This repository is worth reading because it is where the documentation, the variable explanations and the setup guidance live, and much of that carries over.

The licence is GPL-3.0, with the LICENSE file at the repository root. That is worth a thought for a workflow that reads your notes: the code is copyleft, but the more relevant question is the data, since the workflow transmits your search queries and the contents of your workspace to Notion through your own session cookie, using the same endpoints the webapp uses.

What it is for, and what to use instead

The scope is narrow and the tool is good at it. If your notes live in Notion and you search for them dozens of times a day, moving from a Cmd+Space query to an instant result list is a real saving, and the recents panel removes the need to remember where a page lives.

Three additional features round it out. There is pre-configured support for OneUpdater for automatic version updates, which is a small thing that matters for a workflow you install once and never look at again. There is the recently viewed pages view, reached by typing ns with no query. And there is nsn to open a new Notion page, which currently only supports the web app.

The limitations are worth being concrete about. The authentication is a browser session cookie, so it can expire or be invalidated by a Notion login, and the workflow has no way to refresh it. The result set is whatever the internal search endpoint returns, which is not the same as the full Notion API surface. The desktop client is only used for opening links, and the new page command is web app only. And the whole thing is macOS only, since Alfred is.

The alternatives differ in what they cost you. The official route is Notion's own desktop app with its quick find, which is free, needs no cookie, and works on Windows and Linux as well, at the cost of switching to another application and losing the launcher integration. Alfred's own web search with a Notion URL, if you can live with opening the browser and searching there, requires no credentials at all.

A more capable option is a tool built on the official Notion API rather than a scraped session, which gives you a stable authentication model and a documented surface, at the cost of more setup and the fact that the official API does not expose the same global quick find search.

The honest summary is that this workflow trades stability of authentication for fidelity of behaviour. If your Notion usage is occasional, use the official app. If it is your primary notes system and you live in Alfred, the friction of one cookie paste is worth it, and the recents panel is what tips it.

Editorial conclusion

Adopt this workflow if you use Alfred on macOS and want Notion page search without switching to the web app or the desktop client, and you are comfortable pasting a session cookie into a workflow variable. Do not adopt it if your workspace is governed by a policy that forbids using session credentials outside the official client, and skip the Alfred 4 build entirely, since the README states it receives no further updates. Verify first that the token_v2 cookie you copied is still valid, that your space id resolves to the right workspace, and that the results you expect are reachable through the search endpoint rather than only through the navigation pane.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. wrjlewis/notion-search-alfred-workflow on GitHub