Wechatsync: A Chrome Extension That Publishes One Article to 29+ Chinese Platforms

The copy-paste tax Wechatsync is trying to remove

Anyone who publishes in Chinese runs the same loop: write once in the WeChat editor or a Markdown file, then paste the same body into Zhihu, Juejin, CSDN, Toutiao, Jianshu, Xiaohongshu and a self-hosted blog. Each platform has its own editor, its own image handling and its own idea of what a code block looks like. Wechatsync targets that loop directly. The README frames the audience in four groups: self-media operators distributing a WeChat article, technical bloggers pushing to developer communities, independent bloggers pulling traffic from WordPress or Typecho, and people generating text with an AI assistant who then need somewhere to put it.

The scope is broad by design. The platform table lists 29+ targets, including finance sites (Xueqiu, Eastmoney), product communities (woshipm), video-adjacent surfaces (Bilibili columns, Douyin image posts) and overseas ones (X). Hexo and Hugo are handled differently: not through an API adapter but by downloading a Markdown ZIP, which is the honest way to serve static site generators. If your distribution list is mostly Chinese consumer platforms, that coverage is the reason to look at this project rather than a generic cross-poster.

Why there is no server: cookies, official APIs and drafts

The README is explicit that Wechatsync is not a crawler and does not simulate login. It is a Chrome extension running with your session. When you publish, it reads the cookies your browser already holds for each platform and calls the same web API that platform's own editor calls. The stated data flow is browser to platform, with no intermediate server and no upload of account data. That architecture has a real consequence: the extension can only act where you are already logged in, and it inherits whatever session state the browser has, including expired cookies.

The second design decision is draft-first. According to the README, articles are synced as drafts by default and a human confirms before anything goes live. For a tool holding live publishing credentials across two dozen accounts, that is the right default, and it also means Wechatsync is not a scheduler. It will not post at 9am while you sleep. The repository layout matches the description: a pnpm workspace with packages/extension (Manifest V3), packages/mcp-server, packages/cli and packages/core for shared logic. The root package.json shows the build split into build:extension, build:mcp and build:cli, and requires Node >=20.0.0.

Installing the extension and running your first sync from the CLI

The README gives two install routes for the browser extension. The recommended one is the Chrome Web Store listing, which auto-updates. The manual route is to download the latest release ZIP, unzip it and load it as an unpacked extension. Chromium-based browsers are listed as supported: Chrome, Edge, 360 and QQ.

For scripted use, the README points at the CLI and says it is the simplest path because no MCP configuration is needed. It installs globally from npm:

npm install -g @wechatsync/cli

Before the CLI can do anything, the README says you must install the Chrome extension and enable the MCP connection in the extension settings to obtain a token. That token is then exported as an environment variable:

export WECHATSYNC_TOKEN="你的token"

With the token set, the documented sync command takes a Markdown file and a comma-separated platform list. The README uses zhihu, juejin and csdn as the example targets:

wechatsync sync article.md -p zhihu,juejin,csdn

Two more CLI commands are documented. One lists platforms together with their login state, which is the first thing to run when a sync silently fails. The other extracts the article from the page currently open in the browser and writes it to a file:

wechatsync platforms --auth
wechatsync extract -o article.md

Expect drafts, not live posts. If a platform does not appear as authenticated, log into it in the same browser profile before retrying.

The MCP path, and the token mismatch that will bite you

The more interesting integration is the Anthropic MCP server. The README documents building the project with pnpm build, enabling the MCP connection in the Chrome extension settings, setting a token there, and then registering the server in the Claude Desktop config file at ~/.claude/claude_desktop_config.json. The config points at packages/mcp-server/dist/index.js and passes the token through an environment variable:

{
  "mcpServers": {
    "sync-assistant": {
      "command": "node",
      "args": ["/path/to/Wechatsync/packages/mcp-server/dist/index.js"],
      "env": {
        "MCP_TOKEN": "your-secret-token-here"
      }
    }
  }
}

