WenXiaoWendy/cyberboss: a WeChat bridge that gives a coding agent a sense of time

What Cyberboss moves out of the user and into the agent

Cyberboss is described as an agent bridge rather than a productivity timer, and the difference shows in the design. A timer is opened, started and stopped by the person who needs it. A to-do list assumes the same person returns to it. Reminder apps assume they are still respected when they fire. The project states its premise directly: most of these tools assume the user still has enough executive function to remember to use them, and the answer here is to move the regulatory layer into an always-on local agent.

The bridge plugs a local coding runtime into WeChat, the chat application the user already opens every day, and supports Codex and Claude Code behind the same command surface. The user does not start a session, because the bridge is already running and connected. Incoming messages are stamped with the local time before they reach the runtime, so the model is reading the day as it unfolds rather than reading loose text.

The intended audience is stated as people with ADHD or anyone who needs strong external accountability. The differentiator is not a better interface for a checklist. It is a supervision layer that keeps memory across time, notices when the user disappears, and can act on its own schedule. Everything else in the project, the timeline, the diary, the reminder queue, the file delivery, exists to support that one behavior.

Omniscient Time and the Ledger of Life

Two features carry most of the design weight. The first, called Omniscient Time, stamps every inbound WeChat message with local time before the message reaches the runtime. That single change is what makes the rest possible. Without a timestamp on every message, an agent reading a chat has no way to know whether a gap of silence lasted two minutes or two days, or whether a promise made this morning is still open.

The second, the Ledger of Life, uses those timestamps to reconstruct when events start, when they end and how long they last, then turns fragmented chat into a structured personal timeline. The practical effect is that the agent can reason about durations rather than only about text. It can tell that a task has been unresolved for a specific length of time, and it can describe a day as a sequence of spans instead of a pile of separate messages.

This layer is deliberately separable from the messaging part. The project points to a separate repository, WenXiaoWendy/timeline-for-agent, and states that it is an independent project that does not require the WeChat bridge, and that it can be plugged into another agent, bot or automation stack even if Codex is not used. Cyberboss builds on top of that timeline project and adds the WeChat connection, reminders, diary writing and random check-ins around it. A developer who likes the timeline idea but not the chat part has an exit that costs nothing.

Stochastic Pulse and the local reminder queue

The third feature, Stochastic Pulse, wakes the agent at random intervals and lets it decide what to do next. The options the project lists are sending a message, staying silent, writing in the diary, updating the timeline, or using tools. Silence is a valid outcome, which is the point: the agent is given discretion about when to appear rather than being given a schedule of fixed check-ins.

That discretion depends on the fourth feature, the Local Reminder Queue. The project is explicit that reminders are not primarily a user-facing alarm clock. They are how the model leaves instructions for its future self and wakes itself up later. The queue is one of three local queues, alongside system triggers and timeline screenshot jobs, all of which live on the machine rather than in a hosted service.

The mechanism is worth comparing with a scheduled cron job, because the difference is where the decision sits. A cron job says when to run and what to run. Here the wake-up creates an opportunity and the agent fills it, using its own judgment about whether a message is worth sending. The cost of that design is that behavior becomes harder to predict from configuration alone, and the project does not document a way to fix or silence the pulse itself.

Zero-Token Diary and optional file and image delivery

The fifth named feature is the Zero-Token Diary. Daily traces can be written to local files without depending on a cloud note service and without spending extra model context every time. For a bridge that runs all day, that matters: an always-on agent that wrote every observation back through a model call would cost tokens continuously, and a diary kept only in a vendor's note application would place a daily record of the user's day outside their control.

The capability layer lists timeline, diary, random check-ins, file delivery and related runtime actions. File delivery and images are part of the WeChat bridge itself, which handles inbound messages, outbound replies, files and status transitions over long-poll synchronization. A screenshot feature is available when the user has Chrome, Chromium or Edge installed, and timeline screenshot jobs are queued locally alongside the other two queues.

The vision side is configurable and separate. Variables such as CYBERBOSS_VISION_MODE, CYBERBOSS_VISION_PROVIDER, CYBERBOSS_VISION_API_BASE_URL, CYBERBOSS_VISION_API_KEY, CYBERBOSS_VISION_MODEL and CYBERBOSS_VISION_TIMEOUT_MS let the user point image understanding at an OpenAI-compatible endpoint, with the default mode given as auto and the default provider as openai-compatible. A separate location capability is opt-in through CYBERBOSS_ENABLE_LOCATION_SERVER, with its own host, port, token, home and work centers, known places and a place radius default of 150 meters, plus a battery history limit of 100 entries. Both of these are optional rather than required for the core loop.

