If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sunnyyoung/WeChatTweak shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 3mo ago

• Last commit 3mo ago
• 3 active contributors
• AGPL-3.0 licensed
• ⚠ Slowing — last commit 3mo ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sunnyyoung/WeChatTweak repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sunnyyoung/WeChatTweak.

What it runs against: a local clone of sunnyyoung/WeChatTweak — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sunnyyoung/WeChatTweak | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 121 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sunnyyoung/WeChatTweak. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sunnyyoung/WeChatTweak.git
#   cd WeChatTweak
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sunnyyoung/WeChatTweak and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sunnyyoung/WeChatTweak(\\.git)?\\b" \\
  && ok "origin remote is sunnyyoung/WeChatTweak" \\
  || miss "origin remote is not sunnyyoung/WeChatTweak (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 121 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~91d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sunnyyoung/WeChatTweak"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

WeChatTweak is a Swift-based macOS command-line tool that patches the WeChat client binary to block message recall, prevent auto-updates, and enable multiple simultaneous client instances. It works by directly modifying the WeChat application executable at runtime to intercept and suppress these behaviors. Simple flat structure: Sources/WeChatTweak/ contains main.swift (CLI entry), Command.swift (command routing), Config.swift (version/feature configuration), and Patcher.swift (core binary patching logic). Package.swift declares it as a Swift executable package with no external dependencies.

Chinese macOS users who want to prevent colleagues or contacts from recalling messages, avoid forced WeChat updates, or run multiple WeChat accounts simultaneously on one machine without using virtual machines.

Actively maintained single-author project with clear versioning support (config.json tracks compatible WeChat versions). No visible CI/CD setup or test suite in the repository structure. The implementation is stable for its narrow use case but relies on reverse-engineering WeChat internals, making it inherently fragile across WeChat version updates.

High risk of breakage: the patcher depends on exact binary offsets and function signatures in WeChat, which change with every WeChat update—the config.json tracks versions but patches may silently fail. Single maintainer with no automated tests means regression detection is manual. The AGPL-3.0 license is restrictive for closed-source modifications.

No recent commit data available in the provided information. The repo maintains config.json to track compatible WeChat versions, suggesting active monitoring of WeChat releases, but current development status is unclear.

git clone https://github.com/sunnyyoung/WeChatTweak.git
cd WeChatTweak
brew install sunnyyoung/tap/wechattweak
wechattweak patch

Daily commands:

make build
./build/wechattweak patch
./build/wechattweak versions

• Sources/WeChatTweak/Patcher.swift: Core logic that performs binary pattern matching and hex-patching on the WeChat executable—any new tweak feature requires modifications here
• config.json: Stores version-specific binary offsets, memory addresses, and hex patterns for each supported WeChat version; must be updated whenever WeChat releases a new version
• Sources/WeChatTweak/Config.swift: Parses config.json and provides type-safe access to version metadata and patch definitions that Patcher.swift consumes
• Sources/WeChatTweak/Command.swift: CLI command dispatcher handling 'patch', 'versions', and other subcommands—entry point for user interaction
• Package.swift: Swift Package Manager manifest defining the executable target and build configuration with zero external dependencies

For new features: add command handlers to Command.swift and parse new config keys in Config.swift. To support a new WeChat version: add entries to config.json with the binary offsets for the patterns Patcher.swift searches for. For new patch types (beyond message recall, auto-update, multi-open): add logic to Patcher.swift's patch method and corresponding config.json metadata.

Patcher.swift relies on exact hex pattern offsets stored in config.json—if WeChat updates and changes the binary layout, patches will fail silently or crash the app. The tool requires full write access to the WeChat application bundle (usually /Applications/WeChat.app), which may require elevated privileges or code-signing workarounds on newer macOS versions. Backup of original WeChat binary is not automatic—failed patches can corrupt the installation.

• Binary patching and hex pattern matching — Core technique used in Patcher.swift to locate and modify compiled code; essential to understanding how WeChatTweak intercepts WeChat behavior without source code
• Runtime code instrumentation — The tool modifies an already-compiled executable at runtime to change its behavior—requires deep understanding of executable formats and function calling conventions
• Reverse engineering and binary analysis — Contributors must identify WeChat's binary structure, function signatures, and control flow to craft correct hex patches—no source code available
• macOS code signing and sandboxing — Patching a binary invalidates its signature; understanding macOS security constraints is crucial for deployment and avoiding sandbox violations
• Version-specific configuration management — config.json pattern stores patches keyed by WeChat version number because binary offsets change between releases—critical for maintainability at scale

• grepug/WeChatTweak-macOS — Alternative WeChat patcher for macOS also targeting message recall blocking and multi-open; represents competing approach in same ecosystem
• Telepathy/weChat — WeChat-related macOS tweaks exploring similar binary patching techniques for WeChat functionality extension
• sindresorhus/mas — Command-line macOS App Store manager; shares similar CLI/automation design patterns and uses Swift/Foundation for system integration
• swiftenv/swiftenv — Swift version manager; demonstrates Swift package distribution and version management patterns applicable to WeChatTweak's versioning strategy

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow to automate Swift builds and test WeChat version compatibility

The repo lacks automated testing infrastructure. Currently there's no CI to validate that the patching logic works correctly across different WeChat versions. A GitHub Actions workflow would catch breaking changes early, especially important since this tool patches binary code that varies by WeChat version.

