ClaudeClaw: a personal assistant daemon built on your Claude Code subscription

An assistant that uses the subscription you already have

ClaudeClaw is described as a lightweight, open source OpenClaw version built into your Claude Code, and the README expands that into turning your Claude Code into a personal assistant that never sleeps. It runs as a background daemon, executes tasks on a schedule, responds to messages on Telegram, Discord and Slack, transcribes voice commands, and integrates with any service you need. The differentiator against OpenClaw is set out in a comparison table, and the row that matters most is API overhead, where ClaudeClaw is said to use your Claude Code subscription directly while OpenClaw is described as a nightmare on that axis, with setup said to take around five minutes, deployment said to be installing Claude Code on any device or VPS and running it, isolation said to be folder based and isolated as needed rather than global by default, memory said to use Claude's internal memory system along with `CLAUDE.md`, and feature scope said to be the lightweight features you actually use. The framing is competitive, so read it as the author's opinion rather than as a benchmark. The engineering point underneath it is real, though. A daemon that reuses an existing agent runtime inherits that runtime's tools, its memory and its model access, and does not have to reimplement any of them.

Installing it is three commands

The plugin is distributed through the Claude Code plugin marketplace, so the install is two commands followed by one slash command inside a session.

claude plugin marketplace add moazbuilds/claudeclaw
claude plugin install claudeclaw

Then you open a Claude Code session and run `/claudeclaw:start`, and the setup wizard walks you through the model, the heartbeat, Telegram, Discord, Slack and security, after which the daemon is live with a web dashboard. The wizard shape matters for a tool with this many integrations, because it means the order of configuration is guided rather than something you have to infer from a README. The project also documents a contributor convention that says something about how it is maintained. If you change shipped plugin files under `src/`, `commands/`, `prompts/` or `.claude-plugin/`, the plugin metadata version may also need to be bumped so that Claude Code and marketplace consumers detect the update correctly, and two helper scripts do that, one to bump the plugin version and one to bump the marketplace version. Changes that are documentation only do not need them. The runtime is Bun, with a `bun test` script for the test suite and separate entry points for the daemon, the Telegram transport, the Discord transport and a status command.

Scheduling and the three chat transports

The automation features are the substance of the tool. The heartbeat is a periodic check-in with configurable intervals, quiet hours and editable prompts, which is the difference between an assistant that pings you and one that respects your night. Cron jobs are timezone aware and cover repeating or one time tasks with reliable execution, which matters for anyone outside UTC. The communication side covers three platforms with different shapes. Telegram handles text, image and voice. Discord covers DMs, server mentions and replies, slash commands, voice messages and image attachments. Slack uses a Socket Mode bot, with DMs, channel mentions, threads, voice messages and file attachments, configured through `SLACK_BOT_TOKEN` and `SLACK_APP_TOKEN` in your environment or in `settings.json`. There is also a time awareness feature, where message time prefixes help the agent understand delays and daily patterns, which is a small trick that has a large effect on how sensible a scheduled agent sounds. On the reliability side there is a GLM fallback, so the assistant continues with GLM models when your primary limit is reached, and a web dashboard for managing jobs, monitoring runs and inspecting logs in real time.

Discord threads each get their own session

The multi-session thread support in Discord is the feature with the most interesting design, and it is documented separately in `docs/MULTI_SESSION.md` and in a `MULTI_SESSION_SPEC.md` at the repository root. Each Discord thread gets its own Claude CLI session, fully isolated from the main channel. Thread conversations run concurrently, so messages in different threads do not block each other. The first message in a new thread automatically bootstraps a fresh session, with no setup needed. Sessions are cleaned up automatically when the threads are deleted or archived, which is the detail that decides whether the feature is usable, since an assistant that accumulates orphaned sessions is a resource leak and a privacy problem. And the behaviour is backward compatible, with DMs and main channel messages continuing to use the global session. The isolation model is the point here, and it connects to the row in the comparison table about folder based isolation, since the per-thread session is the same idea applied at thread granularity.

Two releases tightened who can drive the daemon

The upgrading notes are the most instructive part of the README, because they show the project reacting to real exposure. In v1.0.26 the allowlist behaviour changed for Telegram and Discord. Previously an empty `allowedUserIds` list meant allow everyone, and the README calls that a potential security vulnerability, since any Telegram or Discord user could drive the daemon. The new behaviour is that an empty list blocks everyone, and the daemon refuses to start if a bot token is configured without at least one allowed user ID. The migration is to add your user IDs to `settings.json` before upgrading, and `claudeclaw config` gives guided setup if you are unsure of your ID.

"telegram": { "allowedUserIds": [123456789] },
"discord":  { "allowedUserIds": ["987654321012345678"] }

In v1.1.0 the web UI gained a bearer token gate. All the `/api/*` routes, except `/api/health`, now require an `Authorization: Bearer <token>` header, the token is auto generated on first start and written to `.claude/claudeclaw/web.token`, and the daemon prints the full URL with the token embedded when the web UI starts. Existing `/api/inject` users who configured `settings.apiToken` are unaffected, since that fallback still works. The design here is sensible, since a dashboard on localhost that can inject work into an agent deserves a token, and printing the URL with the token embedded makes the first use easy while the file keeps it out of your shell history.

The Discord attachment cap, and the project's own limits

The other v1.1.0 change is a regression in capability rather than a hardening. Text attachments sent to the Discord bot are now truncated at 2,048 bytes, down from 51,200, with payloads over the limit getting an ellipsis and a truncated marker appended silently, and there is no config knob to restore the old limit. The migration advice is to switch to gists or another file sharing mechanism and paste the URL instead, which is a reasonable suggestion and a real loss of function for anyone who used attachments to move a file into a session. Two other limits are worth stating. The README asks readers not to use ClaudeClaw for hacking any bank system or doing illegal activities, which is a request rather than a control, and the real control is the allow list and the token gate described above. And the project describes itself as lightweight, with a feature scope of the features you actually use, so a reader arriving from a larger agent platform should expect a smaller surface, not a better one.

How the project is put together

The repository is a Bun project with TypeScript sources, a `bun.lock` file, a `tsconfig.json` and a package manifest whose only runtime dependency is an Opus audio decoder, which is a good indication of how small the footprint is. The `src/` directory holds the daemon entry points, the `commands/` directory holds the slash commands, `prompts/` and `skills/` hold the prompt material, `hooks/` the lifecycle hooks and `scripts/` the maintenance helpers including the two version bump scripts. There is a `tests/` directory run with `bun test`, an `examples/` directory with heartbeat and python examples, a `docs/` directory, and specification documents at the root in the shape of `MULTI_SESSION_SPEC.md`, `RESTART_RESUME_SPEC.md` and `TASK.md`, plus a `CLAUDE.md` and a `CONTRIBUTING.md`. The licence is MIT. The maintenance signal is moderate rather than strong, since the last push was on 2026-07-19 and the repository publishes no GitHub releases, and the roadmap is an open issue where the author asks people to vote on what to build next.

Editorial conclusion

Adopt ClaudeClaw if you already pay for Claude Code and want scheduled work and chat driven access to it from your phone or your chat client, and you are willing to run a daemon with access to your machine. Do not adopt it as a general agent platform, because the README positions it as a deliberately lightweight alternative to a much larger project, and do not expose it to the internet without reading the security section, since the daemon is a remote control for an agent with your permissions. Before you enable a chat integration, set the allow lists, because the current behaviour of an empty list is to block everyone and the daemon refuses to start without one, and keep the web token out of scripts that a third party can read. The licence is MIT, the last push was on 2026-07-19, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. moazbuilds/claudeclaw on GitHub
4. README