Survey date: 2026-03-27 Target scenarios: (A) bulk extraction of WeChat chat history for analysis; (B) monitoring 3-4 group chats for alerts or low-frequency replies Method: multi-agent parallel research + official documentation + public project source verification + cross-checking
For large-scale chat history analysis, the lowest-friction path is not UI automation but direct database decryption. Both macOS and Windows have mature open-source tools that can decrypt local WeChat SQLite databases and recover full text, sender IDs, and timestamps without manipulating the UI at all. For a limited bot that monitors 3-4 group chats, Android with worktool is the most engineered solution, macOS can use a mixed approach of database Webhook intake plus AppleScript sending, and Windows after WeChat 4.0 needs either OCR screenshots or a pinned old version with Hook injection. On iOS, neither goal is feasible without jailbreaking.
There is one premise that matters for understanding the current landscape: WeChat 4.0 changed the underlying rendering architecture on every platform, and the traditional UI-tree automation path is failing across the board. This is not a single tool problem. It is WeChat actively closing that route. Any technical choice has to price in that trend.
Before discussing feasibility, the first step is to separate three completely different technical paths, because their capability boundaries, detection surface, and version fragility differ sharply.
UI automation means using accessibility frameworks exposed by the operating system, such as Windows UIAutomation, the macOS Accessibility API, and Android AccessibilityService, to read the control tree of the application UI, capture text, and simulate clicks and typing. Its prerequisite is that the target application actually exposes meaningful UI elements to the system accessibility layer. The advantage is that it does not intrude into the target process, and at the system layer it looks almost the same as human operation. The downside is that it depends entirely on whether the target app is willing to expose stable, semantic UI objects.
Database decryption means directly reading WeChat’s encrypted local SQLite database files, extracting the encryption key from the WeChat process memory, decrypting the files, and then querying chat history with standard SQL. This path does not manipulate the WeChat UI and does not interact with the WeChat server. It only reads local files. It is naturally suited to large-scale data analysis, but it cannot send messages.
Hook/injection means reverse engineering the internal function addresses inside the WeChat process and injecting a DLL or dynamic library to intercept function calls, so that it can implement full features such as message receive/send and contact management. This path is the most powerful, but also the most intrusive. It requires pinning to specific WeChat versions and lives in a legal gray zone.
These three paths are not substitutes in a strict sense. In practice they are often combined. On macOS, for example, the most pragmatic setup is to read messages through database decryption and send messages through the Accessibility API.
Windows used to have the richest WeChat UI automation ecosystem. wxauto, with 6,832 GitHub stars, was the best-known project. It used the Windows UIAutomation API to read the WeChat desktop client control tree, and could send messages with roughly 10 lines of Python. But wxauto stopped maintenance in October 2025 because WeChat 4.0.5 migrated from Qt Widgets to Qt Quick/QML.
The effect of this architecture change is fundamental. In the Qt Widgets era, every UI control in WeChat corresponded to a Win32 window handle, so the UIAutomation framework could traverse the control tree, read text, and locate buttons. After the move to Qt Quick, the UI is rendered with OpenGL onto a canvas, and most controls no longer have independent HWNDs. UIAutomation can only see an empty shell window. wxauto4, an adaptation attempt for WeChat 4.0 with 211 stars, has already explicitly marked itself as no longer updated.
There is a newer project called wechat-automation-api, with 91 stars, that claims compatibility with WeChat 4.0+, but its README does not explain in detail how it bypasses the Qt Quick UI black-box problem. It may only work for early 4.0 builds that still preserved some HWNDs, so its long-term reliability is doubtful.
For environments still using WeChat 3.9.x, wxauto remains usable. The WeChat window has to stay visible on the desktop and cannot be minimized, message reading works through polling rather than callbacks, and WeChat auto-update is the most common source of failure. Under those constraints it is still enough for a prototype that monitors three or four groups. The program runs on a Windows computer and occupies a foreground window.
After WeChat 4.0, UI automation on Windows has effectively regressed into screenshot + OCR + coordinate clicking. A detailed technical report on getquicker.net describes this route: GDI screenshots, OpenCV HSV color masks to detect unread-message red dots, OCR for text recognition, and Win32 API coordinate clicking. Traditional OpenCV approaches keep latency under 50 ms, while AI vision parsing approaches such as OmniParser exceed 500 ms.
The benefit of this route is that it is less sensitive to WeChat version changes as long as the UI does not undergo a major redesign. The cost is that it can only capture content currently visible on screen, historical messages require continuous scrolling and capture, and it depends on screen resolution and window position. That makes it inefficient for bulk history analysis, but sufficient for monitoring new messages in a few group chats.
wechat-decrypt, with 2,207 stars and active maintenance, can decrypt
the SQLCipher-encrypted databases stored locally by WeChat on Windows
and recover full chat history. The key is extracted from the WeChat
process memory. Installation is pip install wechat-decrypt.
After decryption, standard SQL can query complete text across any time
range and any chat, including sender wxid, display names, and message
types. This path does not manipulate the UI or interact with the server.
The only runtime requirement is that the WeChat client is running so the
key can be extracted from memory.
For bulk chat-history analysis, this is the most direct option on Windows. The limitation is that it is read-only and cannot send messages. If both monitoring and replying are needed, then database reading for detection has to be combined with another path for sending replies.
WeChatFerry, with roughly 6,400 stars and active maintenance, reverse
engineers PC WeChat, locates key function addresses, and injects a DLL
to intercept internal calls. It provides real message callbacks with no
polling, can run with the WeChat window minimized, and supports full
operations such as sending text, images, files, @mentions, and forwarding. Its Python SDK
is available through pip install wcferry, and it also has
Docker deployment options.
The core constraint is that the WeChat version must be pinned and cannot update. It is currently adapted up to 3.9.12.51. Every WeChat update can shift function offsets and requires WeChatFerry to re-adapt. Beyond that, Hook injection is intrusive to the process, which places it a full level higher in both detection risk and legal/compliance sensitivity than pure UI automation.
For chat history analysis, use direct database decryption with wechat-decrypt. For a group-monitoring bot, if pinning to WeChat 3.9.x is acceptable, WeChatFerry is the most feature-complete option. If using WeChat 4.0+, the path falls back to OCR screenshots. The program runs on a Windows machine.
There are two actively maintained database-decryption projects on macOS. chatlog-bot, with 22 stars and built on top of sjzar/chatlog, provides a complete HTTP API, MCP integration, Webhook-based real-time new-message listening, multi-account support, and Docker deployment. wechat-db-decrypt-macos, with 466 stars, is similar and additionally supports an MCP Server. Both use a C memory scanner to extract the SQLCipher 4 key from the WeChat process and then query the decrypted database with standard SQLite.
chatlog-bot’s Webhook capability deserves special attention. It uses fsnotify to watch database-file changes, and when a new message is written to disk it automatically decrypts and pushes an event. That makes it effectively a quasi-real-time message subscription system. In other words, it can serve not only batch historical analysis, but also as the intake side for group monitoring.
There is one operational hurdle: extracting the key requires
temporarily disabling macOS SIP, System Integrity Protection, by
rebooting into Recovery mode and running csrutil disable.
This is a security downgrade, but it is reversible with
csrutil enable. macOS system updates may re-enable SIP
automatically.
WeChat-MCP, with 133 stars, MIT license, and written in Python,
directly reads the WeChat UI tree through the macOS Accessibility API.
It can navigate to any chat, read currently visible messages, and send
text messages. It uses pyobjc to call AXUIElement APIs, uses
AXUIElementSetAttributeValue to set text in the input
field, and uses CGEventCreateKeyboardEvent to simulate
Enter for sending.
This project demonstrates that current macOS WeChat 4.x still exposes
usable UI objects through the Accessibility API, including session list
items like session_item_{chat_name}, the input field
chat_input_field, and the search result list
search_list. There is one limitation in message reading:
the AX tree does not directly expose sender identity, so WeChat-MCP uses
a screenshot heuristic, sampling the pixel colors on the left and right
of a message bubble, to determine whether a message was sent by the user
or by someone else.
mac-wechat-summary contains one engineering detail worth noting on the sending side: its CGEvent keyboard-event function always explicitly sets flags to 0, which prevents inheriting modifier state from a previous keystroke. That avoids the case where pressing Enter after Cmd+V turns into Cmd+Enter, which inserts a newline in WeChat instead of sending the message.
The most pragmatic setup on macOS is to combine the two paths: use database decryption for message intake and historical analysis, because it is accurate, complete, and independent of UI state; then use the Accessibility API or AppleScript for sending, because it is real-time and flexible. chatlog-bot’s Webhook listens for new messages, triggers business logic, and the sender then navigates to the right group and replies through the Accessibility API. The two core projects are both Python, so they can be composed in a single process.
This setup needs no extra device, runs directly on the Mac, does not require pinning a WeChat version because the database format is more stable than the UI layout, and does not rely on Hook injection. The cost is the temporary SIP disablement and the fact that the AppleScript or Accessibility sender may need adjustment if the WeChat UI changes significantly.
For chat-history analysis, macOS currently offers the best overall experience. chatlog-bot or wechat-db-decrypt-macos are both close to turnkey. For a group-monitoring bot, the combination of DB Webhook intake and Accessibility API sending is feasible with medium engineering effort. The program runs on the Mac.
Android’s AccessibilityService is the strongest automation capability exposed by the OS among the four platforms. It can receive UI change events, read window content and node trees, and execute clicks and text input, and it is part of the official Android SDK. Chinese regulators have even required apps to improve accessibility support.
The problem is on WeChat’s side. Starting from WeChat 8.0.52, WeChat
introduced node obfuscation against AccessibilityService, which
scrambles the node information received by automation scripts and breaks
accessibility-based automation. There is currently a workaround:
register an accessibility service with the same package and class name
as a built-in system service, such as
com.google.android.accessibility.selecttospeak.SelectToSpeakService,
and use that identity to bypass the obfuscation check. Auto.js Pro and
the open-source library Assists already integrate this route. But this
depends on unintended behavior, which WeChat can patch at any time.
worktool, with 2,935 stars, is the most engineered WeChat automation solution on Android. It is built on top of AccessibilityService and ships with a complete Android app, backend scheduling platform, and HTTP API docs. It claims compatibility with WeChat 4.1.8 through 5.0.3, requires no root, and supports 99% of Android phones. The open-source edition stopped at v2.8.1 in November 2023, while the commercial edition continues to update. It covers sending and receiving messages, group creation, member invite and removal, automatic friend acceptance, @mentions, and more.
On Android, WeChat databases live in the app’s private directory, which is inaccessible without root. That makes the database route unrealistic for bulk chat-history analysis on Android unless the user is willing to root the device.
There are two practical constraints on Android. First is background restrictions. Since Android 8, the platform has continuously tightened background behavior, and battery optimization or process cleanup may kill the accessibility service. Different vendors such as Xiaomi, Huawei, and OPPO also apply different policies, so self-start permissions and battery-optimization exemptions are usually needed. Second is the foreground requirement. Accessibility services can listen in the background, but simulated clicks require WeChat to be in the foreground and the screen to stay on. The usual setup is to dedicate an Android phone with the screen kept awake.
For bulk chat-history analysis, Android is not the right platform, because the database cannot be read without root. For a group-monitoring bot, worktool is the most complete and best-engineered option across all platforms, but it requires a dedicated Android phone. The program runs as an app on the phone.
iOS’s closed ecosystem makes any form of WeChat personal-account automation extremely difficult. The sandbox blocks cross-app data access and operation simulation. iOS has no global AccessibilityService API comparable to Android. Shortcuts cannot read WeChat chat content or send messages into a specific group.
Apple documentation does support Xcode-led UI testing and automation through XCUITest, and WebDriverAgent plus Appium can in theory automate across apps, but these are intended for developers in controlled test environments. They require Xcode and an Apple Developer account, and there is no public WeChat-specific adaptation layer. Within the scope of this research, no public project was found for automating a personal WeChat account on iOS.
Jailbreak-based approaches could in theory break through the sandbox, but most modern iOS devices are not jailbreakable, and jailbreak status itself can be detected by Tencent. Under the two target scenarios here, iOS is not feasible.
Different technical paths expose very different surfaces to WeChat’s risk-control system, and that difference directly shapes the selection decision.
Direct database decryption has the smallest detection surface. It does not interact with the WeChat process except when touching memory to extract the key, does not talk to the WeChat server, and does not generate abnormal network traffic or action patterns. Neither the WeChat client nor server can realistically observe that someone is reading local database files. Among all paths, it carries the lowest account risk, close to zero.
UI automation, including Windows UIAutomation, the macOS Accessibility API, and Android AccessibilityService, looks almost identical to human interaction at the system layer. The WeChat client sees normal sequences of window activation, input-box focus, text entry, and button clicks. The WeChat server sees messages sent and received at normal frequency. The main detection surface here is statistical behavior anomaly. If reply speed is too uniform, timing is too regular, or the account stays active 24 hours a day, behavior analysis could in theory flag it. But for a low-frequency setup that monitors only 3-4 groups, that level of anomaly is unlikely. Public reports of account bans caused purely by UI automation, as opposed to marketing abuse, are rare.
Hook/injection has a noticeably larger detection surface than the first two paths. DLL injection modifies the memory space of the WeChat process. The client can in principle detect this through integrity checks, anti-debugging logic, or module-list scanning. One reason tools like WeChatFerry require pinned WeChat versions is that new versions may add targeted detection logic. In public communities, ban reports involving Hook-style tools are more common than reports involving pure UI automation, though many of those cases involve high-frequency marketing or mass messaging. For low-frequency personal use, the absolute ban probability still appears relatively low.
Protocol simulation, such as the old web protocol or iPad protocol routes, has the largest detection surface. At the server layer, it differs in identifiable ways from normal client behavior, including login environment, heartbeat characteristics, and TLS fingerprinting. Tencent shut down Web WeChat login in 2019. Community reports around iPad-protocol solutions such as Wechaty’s padlocal puppet include multiple account-ban cases.
Windows is the platform where WeChat has invested the most into anti-automation efforts, because the automation tool ecosystem there is the richest. The migration from Qt Widgets to Qt Quick in WeChat 4.0 can itself be understood as a systematic move against UI automation. Ban reports for Hook injection on Windows are also more common than on other platforms.
macOS currently faces relatively less anti-automation pressure. The database-decryption path has a very small detection surface because it is purely local, and the Accessibility API path produces operations that are almost indistinguishable from human use. The macOS WeChat user base is much smaller than the Windows one, and WeChat’s anti-automation investment on this platform appears correspondingly lower.
Android is a special case. AccessibilityService is an official Android API and also sits under an accessibility-compliance policy context, so WeChat is unlikely to block accessibility services outright. But the node obfuscation introduced in WeChat 8.0.52 shows that WeChat is increasing the cost of accessibility-based automation rather than banning it directly. The continued existence of worktool, including its commercial edition, suggests that this path remains maintainable in practice.
iOS would face the highest detection risk for any automation route that could even be made to work, because jailbreak status itself is a direct detection target.
Public community experience shows a clear difference in risk tier between low-frequency personal use across a small number of group chats and high-frequency abuse such as marketing automation, mass messaging, or large-scale friend adds. Tencent focuses on bulk registration, mass messaging, automated friend adds, and protocol-layer simulated logins. Monitoring 3-4 group chats and replying occasionally is not the core enforcement target. That said, this judgment is based on current public experience, and WeChat’s risk-control strategy can change at any time.
| Technical path | Client-side detection surface | Server-side detection surface | Risk for low-frequency monitoring | Risk for high-frequency automation |
|---|---|---|---|---|
| Direct database decryption | Very low | None | Very low | N/A (read-only) |
| UI automation | Low | Low, mostly behavioral statistics | Low | Medium |
| OCR screenshots | Very low | Low, mostly behavioral statistics | Very low | Medium |
| Hook/injection | Medium, process integrity | Low | Low to medium | Medium to high |
| Protocol simulation | High | High | Medium to high | High |
Wechaty, with roughly 22k stars, is the best-designed cross-platform chatbot RPA SDK framework from an architecture perspective, but its core dependency is the puppet layer, the protocol implementation underneath. All free puppets that used to work are now defunct or blocked. The currently available puppets, such as padlocal based on iPad protocol simulation, require paid tokens and still carry ban risk. For a low-frequency scenario with only 3-4 groups, Wechaty’s paid cost structure is hard to justify.
On macOS, use chatlog-bot or wechat-db-decrypt-macos. On Windows, use
wechat-decrypt. These are installation-level tools, typically
pip install or go install, and after
decryption they expose full historical data through standard SQL
queries. chatlog-bot on macOS additionally offers an HTTP API and MCP
integration, which makes it well suited for direct connection into AI
tooling. The account risk of this route is close to zero.
Android and iOS are poor fits for bulk chat-history analysis, for straightforward reasons: Android cannot read the database without root, and iOS is blocked by sandbox isolation.
The first choice is Android plus worktool, if a dedicated Android phone is available. worktool provides the most complete app, backend scheduler, and HTTP API stack among all options, and it is based on the system’s official accessibility service, which keeps detection risk relatively low.
The second choice is the macOS hybrid route: chatlog-bot Webhook for listening to new messages, plus AppleScript or the Accessibility API for sending replies. It needs no extra device and runs on the Mac, but it requires temporarily disabling SIP and some sender-side debugging.
The third choice is Windows plus WeChatFerry pinned to WeChat 3.9.x. It provides the most complete functionality, background operation, event callbacks, and Docker deployment. The trade-off is the need to lock to an old WeChat version and accept higher detection risk than the first two routes.
macOS is the only platform that can satisfy both goals with one coherent technical stack: chatlog-bot for historical analysis and real-time message intake, and the Accessibility API for sending replies. On Windows, the analysis path and the sending path split into different stacks, database decryption for analysis and OCR or Hook for sending, which raises integration cost.
| Project | Stars | Platform | Technical path | Maintenance status |
|---|---|---|---|---|
| wechat-decrypt | 2207 | Windows | Direct database decryption | Active |
| wxauto | 6832 | Windows | UIAutomation | Maintenance stopped, broken by WeChat 4.0 |
| WeChatFerry | ~6400 | Windows | Hook/DLL injection | Active, pinned to 3.9.x |
| wechat-automation-api | 91 | Windows | UIAutomation | Active, 4.0 compatibility still unverified |
| chatlog-bot | 22 | macOS | Database decryption + HTTP API + MCP | Active |
| wechat-db-decrypt-macos | 466 | macOS | Database decryption + MCP Server | Active |
| WeChat-MCP | 133 | macOS | Accessibility API | Active |
| mac-wechat-summary | N/A | macOS | Database decryption + CGEvent sending | Active |
| openclaw-wechat-plugin | 17 | macOS | AppleScript + Webhook | Demo-level |
| worktool | 2935 | Android | AccessibilityService | Active, commercial + open source |
| CleanUpWeChatZombieFans | 391 | Android | Auto.js | Active |
| wechaty | ~22000 | Cross-platform | RPA framework, requires paid puppet | Framework active, free puppets defunct |
| XYBotV2 | 798 | Win/Linux/Mac | UI automation | Maintenance stopped |
This survey is based on public information available as of 2026-03-27. WeChat version updates and risk-control changes may invalidate some conclusions within a few months. All projects state that they are for learning and discussion only, and users should assess compliance risk on their own.