qiye45/wechatVideoDownload: a Windows-side WeChat Channels downloader that watches traffic, not the app

What qiye45/wechatVideoDownload is for, and who actually needs it

WeChat Channels (视频号) plays video inside WeChat. There is no download button, no export, and no share sheet that hands you the file. The repository qiye45/wechatVideoDownload exists to close that gap on a desktop: it captures the media that WeChat fetches while you browse, and writes it to local disk. The README describes four targets: 视频号视频 (regular channel videos), 直播回放 (live replays), 直播 (live streams), and 图片 (image posts). It also describes two acquisition modes, automatic monitoring and a manual copy-link path.

The audience is narrow and specific. This is for someone who watches WeChat Channels on a Windows machine and wants a local copy, for archiving, for offline review, or for material that disappears from the feed. It is not a phone tool. Every instruction in the README assumes a desktop install with a folder for cached files, a mitmdump.exe binary, and a certificate store you can modify. If your only WeChat is on an iPhone or an Android handset, the README gives you nothing to follow. The repository's example/ directory is instructive about scope: it holds .mp4 files and one .flv file, plus a 缓存 (cache) folder, so both progressive video and a live-stream container show up in real output.

How the monitoring and decryption mechanism works

The README's tutorial is short but it reveals the architecture. Step one: open the software and click 开始监听 (start monitoring), then open WeChat Channels. The README states the software will automatically monitor videos. That phrasing points to a local proxy that observes the traffic WeChat generates while you scroll, rather than an API integration, because WeChat exposes no public download API for Channels content. The presence of mitmdump.exe and of .p12 certificates in the cache folder confirms it: the tool participates in the TLS session so it can read the media URLs. This is why the title-display feature is optional and gated behind certificate installation. Without the certificates, the proxy can still see and save media, but it cannot read the metadata that carries the title.

The second path is manual. The README says you can click 复制链接 (copy link), download with an external download tool, then click 解密 (decrypt) and select the downloaded file. That is a two-stage flow: the tool gives you the address, you fetch the bytes with something else, and the tool then removes the encryption layer. The distinction matters because the two paths fail differently. The monitoring path depends on the proxy being trusted and on WeChat not changing its transport. The manual path depends on the link staying valid long enough for your external downloader to use it, and on the decrypt step accepting whatever container that downloader produced.

Live handling adds a third behaviour. The README's changelog says version 2.5 added MP4 output for live capture, segmented recording, and a pause-recording function. Version 2.8 says the live segment duration can now be set longer. So a live stream is not saved as one unbounded file by default; it is cut into segments whose length is configurable in the interface. That is a deliberate trade-off. Segments survive an interrupted session better than a single growing file, but they require reassembly if you want one continuous recording.

Installing it and capturing a first video

The repository does not publish install commands, package names or a version number to pin. The README points readers to a project page at changfengbox.top/wechatVideo for the software itself, and to a Telegram group at https://t.me/changfengbox for chat. There is no pip, npm or apt step in the README, so the only honest instruction is to get the build from the page the project names. What the README does give is the sequence after you have it running.

Start monitoring, then open WeChat Channels. The README's first step is exactly this pairing: press the monitor button first, then browse. The software is expected to list what it observes.

# Not an install command: this is the README's usage order, transcribed.
# 1. Open the application.
# 2. Click 开始监听 (start monitoring).
# 3. Open WeChat Channels and play a video.
# 4. The video appears in the list; click download, or enable auto-download.

For the manual route, the README describes copying the link, downloading it with your own tool, then using the decrypt action on the resulting file. If you want video titles rather than opaque filenames, the README's title instructions are a separate three-step procedure: click 开启标题显示 (enable title display), open the cache folder and install the two 证书.p12 certificates by double-clicking and confirming through the dialogs, then restart the software. The README notes that if the certificates have not been generated, you must open mitmdump.exe manually first and try again. After the restart, the README says a 开启成功 (enabled successfully) message confirms title display is working. That is the point where you should see titles instead of hash-like names in the list.

Where it breaks: certificates, overwrites and the version 2.8 fixes

