I’ve vibe-coded a fully functioning HTTP server for Logseq’s CLI. This was just meant to be a proof of concept after a discussion I had with @danzu, who came up with the idea, but it turned into a two-week project, and I now have it running full time on my computer. The idea is simple: Logeq DB has a command line interface that duplicates many features of the previous API, so why not replace the API with this so that other apps can talk to your database even when the application (or a specific graph) is not running?
This fixes a problem I’ve long had with tools like Logseq Copilot (a browser search plugin that surfaces Logseq search results as you search the web), which is that they would often not work because the API wasn’t running.
It isn’t perfect; the current implementation doesn’t have all the features of the API, like the ability to write to the graph, and the CLI isn’t always showing the latest version of your data (you have to “save” updates with cmd-S if you make changes while it is running). But it works well enough that I was able to make my own fork of Logseq Copilot, which I’m calling Logseq Sidekick that uses the new HTTP CLI server. It is far stripped down from the original plugin, but meets my needs. (And works with Logseq DB.)
More importantly, this is really a proof of concept, intended to encourage other people to build on my work. As I said, this is all vibe-coded with Claude Code, and so I can’t promise it will work or that things won’t break. @danzu did test it, and it worked on his computer after he restarted the browser. But don’t expect much in the way of customer support! Also, you have to be somewhat comfortable in the command line to get everything installed and working. I’m not planning on putting it in the Chrome Extension Marketplace.
On macOS the server has a launch agent and will run in the background. There is a little AppleScript to control it, I might later upgrade this to a menu-bar app if I am motivated to, but don’t hold your breath. On other systems it should theoretically work in the terminal, but I can’t promise anything as I’ve only tested it on macOS.
Anyway, for those who are interested in playing around, here is a link to the server:
I was able to create a Raycast Extension that uses the same logic to search Raycast. (Note, I have it designed to only return page results. You can fork it if you want blocks as well.)
Interesting. I just noticed that there’s an MCP server that utilizes the CLI, so it can also be run independently from the Logseq desktop software. Out of curiosity, since this is not evident to me, what’s your use case for it? (Instead of using a LLM chat UI, for example.)
I’m still on the old Logseq, and I’m contemplating on whether to stay or migrate. The CLI (and the integrations that come with it) is certainly a selling point for the DB version!
The server has been updated to work with version 0.4.0 of the CLI which had some breaking changes. It will no longer work with older versions of the CLI.
Sorry for being vague, I meant more like a user story, but never mind, perhaps it’s self-evident to you when to use a launcher search and when to use other tools instead…
The tools I’ve made just search page titles, so they work with stuff that I’ve already marked out manually as the kind of stuff I want to search for. For instance, if I have a page “Heikki” tagged as a contact, I just want to open that page up quickly. My tools help me do that. Or remind me that I have a page which I’ve forgotten about.
An MCP is a tool that can help you identify material that might not be obvious, or to organize that material in new ways. For instance, I keep all my article annotations in Logseq, but have not tagged them that extensively - that is where more sophisticated tools can help.
UPDATE: The HTTP server is no longer necessary, since the new version of the CLI is headless. In other words, it no longer requires Logseq to be running.
I have not yet updated the search sidekick for the new CLI…
Great work with the sidekick concept. I saw your update about the shift to headless workflows—this is exactly where the local-first ecosystem needs to go for AI integration.
Since you mentioned you haven’t updated your tools for the headless CLI yet, I just released Matryca (matryca-logseq) on PyPI, which might be the perfect foundation for what you are trying to achieve. It is a 100% pure headless MCP server and CLI companion designed specifically for Logseq OG (Markdown graphs).
Unlike read-only wrappers, Matryca provides a full read/write data plane built for modern AI workflows (Claude Desktop, Cursor, Claude Code). I engineered it to solve two major pain points:
Safe Headless Writes: It implements OS-level file locking (fcntl.flock) and atomic file swaps. External agents can safely write or refactor pages on disk even if the Logseq desktop app is actively open, with zero race conditions.
Context Token Economy (X-Ray Mode): It dynamically squashes long 36-character block UUIDs (id:: ...) into dense, tiny positional aliases (like [0], [1]), reducing context window token bloat up to 35x.
ok, thanks for your reply.
It will be nice if you can give it a try to have also your feedback, because it’s really simple to use with questions in natural language, dialoguing with your Logseq graph.
