wechatdataanalysis: the public build reads, the paid build writes, and the manifest calls the frontend React while the build calls it Nuxt

The public build reads, and the writing is sold separately

The readme splits the product in two, and only one half is here.

The regular version is described as focused on decryption, reading, exporting, and an annual summary, all read-only capabilities. The advanced version is described as adding sixty-one write, action, and automation features covering message modification, message back-filling, messaging actions, moments synchronisation and interaction, group and contact management, and scheduled tasks.

Then the sentence that matters: the publicly released version shows only the feature descriptions and demonstration animations, and does not include the execution implementation of the advanced features. Using them requires the advanced build matched to your client version.

The acquisition route matches that division. It is not a purchase link but a chat group number, with the instruction to message the group owner privately. A separate group is offered for discussion at the bottom of the file.

So the honest scope statement is this: what you can audit is a decryptor, a reader, an exporter, and a summariser. Everything that acts on a live account is documented as a feature list and delivered outside the repository.

The package, the app, and the frontend all have different names

Three names are in play and the packaging section is where they collide.

The project calls itself a WeChat database decryption and analysis tool. The distribution package in the manifest is named for a decryption tool, not for the application. And the manifest's own one-line description ends by saying the frontend is React.

The build instructions say otherwise. The packaging step for both desktop platforms is described as automatically running a static-site generate step, copying static assets, packaging the backend, and then producing the installer, and the generate step it names is for a different framework than the one in the description.

There is also a sibling project. The readme points readers who need the equivalent for a different messaging platform to another repository, and notes that the author of that one is also a developer on this one. That is unusual disclosure, and it explains part of the name drift: two projects, one team, one of them on a different name.

The root also carries a mail identity mapping file, which in a repository like this usually means the commit history contains more than one identity for the same person.

Dependencies are pinned by platform, so two builds run different engines

The dependency list is long, and the pinning is inconsistent in a way that is worth reading carefully.

Four styles sit side by side. Most entries carry a lower bound. A group of agent-framework packages are capped below their next major version. A group of model and inference packages are pinned to exact versions with no range at all. And two of those exact pins are split by platform, with different versions for macOS and everywhere else, plus a comment explaining that the macOS pin selects the CPU build because it is the one that ships wheels for both processor generations on that platform version.

So a Windows install and a macOS install of the same package run different versions of the same inference engine, deliberately, and neither can drift.

That discipline is worth praising and it has a cost. The exact pins mean a security fix in any of those packages requires a release of this project, and the platform split means the two platforms are not testing the same engine.

Five of the dependencies are restricted to Windows, including a process-inspection library, a Windows key library, a binary-parsing library, a cross-compilation toolchain library, and a rule engine. So the decryptor path is a Windows path, and the macOS support in this repository is for the desktop app and a separate key-extraction helper.

The backend refuses an editable install and prints where its own code came from

The source-run instructions contain the most specific engineering note in the file, and it exists because of a path problem.

The backend dependency install is a single command with a flag that explicitly means do not install the project in editable mode:

uv sync --no-editable

The justification is written in the paragraph that follows: the entry point puts the current repository's source directory ahead of any installed package, and prints at startup where the code it is running came from. A development run is supposed to point at the repository's own copy of the package rather than an older copy sitting in the virtual environment's site-packages directory.

Then two more constraints in the same paragraph. On Windows, with non-ASCII paths, do not switch to an editable install, because a specific interpreter version may read a generated path file using the system code page and fail to start. And the runtime entry point is launched with the no-sync flag for the same reason.

Also here: the port numbers. The frontend runs on one port, the API on another, the API documentation route on the API port itself, and the API port is overridable by an environment variable.

Two other services must be started separately for a full development run, and the desktop mode is described as the one that works directly on both supported desktop platforms.

Two download sources, and a mirror that may send you back to the original

The model download section is written with more care than most readme sections of this length get.

There is a setting for the download source, switchable between the official host and a domestic mirror. The default is the official host, the choice is saved and reused for later downloads started from the model list, and downloads already in progress keep the source they started with. After a connection timeout you can change the source and retry the download from the model's button.

The honest part is the next sentence. Under some networks the mirror issues a redirect to the official host, and the application follows that permanent redirect, so you may end up at the original anyway. The mirror's own availability still depends on your network.

So the feature is not really a mirror, it is a fallback list. That is a reasonable design for a feature that downloads hundreds of megabytes of model weights, and it is worth noting that the setting is described as being in a speech-to-text submenu even though the same local retrieval section separately pins a model version for semantic search.

There is also a small protocol surface: the settings page exposes an endpoint and a bearer token as a copyable prompt for connecting an external assistant to the local service.

The readme lists its own failure modes, including account warnings

The disclaimer is longer than the installation guide, and the fourth of its points is the one to read.

The first point establishes the relationship: an independently developed, unofficial, open-source tool, with no affiliation, authorisation, cooperation, or endorsement from the messaging platform or its parent company, whose product names and trademarks belong to their rights holders. The second restricts it to data the user lawfully holds, manages, or has explicit authorisation to access, and adds compliance with applicable law, software licences, platform rules, and privacy obligations.

The third is the practical one. The process may involve local databases, keys, chat records, media files, the running client process, and system interfaces. Back up important data, keys, and configuration before starting, and take responsibility for key custody, data security, and privacy yourself.

The fourth is the risk statement, and it names the mechanisms: client version changes, memory scanning, hooking, third-party components, and other local processing may cause account warnings, lost functionality, failed processing, file anomalies, or other unexpected results. And there is no promise of compatibility with future client versions.

The fifth point is provided as-is, with no guarantee of accuracy, completeness, or stability, and the sentence carrying that guarantee stops there.

Four Python files sit at the root, and one of them is a test

The root listing explains the project's shape better than the introduction does.

There is one entry point, and then four more Python files beside it that are tools rather than package modules: one that analyses databases, one that handles the key, one that scans, and one that generates a configuration template. Then a separate directory for extracting the key on macOS, so the key step has its own home on the platform where it needs one.

Then the projects. A source directory holding the actual package, a frontend directory, a desktop directory wrapping the frontend and the backend, a documentation directory, a website, a tools directory, and a skills directory. That is five separate trees for one application, which explains the packaging section's mention of a static-site generate step, an asset copy, a backend packager, and an installer builder, all chained from one command.

And one file that does not belong: a test module sitting at the repository root while a separate tests directory exists beside it. Alongside it are a design quality document and a third-party notices file.

For a project shipping a decryptor, a reader, an exporter, a summariser, a desktop shell, a website, and an agent-facing protocol, that is a coherent tree with one stray file in it.

Editorial conclusion

Read this before anything else: the project is an independent tool with no relationship to the messaging platform, and it states three times that it is for data you lawfully hold, that you should keep your decryption key to yourself, and that it does not promise compatibility with future client versions. Then read it as what it is. The public build decrypts, reads, exports, and summarises; the sixty-one features that write back into a live client are documented, priced separately, and not in this repository. If you need a searchable archive of your own messages, that is what you are getting.

Frequently asked questions

Official sources

1. Issues
2. LifeArchiveProject/WeChatDataAnalysis on GitHub
3. Project website
4. README
5. Releases