MindFS: a self-hosted gateway to your AI agent sessions and workstation files

The gap MindFS fills between a terminal agent and a phone

CLI coding agents are built around a terminal. Claude Code, OpenAI Codex, Gemini CLI and the rest run in a shell, write into a working directory, and keep their session state in their own format. That is fine at a desk and awkward everywhere else: you cannot check whether a long task finished from a phone, and you cannot hand a colleague a link to the file the agent just produced.

MindFS positions itself as an "AI Agent Remote Access Gateway" with "Result Visualization", per the README. The audience is narrow and specific: people who already run one or more of the supported agent CLIs on their own workstation, and who want a browser in front of that workstation. It is not a hosted agent platform. It does not supply models. It sits between your existing agent processes and a web UI, and it also exposes the filesystem and a long-lived shell alongside them.

The supported list in the README is long: Claude Code, OpenAI Codex, Gemini CLI, Grok, Cursor, GitHub Copilot, CodeBuddy, Cline, Augment, Kimi, Kiro, Qwen, Qoder, OMP, Pi, Hermes, DeepSeek Harness (DSH), Reasonix, OpenCode and OpenClaw. The README states installed agents are detected automatically, so the practical question is not which ones are listed but which ones are present on your PATH.

How sessions, files and shells are wired together

The repository layout tells you more about the architecture than the feature list does. There is a Go backend under server/, a CLI entry point under cli/, a web front end under web/, and separate android/ and harmony/ directories for mobile builds. The go.mod file shows the transport and storage choices: go-chi for HTTP routing, gorilla/websocket for the browser channel, hashicorp/yamux for multiplexed streams, and modernc.org/sqlite, a pure-Go SQLite implementation with no cgo requirement.

That last detail matters for the single-binary claim. A pure-Go SQLite driver means the build does not need a C toolchain, which is consistent with the README's statement that the production build is a statically compiled binary with all web assets embedded and an install package under 10 MB. The go.mod also contains replace directives pointing the codex-go-sdk and acp-go-sdk modules at the maintainer's own forks, which is worth knowing if you plan to build from source and audit dependencies.

For agent integration, the presence of coder/acp-go-sdk points at the Agent Client Protocol as one integration path, alongside per-agent SDKs such as claude-agent-sdk-go and codex-go-sdk. The README describes the resulting behaviour: token-by-token streaming to the browser, tool calls and permission prompts rendered as collapsible cards, remaining context-window capacity shown live, and a persisted mapping between a MindFS session and the underlying agent session so follow-up messages continue on the same agent session after a restart. Data defaults to a per-project .mindfs/ directory, with an option in the sidebar to place metadata for new projects under ~/.mindfs/<rootId>/ instead. An existing project-local .mindfs/ is always reused, so the choice is not retroactive.

Installing MindFS and running a first session

The README's installation section describes the production path as a single binary with no Node.js, Docker or daemon manager required on the host, built for macOS (Intel and Apple Silicon), Linux (x86-64, ARM64, ARMv7) and Windows (x86-64, ARM64). The README does not give a package-manager command, so where you obtain the binary is a question for the project's release page rather than something to guess at here.

If you build from source instead, the Makefile is the entry point. Its help target lists the available goals, and the dev target runs the CLI with an address flag:

make dev

The Makefile defines ADDR with a default of :7331, so make dev starts MindFS on that port. The equivalent explicit form, using the CLI entry point the Makefile invokes, is:

go run ./cli/cmd -addr :7331 .

After startup, the README says local mode is accessible in the browser on the local machine immediately, with no account or configuration needed. Open http://localhost:7331, and the agent list should reflect whichever supported CLIs are installed on the machine. The Makefile also exposes make build for compiling web assets plus the CLI binary, make install to place the binary and static assets under PREFIX (which defaults to $(HOME)/.local), and make start to run with built static assets rather than the Vite dev server. For backend-only work, make dev-backend runs server/cmd/mindfs-server on the same default address.

Remote access, and where the trust boundary actually sits

The README describes four access modes, and they are not equivalent from a security standpoint. Local mode is browser access on the same machine. Private channel means putting MindFS on a private network such as Tailscale and reaching it directly at ip:port. Relay remote mode routes traffic through an encrypted tunnel via a9gent.com, activated by a bind button in the local UI, and requires no inbound firewall port. End-to-end encryption is offered as an option for sessions and files.

