# chatgpt-wechat: running an LLM assistant inside WeChat through WeCom

> A Go service that routes ChatGPT, Gemini and Dify through WeCom so users talk to an assistant inside WeChat itself. Here is what it does, how to install it, and where it stops being the right tool.

**whyiyhw/chatgpt-wechat** — 企业微信/微信 安全使用的 LLM 个人助手/客服, 也支持 dify 工作流

- Repository: https://github.com/whyiyhw/chatgpt-wechat
- Stars: 1,172 · Forks: 216
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/whyiyhw-chatgpt-wechat

## The problem: getting an LLM into WeChat without risking the account

Personal WeChat accounts that automate replies get restricted. The README states the project's central claim plainly: it is an application for using ChatGPT inside WeChat safely, by relaying through WeCom (企业微信), with no ban risk. That relay is the whole idea. Instead of driving a personal account, you register a WeCom application and let WeCom deliver messages to the user's WeChat client. The automation lives on the WeCom side, where the API is documented and permitted.

The audience follows from that constraint. This is for someone who has a company entity able to register WeCom, who wants an assistant or a customer service channel that ordinary WeChat users can reach without installing anything. The README also positions it as a customer service endpoint, with a separate document on multi-channel support message integration. A solo developer with no company cannot use the relay at all, which is the first thing to understand about the project.

## What the repository actually contains

The top level holds chat/, doc/, plugins/, plus LICENSE and README.md. The primary language is Go, and the licence is Apache-2.0. The chat/ directory carries the service, its configuration under chat/service/chat/api/etc/chat-api.yaml, and a build/ tree with the Redis configuration and data directory. The doc/ directory holds the deeper material the README links to: install.md, config.md, ability.md, plugin.md, draw.md, custom_support_service.md, frp.md, and CHANGELOG.md.

That layout tells you the project expects an operator, not a library consumer. There is no published package to import. You clone it, configure it, and run it. The README's upgrade note says version 1.0.0 is still in development and points at v0.6.6 as the stable release, with the database moved to pgsql to make vector queries easier.

## How the relay, the model calls and the plugins fit together

Messages arrive from WeCom, either as application messages or as customer service messages. The README's troubleshooting section names two distinct failure log lines, 应用消息-发送失败 err: and 客服消息-发送失败 err:, which confirms these are two separate delivery paths in the code. The service then calls a model provider. OpenAI and Azure OpenAI are both supported, and the README also lists Gemini-pro support and one-api custom model names, so the provider layer is configurable rather than hardcoded.

State lives in Redis and Postgres. Redis handles the cache, and the README's FAQ shows RedisCache.Pass as a configuration key. Postgres arrived with the 1.0.0 line specifically for vector queries, and the README lists milvus as a private vector knowledge base option. Conversation context is described as adaptive: the service adjusts context length on its own rather than making the user clear history. Replies can be streamed in segments, which the README calls 分段极速响应.

Plugins are a separate directory. The README lists shell, search and wikipedia as the shipped ones and points to doc/plugin.md for the rules for writing others, naming summary and weather as examples. A shell plugin in a service that accepts messages from outside your organisation deserves a hard look before you enable it; the README does not describe any sandboxing or allowlist around it.

## Installing chatgpt-wechat and sending a first message

The README points to doc/install.md for the full steps and to doc/config.md for every configuration key. The service runs under Docker Compose, and the FAQ shows the container name chat_web_1 in a log command, so the web service is the one to watch.

Configuration lives in a YAML file. The FAQ shows the exact shape of the Redis password key, which is a good sample of how the file is organised:

```yaml
RedisCache:
    Pass: "xxxxxx"
```

If you change that value, the matching Redis server setting is in chat/build/redis/redis.conf, and the FAQ shows the directive there:

```ini
requirepass "xxxxx"
```

After editing chat-api.yaml, restart just the web service, or rebuild everything:

```bash
docker-compose restart web
```

```bash
docker-compose build && docker-compose up -d
```

When something goes wrong, follow the logs and grep for the two failure keywords:

```bash
docker logs -f chat_web_1
```

What you should see on a working setup is a reply in the WeChat conversation after you send a message to the WeCom application. If the model answers but nothing reaches the user, the README's first FAQ points at the trusted IP configuration in install.md step 5, and at access_token errors such as Code 41001. Those usually mean CorpID, agentSecret or agentID in the config do not match the WeCom application.

## Where it breaks: network, Redis state and the shell plugin

