# flowix and its habit of not reading stdin on Windows

> A Markdown notebook that treats your notes as the memory an agent reads and writes back into, shipped as a Tauri desktop app with an MCP server and a DeepSeek Harness plugin. The most instructive part is the CLI input contract, where implicit stdin was removed specifically to stop PowerShell corrupting non-ASCII text.

**text2future/flowix** — Notes for you, Memory for your agents. / 内置 Deepseek harness Agent / 适用 办公 & 写作 & Coding

- Repository: https://github.com/text2future/flowix
- Website: flowix.cc
- Stars: 445 · Forks: 57
- Language: TypeScript
- License: MIT
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/text2future-flowix

## The note is both the input and the output

The whole idea fits in one loop: write in Markdown, point an agent at the context it needs, and save the result back to the same note, ready to review, edit and reuse next time. That last clause is the part that separates this from a chat window with a file picker. The note is not read-only input that the agent summarises into a different place, it is the document the agent edits, so the artifact you keep is the artifact the work happened in. The framing is notes for you and memory for your agents, and the stated categories are Markdown, open source, multi agent, MCP and CLI. The documentation describes four places this is meant to pay off: product work where requirements, feedback, decisions and PRDs stay current, software development where a coding agent can continue a project, research where sources and conclusions remain reusable, and personal knowledge where notes and preferences become agent context. The getting started path is four steps and deliberately unremarkable: download and install from the website, create a new local folder or register an existing one as a notebook, create a document and write down the task background, reference materials, goals and constraints, then either call an agent from inside that document or keep organising with tags and properties. The repository carries both an English and a Simplified Chinese README, and one HTML comment in the English file records a Codex write-access test dated 2026-09-10, which is a small sign of an agent already being pointed at this repository. The loop is asymmetric in a useful way: the note accumulates. Each pass leaves the background and constraints you wrote next to what the agent concluded and changed, so a note that started as a task description becomes the context for the next session without anyone maintaining a separate summary.

## Windows stdin is never read unless you ask for it

The most specific engineering decision in the repository is a negative one. Passing Markdown through a file is the recommended route to create and write, described as especially important from Windows PowerShell 5.1, because piping text through stdin risks damage from the pipeline's encoding:
```powershell
flowix create <notebook> --file body.md --json
flowix write <id> --file body.md --json
```
The behaviour that caused this is now gone: on Windows, stdin is no longer read implicitly when neither input option is given, which removes the path where PowerShell 5.1's $OutputEncoding could corrupt non-ASCII text before it reached the CLI. Callers who can guarantee UTF-8 on stdin opt in deliberately:
```powershell
$OutputEncoding = [System.Text.UTF8Encoding]::new($false)
Get-Content -Raw -Encoding UTF8 body.md | flowix create <notebook> --stdin --json
```
The two options are mutually exclusive, and the file path is read directly as UTF-8, where a file may carry a BOM or omit one. A missing, unreadable or invalid UTF-8 file returns an error rather than empty content, and with --json the failure uses a stable shape of ok false with an error object holding a code and a message, so scripts can branch on the code instead of parsing prose. The two subcommands differ in what they address, since create takes a notebook while write takes an existing id, and both accept either input option plus --json, so the same calling convention covers making a new memo and revising an old one.

## The Harness plugin is local only, and it needs the CLI on PATH

Agent access is delivered as an MCP tool, and one integration ships as a DeepSeek Harness plugin. dsh-flowix-memory connects any Harness agent to your local Flowix notes through the bundled flowix-cli MCP server, and what the agent receives is a single tool named mcp__flowix__memo that can search, read, create and edit memos, including mind maps. Installing it takes one command:
```sh
dsh plugin --profile flowix add ./dsh-flowix-memory
```
Two caveats are stated plainly. The plugin is not yet published to npm, so the path is a local directory and you add it from a flowix-main checkout rather than a registry. And it has runtime requirements beyond the plugin file: the flowix CLI has to be on your PATH, or you set FLOWIX_CLI_PATH instead, and that CLI needs access to your notebook data under ~/.flowix. Outside the Harness flowix is just an ordinary custom profile name, so the same convention works for other clients in that family. A sibling directory named dsh-appserver sits next to dsh and dsh-flowix-memory in the root, and the visible documentation does not explain what that appserver does, so the plugin story here is one piece of a larger harness arrangement rather than the whole of it.

## Sharing is scoped to a note, a folder, or a notebook

The privacy model is a scoping decision rather than a promise. Notes are plain Markdown files on your device, which means you can open them in anything, and three levels of access are offered: share a single note, a folder, or a whole notebook, and only when you want an agent to use it. Alongside that you choose when context is sent and how the files are synced, backed up or versioned, using tools you already trust, and the documentation is explicit that there is nothing to export because there is no proprietary store to get the data out of. Agents can be the ones inside Flowix or external ones, with Codex, Claude Code, OpenCode and Hermes named, along with any other MCP or CLI tool. The visible product surface matches that story: a note library with tags, a note detail view with agent presets, an agent model picker, full-text and file search, provider and MCP configuration, and code file browsing and editing. Longer documentation lives at a docs path on the company's own site rather than in this repository, and the per-note agent presets and the model picker are what make the sharing decision concrete, since the model an agent runs with is chosen next to the note you chose to share.

## The build runs four checks and pins the package manager

package.json is unusually defensive about how the project gets built. The web build is not just tsc and vite: build runs the TypeScript compiler, then vite build, then node scripts/check-web-bundle.mjs, so a bundle check is part of producing the output rather than an optional extra. Four sibling scripts exist for the same kind of guardrail, check:layers, check:package-manager, check:frontend-debt and check:web-bundle, each a small node script of its own. The package manager is pinned to npm 10.8.2 with the packageManager field, and there is a dedicated check script for that pin, so a contributor arriving with a different npm is caught by a command instead of by a diff. Testing splits along the language boundary: test runs vitest, test:rust runs cargo test against the workspace lib in app/Cargo.toml, and test:dsh:packaging runs node's own test runner over the native dependency script. A clean target removes the build output directories in one line, and a package verification script exists as well, though its definition is cut off in the visible manifest. The package is marked private and declared as an ES module, so nothing here is published to a registry under this name. Two details about the shape of the script list are worth noting: the web bundle check exists both as a standalone target and as the last step inside build, so it runs whether you invoke it directly or not, and the development build of the CLI is a separate script that passes a debug flag rather than reusing the production one.

## Building the desktop app needs Rust and Tauri too

The development path is a Tauri application, not a plain web app, and the clone and run sequence shows both halves:
```bash
git clone https://github.com/text2future/flowix.git
cd flowix
npm install

npm run tauri dev
npm run dev
npm run tauri build
```
The stated toolchain is Node.js 20 or newer, Rust 1.75 or newer and Tauri v2, and the desktop app supports macOS 14 or newer and Windows 10 or newer. That combination of a Tauri shell and a Node build is why the script list is long: there are separate build targets for the CLI, including a macOS-specific variant, and a matrix of dsh targets covering dev, production, macOS and Windows builds plus packaging for prod, Windows and local, and a publish step. There are also separate Tauri dev entry points for the default configuration and for Windows, and release:updater runs a bash script, which is the one place in the chain that assumes a Unix shell. Note what the supported list does not include: the desktop targets are named as macOS and Windows only, with no Linux entry anywhere in the requirements, so the Unix shell assumption in that script is a contributor-side detail rather than a sign of a supported platform. The two dev entry points also differ in what they start: the plain dev script runs vite for browser-only work, while the tauri dev script drives the desktop shell through its own development configuration, with a separate Windows configuration file for the Windows case.

## The root holds three harnesses and one stray entry

The file layout explains the product better than the feature list does. Alongside the expected app, docs, scripts and config files, the root contains dsh, dsh-appserver and dsh-flowix-memory, which is the DeepSeek Harness side of the project living in the same repository as the desktop app rather than in a separate package. Agent-facing instruction files sit there too, AGENTS.md and CLAUDE.md, next to CONTRIBUTING.md and lefthook.yml for commit hooks, plus a .flowix directory whose contents are not explained in the visible documentation. There is an examples folder containing a plain-report example, and one root entry is literally named with a dash, which is the kind of artifact that comes from a mistyped command rather than a design decision. Two small mismatches are worth checking before you rely on either: the manifest says version 1.5.0 while the most recent tagged release listed is v1.4.6, and the repository homepage is flowix.cc while the README links everything to flowix-memo.com. Release history is short and recent, with v1.4.6 on 2026-09-20, v1.2.2 on 2026-08-23 and v1.2.1 on 2026-08-17, the last push landed on 2026-10-01 on the main branch, the repository is not archived, and licensing is a single MIT file at the root covering the whole project. The front end is conventional underneath all of it, with postcss and tailwind configs, a vite config, a vitest config and separate tsconfig files for the app and for node-side code, plus a docs directory whose contents are not visible from the repository listing.

## Conclusion

It fits someone whose notes already live as Markdown and who wants an agent to read a folder and write its answer back into the same note, since nothing has to be exported to make that happen. It does not fit a team that needs shared or synchronised notes, since sync is deliberately left to your own tools, and it does not fit anyone without Rust who wants to build from source. Before you install the DeepSeek Harness plugin, read its README, because it is not on npm yet, must be added from a local checkout, and needs the flowix CLI on your PATH or FLOWIX_CLI_PATH set.

## FAQ

### How do I install Flowix and start using it?

Download and install it from the website, then create a new local folder or register an existing folder as a notebook. Building from source instead needs Node.js 20+, Rust 1.75+ and Tauri v2.

### Why does the flowix CLI ignore stdin on Windows?

Stdin is no longer read implicitly when neither input option is given, so PowerShell 5.1's $OutputEncoding cannot corrupt non-ASCII text. Callers with guaranteed UTF-8 stdin opt in with --stdin, and --file and --stdin are mutually exclusive.

### What does the dsh-flowix-memory plugin give an agent?

A single mcp__flowix__memo tool to search, read, create and edit local Flowix memos, including mind maps, delivered through the bundled flowix-cli MCP server. It requires the flowix CLI on PATH or FLOWIX_CLI_PATH set.

### Where does Flowix keep my notes?

As plain Markdown files on your device, with notebook data under ~/.flowix according to the plugin documentation. You share a single note, a folder or a whole notebook, and only when you want an agent to read it.

### Do I have to export my notes from Flowix to back them up?

No. Sync, backup and version control are left to the tools you already trust, precisely because the notes are ordinary Markdown files rather than data held in a proprietary store.

## Sources

- [Issues](https://github.com/text2future/flowix/issues)
- [License: MIT](https://github.com/text2future/flowix/blob/main/LICENSE)
- [README](https://github.com/text2future/flowix/blob/main/README.md)
- [Releases](https://github.com/text2future/flowix/releases)
- [text2future/flowix on GitHub](https://github.com/text2future/flowix)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/text2future-flowix