The distinction that deserves attention: local mode and the private channel keep traffic inside infrastructure you control, while Relay mode introduces the project's relay service into the path. The README describes the tunnel as encrypted and the site as a9gent.com, and it offers end-to-end encryption as a separate capability. Whether that combination satisfies a given threat model is not something the README argues; it states the modes and leaves the judgement to you. If your agent sessions touch proprietary source, decide deliberately between the private channel and the relay rather than accepting the default because it is one click.

The same section of the README mentions one-click exposure of local services to a public domain name in Relay mode. That is a genuinely useful capability and also the single most consequential thing in the product: it turns a local port into something reachable from the internet. Treat the exposure configuration as production infrastructure, not as a convenience toggle.

Where MindFS is the wrong tool

MindFS assumes a persistent workstation. Sessions, files and the long-lived shell all live on the host running the binary. If your agents run in ephemeral containers that are destroyed after each job, there is nothing stable for the gateway to attach to, and the session persistence and recovery described in the README lose their point.

The single-user model is the second constraint. The README describes self-hosted data, per-project directories and a bind button for relay access, but nothing about accounts, roles or per-user isolation. If several people need to share one agent environment with separate permissions, MindFS does not present itself as the layer that provides that.

Third, the mobile and notification story has conditions the README states plainly. Notifications arrive via Web Push on session status changes, and the README notes iOS requires adding the page to the home screen first. The PWA path avoids an app store, but it is still a browser install with the platform limits that implies. Finally, the README's installation section is thin on distribution: it describes the artifact and the platforms but does not give a package-manager command, so verifying a download or a build is on you.

MindFS compared with plain tmux over SSH

The obvious alternative for many readers is not another product but the setup they already have: SSH into the workstation and attach to a tmux session. That approach costs nothing, adds no dependency, and works from any terminal, including a phone terminal app. It keeps the agent's native interface, which some people prefer to a re-rendered one.

The difference in approach is what each layer chooses to understand. tmux multiplexes a terminal; it has no idea that a line of output is a tool call, a permission prompt or a context-window counter. MindFS parses the agent protocol, which is why the README can promise structured collapsible cards, session search across conversation content, session forking from historical replies, and bidirectional import between external agent CLI sessions and MindFS sessions. It also explains why the supported-agent list is finite: each integration depends on an SDK or protocol the project has implemented, not on terminal output alone.

What you give up in the trade is the terminal's universality. tmux works with any program that writes to a tty. MindFS works with the agents it supports and with the file and command surfaces it implements. If your workflow depends on an agent that is not on the list, the gateway adds nothing.

Maintenance, licensing and what upgrading costs

The repository is not archived, and the last push was on 2026-08-20, which is recent enough that the project is being worked on. Release cadence is visible in the release list: v0.4.7 on 2026-08-13, v0.4.8 on 2026-08-18, and v0.4.9 on 2026-08-20. That is a fast patch rhythm at the 0.4.x stage, which usually means the surface is still moving. The Makefile includes verify-release, which checks a signed release manifest and artifacts in DIST_DIR, and publish-release-notes, which commits and pushes release-notes.md when it changes. Those targets suggest a deliberate release process rather than ad hoc tagging.

The upgrade cost is concentrated in two places. First, the session mapping between MindFS sessions and underlying agent sessions is persisted, and the README describes recovery after service restarts. Any change to that mapping in a new version is the kind of thing that can strand existing sessions, so read release-notes.md before upgrading rather than after. Second, agent SDKs move independently of MindFS. The go.mod pins specific versions and uses replace directives for two SDKs, so an agent CLI update can outpace the gateway's integration.

On licensing: the repository is AGPL-3.0. The practical consequence is that if you modify MindFS and let other people interact with it over a network, the licence's network-use condition is likely to apply to your modified version. Running it privately for yourself raises a different question than shipping it inside a product. This is not legal advice, and the LICENSE file in the repository is the authority.

Editorial conclusion

Adopt MindFS if you already drive Claude Code, Codex or a similar CLI agent on a machine you control and want its sessions, files and shell reachable from a phone or another browser. Skip it if you want a hosted multi-tenant service or if AGPL-3.0 obligations do not fit how you distribute software. Before committing, verify three things: that the agent CLI you use is detected on startup, that your project directory's .mindfs/ layout matches what the README describes, and whether you need Relay mode or whether a private network on ip:port is enough.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes