The word "fork" needs two records.
Mitos calls itself a Helix fork. Its README names Helix commit f9928f57f as the branch point and says the repository keeps the full upstream history.[1] The GitHub repository API currently reports fork: false for mitos-editor/mitos.[2]
Those facts can coexist. Git history records ancestry. A hosting platform's fork flag records how that platform classifies the repository. Inventory tools that trust one field can miss the other. Save the named branch commit, verify that it exists in both histories, and record the platform relationship separately.
Lineage answers "where did this begin?" Migration proof answers "can this replace my current route?"
Compare behavior, not feature nouns.
Helix documents modal editing, multiple selections, built-in language-server support, and tree-sitter syntax work.[3] Mitos keeps that selection-first base. Its first release adds spell checking, image previews, a quicklist, changed-file picking, breadcrumb navigation, and custom commands. It also changes the terminal interface, default themes, executable name, and configuration paths.[4]
A feature checklist hides the expensive part. Test one real edit with several selections. Open a project that needs a language server. Run a formatter. Use the debugger if it matters to your work. Compare the exact command, state, output, and recovery on both editors.
Configuration does not follow the binary by magic.
Mitos uses ms as its executable. Its user configuration lives under ~/.config/mitos on Unix-like systems and %AppData%\mitos on Windows. Project configuration uses .mitos/. The release notes also call out a keymap rename from replace to replace_char for custom mappings.[4]
Keep the old and new configuration roots separate during evaluation. Copy only the settings you understand. Record rejected keys and changed defaults. Do not turn a clean startup into a compatibility verdict.
The package exists. We did not run it.
We fetched the immutable Mitos 0.1.0 x86_64 Linux archive from its GitHub release. The file measured 20,090,740 bytes, contained 2,068 entries, and had SHA-256 804667c815dccf7829d45d4c9c26093ff0d0228c09de0d4386f7bc41edc3171f. The archive included ms, a license, shell completions, runtime queries, compiled grammar libraries, a tutor, and a README.[4]
We listed the archive without installing or executing it. This proves that those bytes were distributed under that release. It does not prove installation, language-server behavior, debugger behavior, terminal compatibility, or safe runtime behavior.
Do not invent the fork motive.
The Hacker News thread asked what Mitos does differently. One commenter suggested Helix's draft Steel plugin pull request as a possible motive, then labeled that suggestion as speculation.[5] The Mitos README and 0.1.0 release notes do not make that causal claim.
There is a real connection at the code level. Mitos's release notes credit several Helix pull requests for adapted work, while its repository names the branch commit and license. That is enough for a useful lineage story. A motive needs a statement from the people who made the fork.
Run the transfer before changing muscle memory.
- Pin the old editor revision, the fork revision, and the common ancestor.
- Keep separate configuration and runtime directories.
- Replay a small file, a real project, and one failure case.
- Record changed keys, commands, theme names, and external tool requirements.
- Keep the old launch command and configuration intact until the new route passes your workload.
The transfer rail below drafts that test packet. Its completed state means the packet has all four sections. It does not mean the editor passed them.