WeChat ACP
Connect WeChat direct messages to local ACP agents and return their replies, media, and files.
Per-dimension scores and reasoning
The README clearly describes the WeChat-to-local-ACP-to-WeChat flow, local storage of login and inbox state, telemetry fields, and opt-out behavior. The artifact service is documented and tested as loopback-only, bearer-token protected, browser-origin rejecting, workspace confined, and size limited. Deductions are substantial because agent permission requests are auto-approved and ordinary messages trigger agent work and outbound replies without per-action confirmation; the agent can also affect its configured working directory. Login and user-context data are persisted without documented encryption, filesystem permissions, or rotation. Dependencies use broad ranges; npm ci, CI, and OIDC provenance help, but no audit, lockfile evidence, or vulnerability-response policy is supplied. Cancel, reset, stop, retry, and one-shot artifacts provide partial recovery, but cannot undo external actions already taken by an underlying agent. Repository, package, and MIT copyright attribution are present, while publisher identity remains unverified.
The README, package metadata, CI, publishing workflow, and supplied tests agree on Node requirements, build and test commands, session restoration, process cleanup, and artifact behavior. Tests cover initialization aborts, resume-policy branches, propagated failures, cross-platform process-tree cleanup, and artifact shutdown errors, supporting strong consistency and failure visibility. Dependency availability is reduced by the Node 20+ and iLink requirements, reliance on separately available or npx-resolved ACP agents, and agent-specific authentication that the README itself identifies.
The source addresses quick starts, multiple instances, daemon operation, automation injection, session restoration, mixed-content prompts, and custom agents, with CLI, JSON configuration, aliases, and per-session visibility controls. Boundaries are explicit: direct messages only, stdio ACP transport, capability-dependent attachment delivery, and inability to detect silent iLink drops. Trigger rules precisely distinguish reserved slash commands, exact whole-message bare aliases, and prompts forwarded to ACP. Environment fit is not full because operation requires an eligible WeChat iLink environment and Node 20+, while several features depend on the selected agent.
The README is well organized across installation, configuration, runtime behavior, recovery, cancellation, buffering, files, storage, limitations, development, and telemetry, with extensive usable examples. The MIT license matches package metadata. Stable preset identities, fallback command names, and backward-compatible instance paths support naming stability, but no comprehensive compatibility guarantee is provided. Version 0.10.0, latest/next semantics, release-tag validation, and prerelease automation are documented, but there is no separate changelog or migration history. Maintenance ownership is only inferable from the copyright holder, repository, and issue URL; no explicit maintainer team, security-reporting route, or support commitment appears.
The bridge makes multiple ACP CLIs usable through WeChat and handles streamed text, images, audio, resources, files, cancellation, failed-text retrieval, fresh sessions, and local automation. This provides strong usable output and clear value over manual relaying. Cost-benefit is reduced by the need to maintain a local daemon, authenticate WeChat and agents, manage retained files, and secure the environment; automatic permission approval can also amplify operational cost and risk.
Many claims map to concrete configuration, workflows, and focused tests. Session restoration, process cleanup, path-escape prevention, authentication, one-shot artifacts, and capacity controls have cross-file corroboration. Claim traceability is reduced because core implementation files are absent from the supplied evidence and the telemetry section is truncated, preventing complete inspection of every README claim. The documentation carefully separates defaults, capability-dependent behavior, preview risk, and known undetectable failures from unconditional facts.
- Agent permission requests are auto-approved. Run only trusted agents under a low-privilege account and constrained working directory, and treat their file, command, and network capabilities as real external effects.
- Login tokens, context state, logs, injection queues, and received binary files are stored under ~/.wechat-acp, while inbox files have no automatic cleanup. The supplied material does not document encryption at rest or restrictive file modes.
- Anonymous Azure Application Insights telemetry is enabled by default. Sensitive deployments should set WECHAT_ACP_TELEMETRY=0 before startup and inspect the complete event list because the supplied telemetry section is truncated.
- Prefer @latest for stable use. The @next channel is published after every main-branch push and is explicitly described as lacking release review.
- Cancellation and session reset stop bridge work and queues but do not guarantee reversal of file changes, network calls, or other external actions already performed by the underlying agent.
What does this agent do, and when should you use it?
WeChat ACP is a locally run command-line bridge that receives one-to-one messages through the WeChat iLink bot API and connects to ACP-compatible agents over standard input and output. It maintains a separate ACP session and subprocess for each WeChat user, processes that user's messages serially, and sends text, images, audio, resources, or generated files back through WeChat. Bundled command presets cover Copilot, Claude, Gemini, Qwen, Codex, OpenCode, OpenClaw, Hermes, Kiro, Kimi, and Pi, while arbitrary ACP launch commands are also accepted. Operational features include daemon mode, isolated named instances, optional session resumption, local message injection, failed-text recovery, multipart input buffering, and in-chat session controls. Its deployment boundary is a local Node.js environment, with login credentials, inbox files, queues, state, logs, and daemon metadata stored under ~/.wechat-acp by default.
The program logs in and polls WeChat direct messages with the iLink bot API; it ignores group chats. For each sender, it starts or reuses an ACP subprocess, forwards prompts over stdio, formats the ACP output, and sends it back to WeChat. Binary attachments are downloaded and decrypted from the WeChat CDN, written to an inbox, and exposed to file-capable agents through an absolute local path; text-like files, source code, and images can instead be embedded as resource or image blocks. When an agent supports HTTP MCP, the bridge injects a local attach_file tool that can deliver files from the configured working directory, with supported images sent as native WeChat images. Bridge-level controls include /acp-config, /acp-cancel, /acp-new, /acp-more, /acp-prompt-start, and /acp-prompt-done, plus wechat-acp inject, stop, and status commands.
- A developer away from their workstation can message a Codex, Claude Code, or Copilot CLI session running in a specific project directory and receive its output in WeChat.
- An individual who prefers WeChat can access a local or npx-launched ACP agent while keeping each contact in a separate session.
- A developer maintaining several repositories can use --instance to run isolated bridges for different WeChat accounts and working directories.
- An automation owner can use wechat-acp inject from cron or launchd to enqueue a scheduled prompt and have the resulting response delivered through WeChat.
- A user can send PDFs, archives, or other binary material through WeChat so a file-capable coding agent can open the saved local path.
- Someone composing a request from separate WeChat text, image, and file messages can buffer them and submit the combined content as one agent turn.
What are this agent's strengths and limitations?
- Its ACP boundary avoids dependence on one model provider: it supplies presets for several CLIs and accepts custom command-and-argument definitions.
- Per-user subprocesses and sessions provide isolation, with optional restart persistence scoped by agent identity and absolute working directory.
- The bridge handles more than text, including images, audio, tool resources, inbound binary files, and agent-generated file delivery.
- Daemon mode, named instances, file-backed injection queues, cancellation, failed-text recovery, and multipart buffering cover practical unattended operation.
- The attach_file server binds to a random 127.0.0.1 port, requires a process-local bearer token, restricts reads to regular files inside the working directory, and enforces a 25 MiB limit.
- Adoption depends on a WeChat environment with iLink bot API access, and only direct messages are supported; group chats are ignored.
- Agent permission requests are automatically approved, which increases the importance of controlling the agent's working directory and local access.
- ACP communication is limited to subprocesses over stdio; no remote ACP transport is documented.
- Active generated-file delivery requires HTTP MCP injection and resource-link support from the selected agent, so capability varies between agents.
- Inbox files have no automatic cleanup and require an operator-defined retention policy.
- Anonymous telemetry is enabled unless WECHAT_ACP_TELEMETRY is explicitly set to 0, false, or off.
How do you install or deploy this agent?
Provide Node.js 20+, a WeChat environment allowed to use the iLink bot API, and an ACP-compatible agent installed locally or available through npx. A global installation is not required: run npx -y wechat-acp@latest --agent copilot. On the first run, scan the QR code rendered in the terminal; the login token is saved under ~/.wechat-acp and direct-message polling begins. Another bundled preset can be selected with a command such as npx -y wechat-acp@latest --agent codex. A custom agent can be launched with npx -y wechat-acp@latest --agent "npx my-agent --acp". Some preset agents require their own separate authentication.
How do you use this agent?
After starting the bridge and completing QR login, send a direct message to the bot account; each sender receives a dedicated ACP session. To bind the agent to a project, run npx -y wechat-acp@latest --agent claude --cwd D:\code\project, and add --daemon for background operation. Run npx wechat-acp agents to list presets, and use wechat-acp status or wechat-acp stop for process management. Add --instance projA when credentials, logs, state, and inbox files must be isolated from other bridges. In WeChat, /acp-cancel stops the current turn, /acp-new resets the user's session, /acp-config inspects or changes session settings, and /acp-more retries retained text segments rejected by iLink. Wrap separately sent text, images, and files between /acp-prompt-start and /acp-prompt-done to create one request. Local automation can enqueue work with npx wechat-acp inject --instance main --text "Daily AI news".
How does this agent compare with similar options?
Compared with operating Copilot, Claude, Gemini, Qwen, Codex, OpenCode, OpenClaw, Hermes, Kiro, Kimi, or Pi directly in their native CLI, WeChat ACP does not replace the underlying agent. It adds WeChat authentication and polling, per-user session management, media and file delivery, and daemon operations around the agent's ACP stdio interface. That makes it useful for remote access through WeChat, at the cost of an additional bridge process, local state, iLink API dependency, and messaging-platform constraints.