The README's second FAQ is blunt about geography. On a server inside mainland China you can hit connect: connection refused when the service tries to reach the model API. The two documented answers are to install a proxy client listening on 0.0.0.0 in socket mode without authentication and enable the proxy in the config, or to move the server to Hong Kong or overseas. The README adds that mainland access will not work long term. That is a deployment constraint, not a bug, and it shapes where you can host this.

Redis state is the second sharp edge. The FAQ documents a case where Redis fails to start or the service cannot connect after an update, and the fix is to stop the stack, delete the files under chat/build/redis/data/, and start again. That directory is inside the repository tree, which means conversation state can be wiped by a routine upgrade if you have not moved it onto a volume. Plan for that before you put real users on it.

The shell plugin is the third. The README lists it as an available plugin and says nothing about restricting what it can execute. If you enable it for a customer-facing bot, you are trusting every inbound message.

## Compared with Wechaty-style personal account bots

The obvious alternative approach is a framework like Wechaty, which drives a personal WeChat account directly. The difference is not one of features but of where the automation sits. Wechaty-style tools operate the user account itself, so the account is the thing at risk and the project's behaviour depends on an unofficial interface. chatgpt-wechat puts the automation on the WeCom application side, where WeCom delivers messages to WeChat on your behalf.

That trade is concrete. You gain a supported path and the ability to publish the bot as a customer service channel, which the README lists as a supported feature. You lose the ability to run without a company entity, and you inherit WeCom's configuration surface: trusted IPs, CorpID, agentSecret, agentID. If your users are already inside a company that runs WeCom, the relay is nearly free. If they are not, it is a wall.

## Maintenance, licence and what upgrading costs

The last push to the default branch was on 2026-05-20, and the repository is not archived. The most recent release listed is v0.6.6 from 2024-01-05, while the README describes 1.0.0 as still in development and recommends v0.6.6 for stability. So the release tags and the branch activity are not telling the same story, and anyone pinning a version should decide which of the two they are tracking.

The upgrade path itself has a cost. Moving from the 0.6.x line to 1.0.0 switches the database to pgsql for vector queries, adds Gemini-pro, adds a web bot that can be published to customer service, and adds a separate front end at whyiyhw/agent-web. That is a migration, not a patch. The Redis data deletion issue in the FAQ is the kind of thing that shows up during exactly this kind of move.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you keep the licence and notice files and state significant changes. This is a summary of the licence text, not legal advice; read LICENSE and your own counsel's view before shipping it inside a product. One practical note for anyone embedding it: the README says the project is free and open source with no paid tier, and warns that anyone asking you to pay is a scammer.

## Conclusion

Adopt chatgpt-wechat if you already run a WeCom tenant and want an assistant or support desk reachable from ordinary WeChat conversations, with streaming replies, voice and image input, and pluggable tools. Do not adopt it if you need a hosted product with a support contract, if you cannot run Docker and Postgres on the host, or if your only requirement is a personal WeChat bot with no company entity behind it, since the whole design depends on the WeCom relay. Verify three things before committing: that the trusted IP list in your WeCom admin console matches the machine running the service, that the model endpoint is reachable from that host or a proxy is configured, and that the database volume under chat/build/redis/data/ is on persistent storage you can back up.

## FAQ

### Does chatgpt-wechat risk getting my WeChat account banned?

The README states the opposite: the application is designed to be used safely inside WeChat by relaying through WeCom, with no ban risk. The automation runs on the WeCom application side rather than on a personal account.

### Which model providers does chatgpt-wechat support?

The README lists OpenAI and Azure OpenAI, with proxy and reverse-domain proxy support, plus Gemini-pro and one-api custom model names. The 1.0.0 upgrade note mentions Gemini-pro specifically.

### How do I restart chatgpt-wechat after changing chat-api.yaml?

The FAQ gives two options: docker-compose restart web to restart only the web service, or docker-compose build && docker-compose up -d to rebuild and restart the whole stack.

### Why does the service get connection refused when calling the model API?

The README attributes this to running the server in mainland China. The documented fixes are to install a proxy client listening on 0.0.0.0 in socket mode with authentication off and enable it in the config, or to move the server to Hong Kong or overseas.

## Sources

- [Issues](https://github.com/whyiyhw/chatgpt-wechat/issues)
- [License: Apache-2.0](https://github.com/whyiyhw/chatgpt-wechat/blob/main/LICENSE)
- [README](https://github.com/whyiyhw/chatgpt-wechat/blob/main/README.md)
- [Releases](https://github.com/whyiyhw/chatgpt-wechat/releases)
- [whyiyhw/chatgpt-wechat on GitHub](https://github.com/whyiyhw/chatgpt-wechat)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/whyiyhw-chatgpt-wechat