Getting Cyberboss running from a clone and a .env file

The project is not published as an npm package, so installation is a clone followed by a local install:

git clone https://github.com/WenXiaoWendy/cyberboss.git
cd cyberboss
npm install

Requirements are Node.js `>= 22`, a local `codex` or `claude` installation, and Chrome, Chromium or Edge if the screenshot features are wanted. The package declares `"type": "commonjs"`, exposes the binary `cyberboss` pointing at `./bin/cyberboss.js`, and the entry point is `src/index.js`.

Configuration is read from three places: a `.env` file in the current project directory, `${HOME}/.cyberboss/.env`, and the current shell environment. At minimum the project asks for these four values before the first command runs:

CYBERBOSS_USER_NAME=YourName
CYBERBOSS_USER_GENDER=female
CYBERBOSS_ALLOWED_USER_IDS=your_wechat_user_id
CYBERBOSS_WORKSPACE_ROOT=/absolute/path/to/your/project

`CYBERBOSS_ALLOWED_USER_IDS` is the access control that matters most, since the bridge reads inbound messages from a chat service and the workspace root decides which directory the agent is allowed to work in. The runtime choice is a single variable, `CYBERBOSS_RUNTIME`, set to `codex` or `claudecode`, and the command set stays the same either way. Codex specific variables cover the endpoint, command, model and model provider, while the Claude variables cover the command, model, context window, permission mode and extra arguments, with `CYBERBOSS_CLAUDE_PERMISSION_MODE=default` and `CYBERBOSS_CLAUDE_COMMAND=claude` given as the defaults.

The runnable commands are exposed as package scripts, including these:

"start": "node ./bin/cyberboss.js start",
"login": "node ./bin/cyberboss.js login",
"accounts": "node ./bin/cyberboss.js accounts",
"doctor": "node ./bin/cyberboss.js doctor"

The `login` command covers the WeChat account side of the bridge, `accounts` lists managed accounts, and `doctor` is the environment check to run first. Two further scripts, `start:checkin` and the `shared:start`, `shared:open` and `shared:status` entries, exist for the check-in startup mode and for the shared thread workflow.

Where Cyberboss is a poor fit, and what the licence means

The first constraint is the platform. The bridge speaks to WeChat through a WeChat HTTP bridge with long-poll synchronization, and the endpoint defaults point at `https://ilinkai.weixin.qq.com` with a CDN base URL of `https://novac2c.cdn.weixin.qq.com/c2c`. Anyone whose assistant lives in another messaging platform gets nothing from this project, and the base URL variables show how tightly the design is bound to that one service.

The second constraint is that everything runs on the user's own machine. The diary is local, the queues are local, the WeChat credentials and the location token are local, and the bridge is a long-running Node process. There is no server component in the repository layout, so a team cannot point a shared instance at it without building that layer themselves.

Maintenance and release posture are thin as well. The repository has no GitHub releases, and the last push was on 2026-06-08. The version in `package.json` is `0.1.0` and the package is marked `"private": false`, which leaves room for a future publication, but no published artifact exists to install today. Any decision to depend on this code is a decision to vendor a clone.

The licence is AGPL-3.0, stated as `AGPL-3.0-only` in `package.json` and as AGPLv3 in the project header. That is a strong copyleft licence, and it is worth being explicit about what it does and does not mean here. If you run the bridge as a network service that other users interact with, the licence's network use clause is exactly the situation it was written for. Redistribution of modified versions carries the same obligation. Whether any particular use is compliant is a question for whoever is responsible for compliance, not a reading of this article.

Editorial conclusion

Adopt Cyberboss when you want a Codex or Claude Code runtime reachable from WeChat, when a local timeline and diary are worth more to you than a conventional timer, and when you accept a JavaScript process holding chat history on your own machine. Do not adopt it for a shared or hosted deployment, for a messaging platform other than WeChat, or for a team that needs a released, versioned artifact. Before the first run, check the Node 22 requirement, the runtime you select with CYBERBOSS_RUNTIME, the CYBERBOSS_ALLOWED_USER_IDS restriction and the location server variables, since the bridge answers whoever is allowed in.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. WenXiaoWendy/cyberboss on GitHub