Wyoming Clawdbot
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill appears to do what it says, but it can expose your local Clawdbot session to network-submitted voice prompts unless you restrict it carefully.
Install only if you can run it on a trusted, firewalled network. Restrict the listening address/port to Home Assistant, use a dedicated Clawdbot profile if possible, review or reduce logs, and verify the GitHub source before running the Docker or Python service.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Any device that can reach the listening port may be able to send prompts through your Clawdbot bridge and receive or influence assistant responses.
The bridge listens on all interfaces by default and forwards accepted Wyoming Transcript events to Clawdbot; the shown handler does not authenticate the client or restrict the origin before using the assistant.
parser.add_argument("--host", default="0.0.0.0", help="Host to bind to") ... server = await asyncio.start_server(handle_client, args.host, args.port) ... response_text = await self._call_clawdbot(transcript.text)Bind the service to localhost or a trusted interface, firewall the port so only Home Assistant can connect, and add an authentication or allowlist layer if possible.
Network or voice-submitted prompts may use your existing Clawdbot account/profile, and the compose mount is read-write by default.
The container receives the user's local Clawdbot configuration/profile, so requests handled by the bridge can run under that Clawdbot identity or session.
volumes:
# Share Clawdbot config for gateway connection
- ${HOME}/.clawdbot:/root/.clawdbotUse a dedicated low-privilege Clawdbot profile or token if available, mount only the minimum needed files, consider read-only mounts where workable, and avoid exposing the service outside trusted clients.
Spoken requests and assistant replies may remain in service logs and prior prompts may affect later responses in the same session.
The code logs full transcripts and responses at the default INFO level and supports persistent Clawdbot session context, creating retained/reused voice interaction data without clear retention or clearing controls.
_LOGGER.info("Received transcript: %s", transcript.text) ... _LOGGER.info("Clawdbot response: %s", response_text) ... parser.add_argument("--session-id", help="Clawdbot session id for context")Reduce or redact logging, configure log rotation, avoid speaking sensitive data, and use separate or resettable session IDs for voice-assistant use.
You may run code from a remote repository rather than only the reviewed registry artifact.
The setup asks the user to clone and run an external repository. This is user-directed and consistent with the project purpose, but users should verify the source and version they run.
git clone https://github.com/vglafirov/wyoming-clawdbot.git cd wyoming-clawdbot docker compose up -d
Review the repository, pin to a known commit or release, and verify dependencies before running the Docker or Python setup.
The bridge can keep accepting requests and reusing context until you explicitly stop or reconfigure it.
The Docker configuration keeps the bridge running in the background and uses a persistent session ID. This is expected for a home-assistant bridge, but it is continuous service behavior.
restart: unless-stopped ... command: ["--host", "0.0.0.0", "--port", "10600", "--session-id", "voice-assistant"]
Know how to stop the container/service, disable it when not needed, and periodically reset the voice-assistant session if appropriate.