The changelog is the most useful part of the README for judging reliability, because it lists what has failed. Version 2.8 fixed video download failures, fixed an invalid download-directory action, and fixed same-name videos being overwritten. Version 2.6 fixed multiple live streams not displaying, simultaneous downloads of several videos, and failures on very large video files. Version 2.4 fixed videos that only played the first few seconds, and fixed certificate generation failures. Version 2.2 fixed list-clearing and title-fetch failures.

Read that list as a map of the failure surface rather than as a maturity signal. Certificate generation has failed before. Large files have failed before. Concurrent downloads have failed before. Title retrieval has failed before. The 2.8 fix for overwriting is worth calling out: before it, two videos with the same title could collide on disk, which means anyone who archived with an earlier build should check whether files were lost. The README also documents a hard dependency in the title flow: if the .p12 certificates are absent, you must open mitmdump.exe by hand. That is not a normal installer experience, and it is the step most likely to stop a non-technical user.

The wrong-tool case is equally clear. If you need something on a phone, this is not it: the README's entire procedure assumes a desktop with a modifiable certificate store. If you are unwilling to install a proxy certificate on the machine that runs WeChat, you can still use the monitoring and manual-decrypt paths, but you give up titles. And if you need a hosted service that takes a URL and returns a file, this project is the opposite of that: it runs locally and intercepts traffic.

The alternative approach: yt-dlp and a browser-side capture

The obvious alternative category is a general-purpose downloader such as yt-dlp. The difference in approach is fundamental. yt-dlp works from a URL and a site extractor: you give it a page address, it identifies the media endpoint and fetches it. That model assumes the media is reachable from outside the app and that the URL is stable enough to be resolved. WeChat Channels content is not published that way, which is why this project monitors traffic instead of resolving links. If you can obtain a direct media URL through some other means, a general downloader can fetch it, and the README's own manual path anticipates exactly that workflow: copy link, download externally, then decrypt.

A second alternative is browser-side capture: a proxy or developer-tools session that records media requests while you browse. That is conceptually the same mechanism as this tool, minus the packaging. The practical difference is that you would be assembling the proxy, the certificate trust and the decryption step yourself. This project bundles those into one interface, adds a list of captured items, and adds live segmentation. The cost of the bundle is that you inherit its bugs and its changelog, which the previous section shows is a real cost. If you only need one video once, a manual capture is less machinery. If you are archiving a channel repeatedly, the bundled monitoring loop is the reason to use this.

Maintenance, upgrades and what the licence question means here

The repository is not archived, and the last push was on 2026-08-29, which is recent. The release history shows a steady cadence: 2.6 on 2026-01-03, 2.7 on 2026-05-10, 2.8 on 2026-08-29. Roughly one feature release every four months, with fixes bundled into each. That cadence is the practical upgrade cost. There is no documented auto-update mechanism, no package registry, and no version-pinning instruction in the README, so upgrading means fetching a new build from the page the project names and reinstalling. Whether settings survive that is not documented. The README also does not document rollback, so if a new build regresses, the only path back is keeping the previous build yourself.

The licence is a genuine gap. The repository metadata carries no licence, and the README states none. For an individual archiving their own viewing, that is a practical non-issue. For anyone embedding this in a product, redistributing it, or shipping it inside a corporate image, the absence of a stated licence is a blocker to resolve before use, not after. I am not giving legal advice; the point is simply that the README does not answer the question, and you should treat an unanswered licence question as unanswered rather than assume permissive terms. The same applies to the proxy certificate: installing a .p12 into your trust store changes how your machine validates traffic, and the README does not describe how to remove it afterwards.

Editorial conclusion

Use it if you already run WeChat on a Windows desktop and you need archived copies of Channels videos, live replays or image posts, and you accept installing two .p12 certificates to get titles. Do not use it if you work only from an iPhone or Android phone, or if you expect an online service with no local install: the README describes a desktop application that monitors WeChat traffic and offers a manual copy-link plus decrypt path. Before adopting it, verify three things in the repository itself: the licence, since the repository metadata carries none and the README does not state one; whether the example/ folder contents are the kind of output you need; and whether the title-display certificate flow works on your machine, because the README says the certificates must be generated first by opening mitmdump.exe manually if they are missing.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qiye45/wechatVideoDownload on GitHub
4. README
5. Releases