The README flags one requirement in bold: MCP_TOKEN must match the token set in the Chrome extension. That is the whole authentication model, and it is also the most likely failure point, because the two values live in different applications and neither side validates the other at startup. The exposed tools are list_platforms, check_auth, sync_article, extract_article and upload_image_file. Note the wording on sync_article: it syncs to the specified platforms as a draft. There is also a Claude Code plugin path through a marketplace add and plugin install, and an OpenClaw skill installed with clawhub install lljxx1/wechatsync.

Where Wechatsync breaks, and what it is not

The dependency on unofficial platform web APIs is the structural weakness. Those interfaces change without notice, and the changelog shows the maintenance burden plainly: v2.0.7 lists re-adapting Jianshu, Yidian and Sohu; v2.0.8 fixes CLI sync format problems and improves bridge reconnection stability. Nothing in the repository suggests a contract with any of these platforms, so an adapter can stop working at any time and the fix arrives whenever a contributor writes it.

There is also a versioning problem worth naming. The GitHub releases listed are 1.0.10, 1.0.9 and 1.0.8, all from 2021, with 1.0.10 dated 2021-04-28. The README's changelog, by contrast, runs through v2.0.9 dated 2026-03-24. The default branch is v2 and the last push was on 2026-05-27, so work is happening, but the release page does not reflect it. Anyone who automates against GitHub release artifacts is looking at five-year-old code.

Finally, the architecture rules out whole categories of use. There is no headless server mode: the extension needs a real logged-in Chromium session, so a cron job on a VPS is not a supported shape. The README does not document rollback after a sync, and it does not describe rate limits or retry behaviour per platform. If you need scheduled publishing, delivery guarantees or a queue with retries, this is the wrong tool.

How it differs from Artipub and the hosted multi-platform tools

The related searches around this project point at Artipub, Yixiaoer and MultiPost Extension, and the difference in approach matters more than any feature list. Artipub is a self-hosted service: you run a server, it holds the platform credentials, and publishing happens from that server rather than from your browser. That gives you scheduling and a headless pipeline, and it also means your session cookies live in a process you operate. Wechatsync inverts this. It keeps credentials inside the browser profile that already has them and accepts the constraint that a browser must be open and logged in.

Hosted tools such as Yixiaoer take the opposite trade again: no local setup, but your content and account relationships pass through someone else's infrastructure, and the README's central claim about Wechatsync is that this does not happen. The GPL-3.0 licence reinforces the same posture: the source is auditable, and derivative distributions carry the same obligations. For a tool that touches publishing credentials for two dozen accounts, local-only execution is the strongest argument in its favour, and it is also the reason it cannot be scheduled.

Licence, upgrade cost and what the repository actually guarantees

Wechatsync is GPL-3.0. If you use it as an end user, that is unremarkable. If you fork the extension or the CLI and distribute it, the copyleft terms apply to the distributed work, and any adapter you write inside the packages/ tree inherits the same licence. The README links a contributor guide for adapters at docs/adapter-spec.md, so the intended path for adding a platform is a pull request rather than a private fork. This is not legal advice; read LICENSE before shipping a modified build.

Upgrade cost is uneven across the three surfaces. The Chrome Web Store build updates itself, and the README says so. The manual ZIP does not, so a user on the manual route has to re-download and reload. The CLI comes from npm as @wechatsync/cli and follows normal npm versioning. The MCP server is the awkward one: the documented setup builds from source and points the client config at an absolute path inside your clone, so upgrading means pulling the v2 branch, rebuilding with pnpm build, and restarting the MCP client. There is no documented version negotiation between the extension and the MCP server, which is why the token check and a matching rebuild are the two things to confirm after any update.

Editorial conclusion

Adopt Wechatsync if you already publish from a Chromium browser into Chinese platforms and want drafts, not automatic posts, and if a GPL-3.0 extension inside your browser is acceptable. Do not adopt it if you need a headless server-side pipeline with no logged-in browser, or if you depend on the GitHub release tags, which stop at 1.0.10 from 2021 while the README describes 2.0.9. Verify first that the Chrome Web Store listing or the manual ZIP installs cleanly on your Chromium build, that the MCP token in the extension settings matches MCP_TOKEN in your client config, and that each target platform still accepts the adapter, since the changelog shows platforms being re-adapted after breaking changes.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. wechatsync/Wechatsync on GitHub