Project snapshot

Status

In daily use as a private personal system.

Interfaces

Chat and voice interfaces across a small set of personal tools.

Voice

Wake-word detection, voice activity detection, speech-to-text, and neural text-to-speech.

Isolation

Read-only containers, dropped Linux capabilities, Docker secrets, and separate browser/dev sidecars.

Technical proof

• Built on OpenClaw as a hardened containerized stack.
• Skills connect a private set of personal productivity and household workflows.
• Research and development capabilities are isolated from the main assistant runtime.

What it is

Moltbot is a private AI assistant built on OpenClaw, running as a hardened containerized stack. Its interfaces cover chat, voice, and personal automation.

Architecture tour

How a request moves through it

Every channel (chat, voice, and the household integrations) terminates at one OpenClaw gateway container. Around that gateway I run a set of adapter containers, one per channel, each in its own package (voice-adapter, siri-adapter, alexa-adapter, hass-adapter, irc-adapter, whisper-adapter), so a bug or an outage in one channel doesn’t take the others down with it. The gateway itself talks to two separate agents inside OpenClaw: a main agent that does file operations, scheduling, and messaging with no web access, and a research agent that gets web search and a headless browser but only a read-only workspace. That split is the actual security boundary, not a formality: the agent capable of touching my files can’t reach the open internet, and the agent that can reach the internet (and is therefore the one exposed to whatever a fetched page or search result contains) can’t touch anything durable.

Why the isolation is layered, not single-point

The gateway container runs with a read-only filesystem, dropped Linux capabilities, and no-new-privileges. That alone is not enough for a coding assistant, since agents need to write files, install packages, and run dev servers. Rather than loosen the gateway to allow that, I built a separate dev-sidecar container that owns the writable filesystem, its own dependency installs, and its own resource caps (memory, CPU, and process-count limits, plus the same capability drop as the gateway). The gateway reaches it only through a bearer-token-authenticated API. So the assistant can still clone a repo and run npm install, but the container that can be told to write arbitrary files is never the same container that has my credentials or talks to the outside world. Secrets follow the same pattern: they’re injected at container start from mounted files rather than baked into images or passed as plain environment variables in config.

Voice pipeline in detail

Voice input goes through wake-word detection (openwakeword), then voice-activity-gated recording, before anything is sent anywhere. Audio is streamed to a speech-to-text sidecar (whisper-adapter, running faster-whisper locally rather than a cloud STT API) that sits on its own internal-only network with no outbound internet access, since its only job is turning audio into text. Text goes to the gateway, and the response comes back through neural text-to-speech (sherpa-onnx) before playback. I built this to support push-to-talk from a browser or a small satellite device without needing a native mobile app, which is why the voice adapter also serves a small installable web app rather than requiring an app-store build.

Skills, CI, and how changes get validated

Skills (skills/, 18 directories beyond the meta-skills that document how to write skills) cover personal productivity, household automation, and scheduled-briefing workflows, and the assistant can propose changes to its own skills through a pull request rather than editing them live. That PR path is enforced mechanically, not just by convention: a CI check (bot-pr-validator.yml) rejects any bot-authored pull request that touches a file outside skills/, blocks it from modifying the meta-skills that govern skill authoring itself, and scans the diff for path-traversal patterns and known prompt-injection phrasing before a human ever looks at it. A second workflow (ci.yml) blocks direct pushes to the main branch from the bot’s account entirely, runs shellcheck, and validates the Docker Compose and JSON configs on every change, so a bad config can’t merge even with a human reviewing quickly. There’s no automated test suite here: correctness is enforced by those CI gates plus a deploy-time health check before a new build is promoted.

The project has been in active daily use since early 2026 and is continuously extended. It is not open-source. OpenClaw is, and this repo is my hardening and configuration on top of it.