• [ ] Create .github/workflows/swift-build.yml to compile the Swift package on every push/PR
• [ ] Add build steps that invoke 'swift build' to catch compilation errors
• [ ] Validate Package.swift dependencies resolve correctly
• [ ] Consider adding a workflow that tests against the versions listed in Sources/WeChatTweak/Config.swift to ensure compatibility data is accurate

Create detailed CONTRIBUTING.md with patching workflow and WeChat version update process

The README references two blog posts about patching internals but doesn't document how contributors can add support for new WeChat versions. The config.json likely maps versions to patch offsets, but the process for discovering and testing new patches is undocumented. This is critical since WeChat updates frequently.

• [ ] Document the process for identifying new WeChat versions and their binary structures
• [ ] Explain how to update config.json with new version entries
• [ ] Reference Sources/WeChatTweak/Patcher.swift and explain the patching mechanism
• [ ] Include testing instructions for contributors to validate their patches work before submitting PRs

Add unit tests for Config.swift parsing and Patcher.swift patch application logic

There are no visible test files in the Sources structure. Config.swift likely parses config.json and Patcher.swift applies binary patches—both are critical paths where bugs would break the tool silently. Unit tests would prevent regressions when updating patch logic or adding new WeChat versions.

• [ ] Create Tests/ directory with WeChatTweakTests target in Package.swift
• [ ] Add ConfigTests.swift to test parsing various config.json formats and edge cases
• [ ] Add PatcherTests.swift to validate that patch offsets are applied correctly and don't corrupt binaries
• [ ] Test version matching logic (Sources/WeChatTweak/Config.swift) against sample WeChat binary versions

• Add unit tests to Config.swift for JSON parsing edge cases (missing version keys, invalid hex strings) and error handling—currently untested
• Create a test fixture or documentation for the expected structure of config.json entries, including all required fields per WeChat version, to prevent contributor errors
• Add a 'restore' command to revert patched WeChat back to original state by comparing against a stored backup hash, improving user safety

This macOS command-line tool has moderate security concerns primarily related to its core functionality of binary patching a third-party application (WeChat). While the codebase appears to be written in Swift (generally safer than C), the nature of the tool involves runtime modification of protected system applications, which raises concerns about bypass of security mechanisms and maintainability. The lack of visible input validation, configuration file handling clarity, and incomplete documentation further reduce the security posture. The tool requires careful management of patches, proper code signing, and comprehensive security documentation to be considered production-ready.

• High · Binary Patching of Third-Party Application — Sources/WeChatTweak/Patcher.swift. The tool performs runtime patching of WeChat binary executable to modify behavior (prevent message recall, prevent auto-updates, enable multi-instance). This involves binary instrumentation which bypasses WeChat's built-in security mechanisms and integrity checks. This approach could be fragile, difficult to audit, and may violate WeChat's terms of service or macOS security policies. Fix: Document the patching mechanism thoroughly. Implement integrity verification of patches. Consider requesting official APIs from WeChat instead of binary patching. Ensure all modifications are logged for audit trails.
• Medium · Configuration File (config.json) Security — config.json. A config.json file exists in the root directory but its contents are not provided. Configuration files may contain sensitive information, API keys, or hardcoded paths. If this file is committed to version control or not properly protected, it could expose sensitive data. Fix: Ensure config.json is added to .gitignore if it contains any secrets or user-specific data. Use environment variables for sensitive configuration. If committed, audit contents immediately for any hardcoded credentials, API keys, or paths that could reveal system information.
• Medium · Insufficient Input Validation on Command-Line Arguments — Sources/WeChatTweak/Command.swift, Sources/WeChatTweak/main.swift. The tool accepts command-line arguments (patch, versions) but without visibility into Command.swift, there's risk of insufficient validation or sanitization. File paths or application names passed as arguments could be exploited for directory traversal or command injection attacks. Fix: Implement strict input validation for all command-line arguments. Use allowlists for accepted commands. Sanitize and validate any file paths. Avoid passing user input directly to shell commands or system calls without proper escaping.
• Medium · Lack of Code Signing Verification — Sources/WeChatTweak/Patcher.swift. The tool modifies WeChat binary, but there's no indication of verification that patches are applied safely or that the source WeChat binary hasn't been tampered with. On macOS, unsigned or improperly signed modifications could bypass Gatekeeper and other security features. Fix: Implement verification of WeChat binary signatures before patching. Ensure the patched binary is properly re-signed. Document the signing chain. Consider using entitlements and hardened runtime to restrict the scope of modifications.
• Low · Incomplete README - Truncated Documentation — README.md. The README appears truncated ('This project e'), suggesting incomplete documentation. Poor documentation can lead to misuse of the tool and security oversights by users. Fix: Complete the README with full documentation, security warnings, system requirements, and supported macOS/WeChat versions. Include clear statements about risks and terms of service compliance.
• Low · No Visible Dependency Management Security — Package.swift, Package.resolved. Package.resolved file exists but content not provided. Without seeing dependency versions and checksums, it's unclear if there are known vulnerabilities in dependencies or if dependency pinning is properly implemented. Fix: Regularly audit Swift package dependencies for known vulnerabilities using tools like Swift Package Manager security features. Pin exact versions of dependencies. Monitor security advisories for all transitive dependencies.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.