# Teamtype: peer-to-peer collaboration for local files

> Teamtype is a Rust-based, editor-agnostic system for synchronizing local directories in real time. It fits pair programming, brainstorming, and shared note editing, while the README still documents known bugs and a project maintained in contributors' free time.

**teamtype/teamtype** — Peer-to-peer, editor-agnostic collaborative editing of local text files.

- Repository: https://github.com/teamtype/teamtype
- Website: https://teamtype.github.io/teamtype/
- Stars: 1,944 · Forks: 57
- Language: Rust
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/teamtype-teamtype

## What Teamtype changes for local editing

Teamtype addresses a specific gap between conventional version control and live collaboration. Teamtype connects local directories so that multiple users can edit text concurrently through their own editors. The README gives pair programming, brainstorming, and note-taking as examples, which makes the intended audience fairly clear: developers and note-takers who want a shared working directory without moving their work into a hosted editing service.

The project is editor-agnostic rather than tied to one editor interface. The README lists a Neovim plugin, a VS Code/Codium marketplace extension, and community integrations for JetBrains IDEs and TeXstudio. This matters because collaboration can remain associated with the editor and file layout already used by the participants. The repository contains `nvim-plugin/` and `vscode-plugin/`, while the documented plugin development guide describes a simple JSON-RPC protocol for additional integrations.

Teamtype is also explicitly local-first. The README says that content remains on disk and that users retain local access when offline. That is a different operating model from a cloud document editor: the files remain the working copy, while Teamtype handles synchronization between peers. The project says its peer-to-peer connections are encrypted and that no server is required. The README does not document the discovery mechanism, relay behavior, or complete key-management workflow, so those parts of the architecture should not be inferred.

## Directory sharing and peer connection flow

The documented workflow starts from the directory that contains the files to share. One participant starts a session with `teamtype share`. The command prints a join code, such as `5-hamburger-endorse`, and then reports a connected peer. A second participant moves to another directory and uses that code with `teamtype join`. The join output states that the peer address is stored in `.teamtype/config`, after which the two directories are connected.

That data flow explains why Teamtype is directory-oriented rather than a single-file service. The share side establishes a session and advertises an address through the join code, while the join side derives a peer from the code and records its configuration locally. Once connected, the README says that changes are synced instantly. The repository topics identify Automergе, CRDT, local-first, synchronization, and peer-to-peer as core areas, so the implementation is associated with conflict-free replicated data types. The README does not document the exact merge algorithm or the file-event sequence used by the daemon.

The editor plugin sits on top of that synchronization layer. It can expose peer cursors, selections, and edits in real time, according to the feature list. The exact mapping from an editor buffer to the files on disk is not specified in the README, so adopters should not assume that every editor operation behaves like a filesystem write. Directory behavior and plugin synchronization are areas that need validation with their particular editor and file layout.

## Installing Teamtype and sharing a first directory

The README supports binary releases and several package managers. For a first installation on a supported Unix-like system, Cargo can install the published crate. The documented command is below. It uses the locked dependency set declared by the project.

```bash
cargo install --locked teamtype
```

After installation, install the editor integration. The README lists Neovim through the separate `teamtype-nvim` repository and the Teamtype extension for VS Code/Codium. Then open a terminal in the directory to share and start the session:

```console
teamtype share
```

The command should print a join instruction containing a code. Give that code to the other participant, who should run the join command in a separate directory. The example below uses the code shown in the README, so its value is illustrative rather than a fixed session code.

```console
teamtype join 5-hamburger-endorse
```

The README indicates that `join` stores peer information in `.teamtype/config`. Both directories can then be opened in editors with Teamtype support. The first useful check is to edit a text file in one directory and confirm whether the other editor displays the change. The project documentation says that directories are now connected and that changes are synced instantly.

## Platform support, plugin boundaries, and Rust build constraints

Teamtype is not presented as a cross-platform native desktop application. The README lists Linux, macOS, Android, and Windows Subsystem for Linux as supported environments. Binary releases include `x86_64-linux-static`, `universal-apple-darwin`, and `aarch64-aarch64-linux-static` assets. For Android, the README specifically points to a terminal emulator such as Termux. Native Windows outside WSL is not listed in the installation documentation, so a Windows-only team should verify that omission before planning a deployment.

The workspace declares Rust edition `2024` and a minimum Rust version of `1.92.0` in `Cargo.toml`. This matters for source installs and development builds because an older Rust toolchain will not satisfy the declared project requirement. The workspace also includes `crates/teamtype` and `crates/e2e-tests`, which indicates that the repository contains more than a single command-line binary. The test profile enables optimization because the project documentation in `Cargo.toml` says the end-to-end fuzzer can time out without it.

The plugin boundary is useful but incomplete in the README. Neovim and VS Code/Codium are documented, and community projects cover JetBrains IDEs, TeXstudio, Emacs, Obsidian, web editors, and Kakoune. The README labels several of those as work in progress, so community availability should not be treated as a release guarantee. The JSON-RPC development guide may reduce the work for a new editor integration, but the README does not define authentication, reconnect behavior, conflict handling at the editor-buffer level, or protocol versioning.

