BinSync syncs decompiler artifacts through a Git repository

Git is the transport, and that is the whole idea

BinSync is described as a decompiler collaboration tool built on the Git versioning system, and the repository title calls it a reversing plugin for cross-decompiler collaboration. The choice of Git as the substrate is what makes it work across decompilers, because Git does not care what the tool that produced the diff is. Each decompiler plugin turns the state of the binary into a set of text artifacts, those artifacts are committed to a Git repository, and a teammate in a different tool pulls the same files and applies them to their own session. The upstream origins are worth knowing because they explain the design. BinSync is built by mahaloz, the angr team, and the SEFCOM research lab, and the README says it is also due in large part to its use by the Shellphish hacking team. A tool shaped by CTF and academic reverse engineering tends to assume a fast moving team with many analysts, which is exactly the situation where a shared binary and divergent notes become expensive.

Reverse Engineering Artifacts are the unit of exchange

All good decompilers share common objects called Reverse Engineering Artifacts, and the README states plainly that these REAs are the center of BinSync's syncing ability. The supported list is short and specific. Function headers with symbol, args and type. Stack variables with symbol and type. Structs. Enums. And comments. The note that all types support user-created types like structs matters more than it first appears, because a struct definition is usually the piece of knowledge that lets three different functions be read correctly, and a type that cannot carry user defined types would flatten that into a loss. The distinction between the artifact categories is also a hint about how the data is modelled. A function header is a structured tuple that can be compared field by field, a comment is free text, and the framework has to reconcile those into a single diff model that can be applied on the other side. The Git repository therefore holds a normalised representation, not a decompiler database.

Install is one command, and the decompiler side needs a host process

The installation is described as best done with the two-part installer with Python:

pip3 install binsync && binsync --install 

The second half is what makes the cross-decompiler story work, since a decompiler plugin has to run inside the decompiler's own process, and on Windows that generally means a Python host process that the decompiler launches. BinSync is also available in the Binary Ninja plugin manager, which removes that step for one of the supported tools. Two conditions are easy to miss. If you plan on using BinSync with Ghidra you must launch it in PyGhidra mode, which is the Ghidra side of the same arrangement. And if you plan on using the extra features, such as the ChatGPT User, the package installs differently, with pip3 install binsync[extras] to pull in the additional packages for support. For developers the package is installed editable with the -e flag, and pip needs to be at version 23.0.0 or newer. The dependencies in pyproject.toml make the shape visible, with declib for the decompiler library abstraction, GitPython and filelock for the repository side, and prompt_toolkit and tqdm for the interactive parts.

Support is complete in IDA, near complete in Binary Ninja, partial in Ghidra

The support tables are the most useful part of the documentation, and they set expectations honestly. The README says that although the decompilers in the earlier section are supported, not every decompiler is supported at the same level of syncing, and points to a decompiler use introduction for the difference between artifact support, pull, push and auto push. For IDA Pro the table is full across the board: symbols, types, pull, push and auto push all carry check marks for function headers, stack variables, global variables, structs, enums and comments. Binary Ninja is the same except for the auto push row, which is unmarked. The Ghidra table is truncated in the README itself, and the prose is blunt about it. Ghidra support is still very much in early stage, so only expect the minimal features like artifact name syncing and comments. The four verbs matter. Support is about whether a decompiler can express an artifact at all, pull is about fetching, push is about publishing, and auto push is about publishing without being asked. A decompiler where auto push is missing still works, it just means someone has to press the button.

Version floors, and the four supported platforms

The supported platforms section gives explicit minimum versions, which is the first thing to check before planning a rollout. IDA Pro 8.4 or newer is required, and if you have an older version the README directs you to BinSync v4.10.1 as a specific commit rather than a release, which tells you the older path is a frozen point. Binary Ninja needs 2.4 or newer, angr-management needs 9.0 or newer, and Ghidra needs 12.0 or newer with PyGhidra mode. Every version requires Python 3.10 or newer and Git installed on your system, so a workstation without Git is out regardless of the decompiler. The version list in the packaging metadata is narrower than that, with classifiers for Python 3.10 and 3.12 only, so a 3.13 or 3.14 environment is not claimed to be tested. The release history shows the project in active maintenance with v5.15.4 on 2026-08-21, v5.13.3 on 2026-07-16 and v5.15.2 on 2026-06-07, and the last push was on 2026-08-31. The licence is BSD-2-Clause, and the repository is not archived.

Where the collaboration model breaks down

The limitations follow from the design rather than from missing features. First, the transport is a Git repository, so every teammate needs repository access and the ability to resolve a conflict, and a conflict in a shared artifact is a conversation rather than an automatic merge. A function header that two analysts changed differently is a genuine semantic disagreement, not a textual one, and no versioning system resolves that for you. Second, the artifact set is fixed. If a team relies on information that is not in the list, such as a specific rename, a recovered stack offset or a note about a decryption routine, that knowledge stays in one tool, and the sync will not carry it. Third, the uneven decompiler coverage means a mixed team, one analyst in IDA and one in Ghidra, gets a much narrower shared view than a team that has all settled on one tool, which is a different reason to pick the same decompiler. Finally, the Ghidra path is explicitly immature, so a team that has standardised on Ghidra will find the collaboration story thin and may need to carry notes by hand as well. The Discord server linked in the README is where the project points for that kind of help.

Editorial conclusion

Adopt BinSync when two or more analysts work the same binary at the same time and your decompiler is IDA Pro or Binary Ninja, since those two have the fullest artifact coverage. Do not adopt it for Ghidra collaboration beyond names and comments, because that support is described as still in an early stage. Verify first that your decompiler version meets the stated floors, that Git and Python 3.10 or newer are present on every machine that will take part, that Ghidra is launched in PyGhidra mode if you use it, and that the repository you sync into is one you are willing to have rewritten by a pull from a teammate.

Frequently asked questions

Official sources

1. binsync/binsync on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases