The awkward part of local AI tooling is that "local" usually means "only useful while I am sitting at the keyboard."
That is fine when I am deep in an editor. It is less fine when Claude Code is waiting for approval, Codex finished a task, or I just want to ask "what happened?" from my phone.
I already had browser chat and a few external channels wired into CliGate. But for my daily workflow, one missing channel was obvious: WeChat.
The problem was not another bot
Adding a chat provider is easy if all you want is text in and text out.
That was not the workflow I wanted.
The useful version needs to preserve the shape of an AI coding task:
- start a Codex or Claude Code run
- keep follow-up messages attached to the same task
- surface approvals when the runtime asks for permission
- send progress and final results back to the user
- remember whether the conversation is a new task, a status check, or a continuation
Without that, a WeChat integration would just become another notification pipe. Nice to demo, not very useful under pressure.
The painful case is familiar: a local agent starts doing real work, hits one approval prompt, and then silently waits in a terminal you are not looking at. The problem is not that the model cannot reason. The problem is that the control loop is trapped in the wrong place.
The fix was to treat channels as task surfaces
In CliGate, I ended up treating WeChat the same way I treat Telegram, Feishu, and DingTalk: not as separate products, but as surfaces over the same local task system.
The runtime is still local. Claude Code and Codex still run on my machine. The proxy, account routing, logs, approvals, and task records still live on localhost.
The channel only changes where I talk to the workflow.
That distinction matters. It means the WeChat provider does not need to know how to run Codex. It needs to know how to receive a message, map a user to a conversation, and hand that message to the same supervisor layer that the web chat uses.
The mental model looks like this:
WeChat message
-> channel gateway
-> supervisor conversation
-> Codex or Claude Code runtime
-> progress / approval / result
-> WeChat reply
The interesting part is the middle. A message like "status?" should not be forwarded to Codex as a random new prompt. It should be answered from the remembered task state. A message like "also update the docs" should usually continue the current task, not start from scratch with the default provider.
That task memory is what makes a channel feel like a real interface instead of a webhook.
What changed in the workflow
Before this, I had a split-brain setup.
The desktop dashboard was where the real task state lived. My phone was mostly for checking messages. If an AI coding task needed a decision, I had to return to the browser or terminal.
Now the chat app can stay in the loop:
- start a coding task from WeChat
- receive progress as the local runtime works
- answer approval prompts without finding the terminal
- ask for a status update without interrupting the agent
- continue the same task with a short follow-up
That does not make WeChat special. That is actually the point.
The more useful design is that the channel is replaceable. Telegram, Feishu, DingTalk, WeChat, and the web dashboard should all speak to the same task model. Users can pick the surface that matches their day.
Why I kept the tools unchanged
I did not want to build a fake Claude Code or a fake Codex inside a chat app.
Those tools already have their own strengths. The better layer is a local control plane around them: one place for routing, credentials, approvals, task records, logs, and channel delivery.
That is what CliGate is trying to be.
You still run it locally:
npx cligate@latest start
Then the same machine that owns your code can also own the coordination loop. No hosted relay is required for the core workflow, and the AI coding tools do not need custom provider configs for every channel you add.
The lesson
The main thing I learned is that "mobile support" for local agents is not just a smaller UI.
It is a continuity problem.
If the phone cannot see the task state, approvals, runtime choice, and final result, then it is only a remote text box. If it can see those things, it becomes a practical control surface for work that still runs safely on your own machine.
That is the direction I want local AI tooling to go: the work stays local, but the conversation can meet you where you already are.
The project is open source here: https://github.com/codeking-ai/cligate
If you use AI coding agents, where do you want their progress and approval prompts to show up: terminal, browser, Slack, Telegram, WeChat, or somewhere else?
Top comments (0)