## Where Teamtype is the wrong tool

Teamtype is the wrong choice when the main requirement is an audit trail, branch management, pull requests, code review, or reliable recovery of prior versions. Its README positions it as the real-time complement to Git, not as a replacement for version control. Concurrent editing and directory synchronization do not by themselves provide the review controls, commit graph, or explicit historical model associated with Git.

It is also a poor fit for a team that requires a centrally administered service. The project states that users do not need an account and that peer-to-peer connections do not require a server. That removes some operational dependencies, but the README does not establish a hosted control plane for identity, access policy, usage reporting, or organization-wide administration. There is no server-side account system described there.

Finally, the project itself says it is maintained in contributors' free time and that bugs remain to be aware of. That is an explicit warning against treating the current project status as a service-level commitment. The latest listed release is `v0.9.2` from 2026-07-08. The repository is not archived, and the last push was on 2026-10-15, but those repository facts do not remove the README's warning about unresolved bugs.

## Teamtype versus Git-centered collaboration

The clearest alternative described by the project is Git together with a conventional review workflow. Teamtype instead synchronizes the current contents of local directories in real time and displays peer presence through editor plugins. A team can use both, but they solve different layers of the problem.

 Teamtype is relevant when two people need to type into the same working files at the same time. The README explicitly calls Teamtype a real-time complement to Git, so the practical distinction is temporal collaboration versus historical version management rather than a direct replacement claim.

The README also links to other collaborative text-editing software, but it does not describe those projects' implementation details. Without independent documentation for each alternative, it would be misleading to claim that they use a particular transport, merge model, or plugin system. The defensible comparison is narrower: Teamtype emphasizes local directories, peer-to-peer operation, editor independence, and a JSON-RPC plugin boundary, while Git-centered collaboration emphasizes repository history and explicit review.

## Maintenance, licensing, and adoption boundaries

The repository is not archived, and the last push was on 2026-10-15. Recent listed releases include `v0.9.2` on 2026-07-08, `v0.9.1` on 2026-01-28, and `v0.9.0` on 2025-10-29. The README describes maintenance as work done in free time and says that bugs remain. That combination supports treating Teamtype as a project with recent repository changes without describing it as a service with guaranteed support.

The repository identifies its license as `AGPL-3.0-or-later`. The license has implications for distributing modified versions and for network use, but this article does not provide legal advice. Organizations considering an embedded or modified Teamtype distribution should review `LICENSE.md`, the applicable notices, and their own obligations before shipping it. The README contains documentation under CC-BY-SA-4.0, while the repository includes `LICENSES/` and `REUSE.toml`, so checking the relevant files is more precise than assuming every file carries the same terms.

For a pilot, the first verification target should be practical interoperability: run `teamtype share` and `teamtype join` with the intended editor plugin, observe edits and peer presence, then inspect `.teamtype/config` and the local directory state. This project is most compelling when the team values a local working copy and direct peer connection more than centralized administration or repository-style review.

## Conclusion

Adopt Teamtype when a small group needs live collaboration over local text files without a central server or account. Do not choose it as a replacement for Git history, review workflows, or environments requiring a production service-level commitment. Before adoption, verify the current editor plugin, directory synchronization, connectivity path, and the implications of AGPL-3.0-or-later for your distribution model.

## FAQ

### How do I install Teamtype?

The README documents `cargo install --locked teamtype`, package-manager options such as `brew install teamtype` and `sudo pacman -S teamtype`, and precompiled release assets. It also requires a compatible editor plugin, including the separate `teamtype-nvim` plugin or the VS Code/Codium Teamtype extension.

### How do I start and join a Teamtype session?

Run `teamtype share` in the directory you want to collaborate on. The README shows the command producing a join code, which another participant can pass to `teamtype join <code>` in a separate directory.

### Does Teamtype require a server or an account?

The README says Teamtype uses encrypted peer-to-peer connections and does not require a server. It also says users do not need to create accounts.

### Can Teamtype synchronize an entire directory?

Yes. The feature list explicitly says that Teamtype can collaborate on entire directories rather than only individual files. The README's basic workflow starts the commands from the directory to be shared.

### Can I write a Teamtype editor plugin?

The README points to an editor plugin development guide and describes a simple JSON-RPC protocol. It also lists existing or community integrations for Neovim, VS Code/Codium, JetBrains IDEs, TeXstudio, and other editors.

## Sources

- [License: AGPL-3.0](https://github.com/teamtype/teamtype/blob/main/LICENSE)
- [Project website](https://teamtype.github.io/teamtype/)
- [README](https://github.com/teamtype/teamtype/blob/main/README.md)
- [Releases](https://github.com/teamtype/teamtype/releases)
- [teamtype/teamtype on GitHub](https://github.com/teamtype/teamtype)

---

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