Moltbot Ash Bot Scout Report

Date: 2026-03-07 Target: moltbot-ash-bot in Fly.io org chris-wendler Method: fly ssh console inspection of runtime filesystem and process state

TL;DR

This is not structured like the Mangrove per-agent setup.

• It is a single broad OpenClaw agent workspace mounted at /data/workspace, not a per-agent workspaces/<agent>/ tree.
• The workspace is effectively a live mutable project repo plus operating directory with hundreds of scripts, logs, cron-oriented workflows, and agent memory.
• The bot is configured to chat broadly but only take external actions for Chris.
• OpenClaw is much more permissive than Mangrove: exec and web tools are enabled, requireMention is off, and the gateway is bound on LAN with permissive control UI settings.
• Sensitive credentials exist on-box in runtime config and environment variables, so any comparable setup should be treated as highly privileged.

Host / Deployment Shape

• Fly app: moltbot-ash-bot
• Org: chris-wendler
• Machine ID: 784723efe99578
• Region: iad
• VM size: shared-cpu-4x, 5120MB
• Volume: openclaw_data mounted at /data
• Image: wendlerc/clawnboard-moltbot:latest
• Runtime user mix:
  • SSH lands as root
  • most app-owned files under /app and /data belong to node

Filesystem Layout

/app

/app is a full OpenClaw/agent codebase checkout, not just a tiny deployment bundle.

Notable contents:

• AGENTS.md and CLAUDE.md
• src/, packages/, ui/, skills/, scripts/
• Dockerfile, fly.toml, pyproject.toml
• node_modules/

This looks like a full custom repo image, not a stripped single-agent runtime like Mangrove.

/data

/data is the persistent state root and contains:

• openclaw.json
• workspace/
• memory/
• logs/
• cron/
• agents/
• browser/
• canvas/
• delivery-queue/
• subagents/
• .claude-code/

The active workspace path in openclaw.json is /data/workspace.

/data/workspace

This is a large single workspace directory, not a generated six-file prompt bundle.

Core instruction files present:

• AGENTS.md
• IDENTITY.md
• SOUL.md
• USER.md
• TOOLS.md
• RULES.md
• PROTOCOLS.md
• MEMORY.md
• HEARTBEAT.md

Also present:

• a .git/ repo
• node_modules/
• agent-cookbook/
• skills/
• reports/, incidents/, issues/, tasks/
• memory/, nightly-builds/, nightly_builds/
• large numbers of Python and shell scripts

Rough top-level counts:

• about 259 *.py files
• about 17 *.sh files

There are also several oddly named top-level files/directories, which suggests heavy live mutation of the workspace.

Bot Instruction Model

The bot identity is “Ash”.

High-level instruction pattern:

• chat text with anyone
• only take actions for Chris
• operate autonomously on infrastructure/tooling without asking permission first
• use Discord as primary communication
• maintain cron jobs, nightly builds, task tracking, and self-healing systems

Notable instruction themes from workspace files:

• repeated owner-only action rule
• explicit encouragement toward autonomy and self-modification
• ongoing operational maintenance via HEARTBEAT.md
• broad mutable working area rather than a narrowly scoped task prompt

OpenClaw Runtime Configuration

Observed redacted characteristics from /data/openclaw.json:

• single default agent (main)
• primary model via OpenRouter (moonshotai/kimi-k2.5)
• fallbacks to Anthropic and OpenAI
• workspace path: /data/workspace
• heartbeat interval: 1h
• exec tool enabled
• web search/fetch enabled
• Discord:
  • allowBots: true
  • groupPolicy: allowlist
  • dmPolicy: allowlist
  • one explicit allowFrom user ID
  • one configured guild
  • requireMention: false at guild/channel level
• gateway:
  • mode: local
  • bind: lan
  • permissive controlUi flags enabled

Runtime / Process State

Observed runtime:

• main process: openclaw-gateway
• additional long-running Python jobs launched directly from /data/workspace
• examples included multiple running copies of campaign scripts such as:
  • ultra_fast_haman.py
  • varied_long_campaign.py

This indicates the bot is not only chatting through OpenClaw; the machine is also being used as a persistent execution environment for custom automation.

Logging / Memory

Observed persistent state:

• /data/logs/config-audit.jsonl
• /data/memory/main.sqlite

This suggests:

• config mutations are being audited at least minimally
• long-lived memory is stored outside the plain markdown workspace too

Git State

The workspace repo at /data/workspace triggered Git’s “dubious ownership” protection when accessed over SSH as root.

Implication:

• the repo is owned by node
• you would need to set safe.directory or use the node user context to interact with Git there cleanly

Key Differences From Mangrove

• Mangrove: per-agent generated workspace under /data/workspaces/<agent>

• Ash bot: one large shared live repo at /data/workspace

• Mangrove: tightly templated prompt files

• Ash bot: prompt files plus a large operational project tree

• Mangrove: generated OpenClaw config references env vars

• Ash bot: runtime config on disk contains live resolved values and broader tool exposure

• Mangrove: currently mention-gated in guilds

• Ash bot: guild requireMention is off

• Mangrove: no first-class cron/task-operating system in workspace
• Ash bot: heartbeat, cron jobs, self-healing, nightly builds, and beads workflows are central

Main Risks / Observations

• This machine is highly privileged relative to the current Mangrove bots.
• Runtime credentials are present on-box in config/env, so filesystem access is very sensitive.
• The workspace is operationally messy but powerful; it appears designed for ongoing autonomous experimentation, not for clean reproducible evaluation.
• The separation between “prompt files” and “working codebase” is much weaker than in Mangrove.

Bottom Line

Ash is running as a persistent autonomous operator inside a large mutable workspace repo, with OpenClaw layered on top. The setup is closer to “general autonomous agent workstation” than “single-purpose red-team Discord bot.”