Data handling
It runs entirely on your own machine. Your code, tickets, and credentials stay local to the Engine process; only what a workflow explicitly sends to an AI provider or to Jira/Bitbucket/GitHub/etc. ever leaves it.
Running a workflow sends real content — ticket descriptions, PR diffs, code, comments — to whichever AI provider (Claude or Cursor) you’ve configured, via their own API, using your own API key. Knoflows itself stores your credentials locally via your OS’s own secure credential store; it doesn’t transmit them anywhere except to the provider they belong to.
The settings screen also offers DeepSeek as an agent provider. A workflow sends content to whichever agent instance the step is configured to use.
Where the engine stores data
Section titled “Where the engine stores data”The engine stores its SQLite database, the encrypted-secrets fallback, and the default worktree root in one directory:
| System | Path |
|---|---|
| macOS | ~/Library/Application Support/knoflows |
| Windows | %LOCALAPPDATA%\knoflows\Data |
| Linux | $XDG_DATA_HOME/knoflows, or ~/.local/share/knoflows when XDG_DATA_HOME is unset |
The database file is kno.db. KNOFLOWS_DATA_DIR (an absolute path) isolates an install, including its keychain entries. KNO_SQLITE_PATH overrides only the database file.
npm uninstall -g @knoflows/engine removes the program only. It does not delete the database, the secrets fallback, or OS keychain entries. knoflows purge (before uninstall) and knoflows secrets prune are the cleanup commands.
kno mcp exposes views and jobs to an MCP client such as Claude Desktop or Cursor. A registered MCP server is reachable from every conversation in that client. Ticket titles, PR details, and job state can surface whenever the model decides a tool matches. Prefer --readonly when you only need lookup. Tool-call approval is the connecting client’s responsibility; this server does not add a second approval layer.