migrate-from-openclawd

name	migrate-from-openclawd
description	Migrate from OpenClawd to NanoClawd. Detects existing OpenClawd installation, extracts identity, channel credentials, scheduled tasks, and other config, then guides interactive migration. Triggers on "migrate from openclawd", "openclawd migration", "import from openclawd".

Migrate from OpenClawd

Guide the user through migrating their OpenClawd installation to NanoClawd. This is a conversation, not a batch job. Read OpenClawd state, discuss it with the user, make judgment calls together about what to bring over and how.

Principle: Never silently copy data. Read it, explain it, discuss where it belongs in NanoClawd's architecture, show proposed changes before applying. Credentials must be masked when displayed (first 4 + ... + last 4 characters). Make judgment calls about what's core vs. reference material.

UX: Use AskUserQuestion for multiple-choice only. Use plain text for free-form input. Don't dump raw data — summarize and explain conversationally.

Migration State File

Create migration-state.md in the project root at the start of Phase 0. Update it after each phase completes. This file is the single source of truth for the migration — if context is compacted or lost, re-read it to recover all decisions and progress.

Before starting any phase, re-read migration-state.md to ensure you have current state.

Sections to maintain (add data as each phase completes):

• Progress — checkbox list of phases (Phase 0–7)
• Discovery — STATE_DIR, IDENTITY_NAME, channels, groups (with JID mappings), workspace files, cron job count, MCP servers
• Decisions — assistant_name, group_model (shared/separate/main-only), main_group (folder + jid)
• Registered Groups — table: folder, jid, channel, is_main
• Settings Migrated — timezone, anthropic_credential (masked), sender_allowlist (created/skipped)
• Identity & Memory — paths of files created, which CLAUDE.md was edited
• Channel Credentials — table: channel, status, env_var
• Scheduled Tasks — table: original_id, name, migrated/deferred
• Deferred / Not Applicable — unsupported channels, discussed customizations, OpenClawd-only features

Keep it factual and terse — this is for machine recovery after compaction, not human reading. Delete the file at the end of Phase 7 (or offer to keep it as a record).

Phase 0: Discovery

Run the discovery script to find and summarize the OpenClawd installation:

pnpm exec tsx ${CLAUDE_SKILL_DIR}/scripts/discover-openclawd.ts

If the user specifies a custom path, pass it: --state-dir <path>

Parse the status block. Key fields: STATUS, STATE_DIR, CHANNELS, WORKSPACE_FILES, DAILY_MEMORY_FILES, SKILL_COUNT, SKILLS, CRON_JOBS, MCP_SERVERS, IDENTITY_NAME, AGENT_COUNT, AGENT_IDS.

Sanity-check the output: The discovery script detects known structures but can silently miss data if OpenClawd's format has changed. Check CONFIG_TOP_KEYS and CONFIG_CHANNEL_KEYS — if you see keys the script didn't report on (e.g. a channel name not in CHANNELS, or a top-level section like integrations or plugins), read that section of the config directly with the Read tool. Also check STATE_DIR_CONTENTS for directories the script doesn't scan (e.g. unexpected folders alongside workspace/, agents/, cron/).

If STATUS=not_found: Tell the user no OpenClawd installation was detected at the standard locations (~/.openclawd, ~/.clawdbot). Ask if they have a custom path. If not, exit.

If STATUS=found: Present a human-readable summary:

• "I found your OpenClawd installation at <STATE_DIR>."
• Identity: name from IDENTITY.md (if found)
• Workspace files: which of SOUL.md, USER.md, MEMORY.md, IDENTITY.md exist
• Channels: list each, note which NanoClawd supports (whatsapp, telegram, slack, discord) and which it doesn't
• Daily memory files: count (if any)
• Skills: count and names (from workspace, shared, personal, project locations)
• Cron jobs: count and names
• MCP servers: count and names
• Agents: count (relevant for Phase 1 groups discussion)

Then explain the key architectural differences. Don't dump a table — paraphrase conversationally:

• Container isolation: NanoClawd runs each agent in an isolated Linux container (Docker or Apple Container). OpenClawd runs everything in one process. This means stronger isolation but also means each group is its own sandbox.
• Group-based memory: In OpenClawd, all groups under one agent share the same SOUL.md, MEMORY.md, and IDENTITY.md. In NanoClawd, each group has its own filesystem and CLAUDE.md. Shared state goes in groups/global/CLAUDE.md (mounted read-only into all non-main containers).
• Channel skills: In OpenClawd, channels are configured in openclawd.json. In NanoClawd, channels are installed as code via skills (/add-telegram, /add-whatsapp, etc.) and configured through .env variables.
• Simpler config: NanoClawd has no config file — behavior is in the code and CLAUDE.md files. Credentials live in .env or the OneCLI vault.

AskUserQuestion: "Ready to start migrating? I'll go through each area one at a time."

1. Yes, let's go — proceed to Phase 1
2. Tell me more — explain more about any area they ask about
3. Skip migration — exit

Phase 1: Groups and Architecture

This discussion must happen before identity/memory, because the shared-vs-isolated decision determines where files go.

If GROUP_COUNT > 0 or AGENT_COUNT > 1, this is a critical conversation. Even with just one group, explain the model difference so the user understands what they're getting into.

OpenClawd model: All groups routed to the same agent share one workspace — the same SOUL.md, MEMORY.md, IDENTITY.md, and tools. When you talk to the bot in your family chat or your work chat, it's the same agent with the same personality and memory. Only the session (conversation history) is separate per group.

NanoClawd model: Each group is a completely separate agent running in its own Linux container. Separate filesystem, separate memory, separate CLAUDE.md. The bot in your family chat and your work chat are different agents that don't know about each other — unless you explicitly share state via groups/global/CLAUDE.md, which is mounted read-only into all non-main containers.

Explain this conversationally. If the user only has one group, it's simple — just note the difference and move on. If they have multiple groups, discuss:

AskUserQuestion: "In OpenClawd, your groups shared the same personality and memory. In NanoClawd, each group is a fully separate agent. How would you like to handle this?"

1. Shared personality (recommended if your groups had the same bot) — "I'll put the shared personality, identity, and user context in groups/global/CLAUDE.md. Every group sees it. Each group can add its own customizations on top."
2. Fully separate — "Each group gets its own independent personality and memory. Complete isolation between groups."
3. Just main group for now — "Set up one group now. We can add others later."

Remember this choice — it determines where identity and memory files go in the next phase.

Confirm assistant name

Before registering groups, confirm the assistant name — it's used for trigger patterns and CLAUDE.md templates.

IDENTITY_NAME from discovery gives the OpenClawd name. Ask the user: "Your OpenClawd assistant was named <IDENTITY_NAME>. Want to keep this name in NanoClawd?" If they want a different name, ask what it should be. If IDENTITY_NAME was empty, ask them to choose a name (default: "Andy").

The register step's --assistant-name flag writes ASSISTANT_NAME to .env and updates CLAUDE.md templates automatically — no manual .env write needed.

Registering groups

The discovery script provides detected groups in the GROUPS field (format: channel:id(name)=>nanoclawd_jid). These are extracted from OpenClawd's session store and channel config.

For each group the user wants to bring over, pre-register it:

pnpm exec tsx setup/index.ts --step register -- --jid "<nanoclawd_jid>" --name "<group_name>" --folder "<channel>_<slug>" --trigger "@<confirmed_name>" --channel <channel> --assistant-name "<confirmed_name>"

Only pass --assistant-name on the first registration (it updates all CLAUDE.md templates globally).

Folder naming: <channel>_<name-slug> (e.g. whatsapp_family-chat, telegram_dev-team). Ask the user to confirm each group's name and folder.

For the first/primary group, add --is-main --no-trigger-required. Other groups default to requiring a trigger prefix.

Important: Registration requires the database to exist. If the environment step hasn't been run yet, run it first: pnpm exec tsx setup/index.ts --step environment. Registration also creates the group folder under groups/ and copies the CLAUDE.md template.

Register groups from all channels — including channels NanoClawd doesn't yet support (signal, matrix, etc.). The registration stores the JID and metadata in the database, ready for when that channel is added later. Groups won't receive messages until their channel code is installed, but the registration, group folder, and CLAUDE.md will be ready.

Phase 2: Settings from Config

Before identity/memory, extract settings from openclawd.json that map directly to NanoClawd setup. Read the config file with the Read tool (<STATE_DIR>/openclawd.json or clawdbot.json).

Timezone

Check agents.defaults.userTimezone in the config. If present and it's a valid IANA timezone (e.g. America/New_York, Asia/Jerusalem), write it to .env as TZ=<timezone>. NanoClawd's setup step 2a reads TZ from .env (src/config.ts:84-97) and will skip the autodetection prompt.

Anthropic Credentials

Check for Anthropic API keys or tokens in OpenClawd's auth system. OpenClawd stores credentials in <STATE_DIR>/auth-profiles.json or <STATE_DIR>/agents/main/agent/auth-profiles.json with this structure:

{
  "version": 1,
  "profiles": {
    "anthropic:default": {
      "type": "api_key",       // or "token" or "oauth"
      "provider": "anthropic",
      "key": "sk-ant-..."      // for api_key type
    }
  }
}

Profile IDs follow provider:identifier format. Look for any profile where provider is "anthropic". The credential field depends on the type:

• type: "api_key" → key field (or keyRef for SecretRef)
• type: "token" → token field (or tokenRef for SecretRef)
• type: "oauth" → access field (OAuth access token, may need refresh)

Also check:

1. <STATE_DIR>/.env — for ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN
2. Config models.providers — for Anthropic provider entries with apiKey

If found, offer to save to .env. This pre-fills the NanoClawd setup credential step (step 4) so the user doesn't need to re-enter it. Use the same masking approach — show first 4 + last 4 characters, write the full value directly.

Important: If the credential uses keyRef/tokenRef with source:"exec" or source:"file", explain that it can't be auto-extracted and the user will need to enter it during setup. For type: "oauth" credentials with an expiry in the past, warn the user the token may need to be refreshed during setup.

Sender Allowlists

Read the channel configs for access control settings. OpenClawd stores these per-channel:

• channels.<channel>.allowFrom — array of allowed sender IDs (E.164 for WhatsApp, numeric IDs for Telegram)
• channels.<channel>.dmPolicy — "open", "allowlist", "disabled"
• channels.<channel>.groupPolicy — "open", "allowlist", "disabled"
• channels.<channel>.groupAllowFrom — array of allowed group member IDs

NanoClawd uses ~/.config/nanoclawd/sender-allowlist.json with this format:

{
  "default": { "allow": "*", "mode": "trigger" },
  "chats": {
    "<chat-jid>": {
      "allow": ["sender-id-1", "sender-id-2"],
      "mode": "trigger"
    }
  },
  "logDenied": true
}

Fields:

• allow: "*" (all senders) or string[] (specific sender IDs)
• mode: "trigger" (messages stored but trigger blocked for non-allowed senders) or "drop" (messages silently discarded before storage)
• logDenied: optional boolean (default true), logs denied messages

If OpenClawd had allowlists configured, show the user what was set and offer to create the NanoClawd equivalent. Map:

• dmPolicy:"allowlist" + allowFrom → per-chat entry with "allow" array, "mode": "trigger"
• groupPolicy:"allowlist" + groupAllowFrom → per-group entry with "allow" array, "mode": "trigger"
• dmPolicy:"open" → "allow": "*"
• dmPolicy:"disabled" → per-chat entry with "allow": [], "mode": "drop" (or don't register that chat)

Create the directory and file:

mkdir -p ~/.config/nanoclawd

Then write the JSON file. If no allowlists were configured, skip this.

Container Timeout

Check agents.defaults.timeoutSeconds in the config. This is maximum total agent runtime (wall-clock). NanoClawd's equivalent is CONTAINER_TIMEOUT (env var, default 30 min), also configurable per-group via containerConfig.timeout. Note: NanoClawd also has a separate IDLE_TIMEOUT (max time without output) which resets on activity — OpenClawd has no equivalent.

If the OpenClawd value differs significantly from 30 minutes, note it for the user. They can set CONTAINER_TIMEOUT=<ms> in .env after setup.

Phase 3: Identity and Memory

This phase is fully conversational — read files directly and discuss with the user. No script needed.

Where files go depends on the Phase 1 (groups) decision:

• Shared personality: Core identity goes in groups/global/CLAUDE.md (seen by all groups). Group-specific customizations go in each group's own CLAUDE.md.
• Fully separate: Everything goes in groups/main/ (or each group's own folder).
• Just main group: Everything goes in groups/main/.

Find workspace files

The STATE_DIR from discovery tells you where OpenClawd lives. Look for workspace files at <STATE_DIR>/workspace/. If AGENT_COUNT > 1, also check <STATE_DIR>/agents/*/workspace/ and ask which agent to migrate.

Use the Read tool to look at each file found.

IDENTITY.md

Read <STATE_DIR>/workspace/IDENTITY.md if it exists. It uses a key:value format (name, emoji, creature, vibe, etc.).

The assistant name was already confirmed and written to .env in Phase 1. Here, focus on the rest of the identity — create an identity.md file with the full identity details (emoji, creature, vibe, personality traits, etc.). If shared personality was chosen in Phase 1, put it alongside groups/global/CLAUDE.md. Otherwise, put it in groups/main/.

SOUL.md

Read <STATE_DIR>/workspace/SOUL.md if it exists. Then read groups/main/CLAUDE.md.

CLAUDE.md is always loaded into the agent's context — it's the agent's continuous instructions. Not everything from SOUL.md needs to be there. Discuss with the user what belongs where:

• In CLAUDE.md (always loaded): Core personality traits, communication style, key behavioral rules. Weave these into the existing CLAUDE.md structure — adjust the opening description under the # <Name> heading, modify the tone in the Communication section.
• In a separate soul file: Detailed personality backstory, extended guidelines, creative writing style, philosophical grounding — things the agent can reference when relevant but don't need to consume context tokens on every turn.

File placement depends on Phase 1 choice:

• Shared personality → edit groups/global/CLAUDE.md for the core traits, create groups/global/soul.md for the extended content. All groups will see both.
• Separate / main only → edit groups/main/CLAUDE.md, create groups/main/soul.md.

Add a reference in the relevant CLAUDE.md: "Your personality and extended behavioral guidelines are in soul.md. Refer to it for identity questions or when crafting responses that need your full character."

Show proposed edits to the user before applying. This is a thoughtful merge, not a copy-paste.

USER.md

Read <STATE_DIR>/workspace/USER.md if it exists.

Create groups/main/user-context.md with the user information. Add a reference in CLAUDE.md: "Information about your user is in user-context.md. Read it when you need context about who you're talking to."

Ask if they want any critical user facts (name, timezone, key preferences) directly in CLAUDE.md for always-on awareness.

MEMORY.md

Read <STATE_DIR>/workspace/MEMORY.md if it exists.

Show the contents and discuss what's worth keeping. Some memory entries may be stale or OpenClawd-specific. Create groups/main/memories.md for relevant items. Add a reference in CLAUDE.md.

Daily memory files (workspace/memory/*.md)

If DAILY_MEMORY_FILES > 0 in the discovery output, OpenClawd accumulated dated memory files (e.g. 2024-01-01.md). These contain observations, facts, and context gathered over time.

AskUserQuestion: "You have N daily memory files from OpenClawd. How would you like to handle them?"

1. Copy as-is (recommended for many files) — "I'll create a daily-memories/ folder in your group directory and copy them over. Your agent can reference them when needed."

   • Create the folder in the appropriate group directory (per Phase 1 decision)
   • Copy all .md files: cp -r <workspace>/memory/*.md <group_dir>/daily-memories/
   • Add a reference in CLAUDE.md: "Historical daily memory files from your previous system are in daily-memories/. Refer to them when you need context about past events or observations."

2. Consolidate into memories — "I'll read through them, extract the durable facts, and add them to your memories file. This reduces clutter but takes longer."

   • Read each file, extract entries worth keeping (skip transient observations, focus on durable facts about the user, preferences, recurring topics)
   • Consolidate into memories.md
   • Use sub-agents for large volumes (>10 files)

3. Skip — "Don't bring daily memories over."

OpenClawd Skills

If SKILL_COUNT > 0 in discovery, OpenClawd had custom skills. The SKILL.md format is a shared standard — skills are directly portable.

The discovery reports skill names and source locations. For each skill, read just the YAML front matter (name + description at the top of SKILL.md) and present a list to the user: skill name, description, source location. Let the user select which ones to bring over.

For confirmed skills, copy the entire skill directory as-is:

cp -r <skill_source_dir> container/skills/<skill_name>

After all skills are copied, a container rebuild is needed — note this for post-migration: ./container/build.sh.

Config-registered plugins and skills

If CONFIG_PLUGIN_COUNT > 0 in discovery, OpenClawd had installed plugins/skills with API keys (e.g. plugins.entries.brave, skills.entries.openai-whisper-api). These are functional tools the agent had access to.

For each detected plugin, present the name to the user and discuss whether to set it up in NanoClawd. Read the OpenClawd config section to understand what it is, then:

1. If NanoClawd has a matching skill — check the available NanoClawd skills list for an equivalent (e.g. /add-voice-transcription for whisper). If found, save the API key to .env and invoke that skill.

2. If the OpenClawd plugin was an MCP server — read its config to find the exact package name and command. Install the same MCP server (e.g. pnpm dlx <exact-package-from-config>). Don't search for or guess at MCP packages — only install what was explicitly configured.

3. If the OpenClawd plugin was a CLI tool — read the config to identify the exact tool. If it's an npm package, add it to the container's Dockerfile. Add a note to the group's CLAUDE.md that the tool is available and how to invoke it.

4. If the plugin wraps an API — discuss with the user what it did and offer to implement the equivalent: save the API key to .env, write a container skill with instructions for using the API, or wire it into the message flow if it's something automatic (e.g. voice transcription).

5. If unclear — discuss with the user what the plugin did and decide together. Don't install unknown packages or search for replacements — that's a supply chain risk.

For API keys, read the config value directly (don't display raw keys) and write to .env. The discovery script reports which plugins have keys but never extracts them.

Other files (TOOLS.md, HEARTBEAT.md, BOOTSTRAP.md, AGENTS.md)

If these exist, briefly mention them and explain:

• TOOLS.md: NanoClawd agents have their own tool discovery; this doesn't transfer
• HEARTBEAT.md: NanoClawd uses scheduled tasks instead
• BOOTSTRAP.md: NanoClawd uses CLAUDE.md and container skills instead
• AGENTS.md: Already covered in the Phase 1 groups discussion

Phase 4: Channel Credentials

For each channel found in the discovery results, handle it based on NanoClawd support:

Supported channels (whatsapp, telegram, slack, discord)

Run the credential extraction script with --write-env .env so it writes credentials directly to NanoClawd's .env file. The script never emits raw credential values to stdout — only masked versions.

First, run without --write-env to preview:

pnpm exec tsx ${CLAUDE_SKILL_DIR}/scripts/extract-channel-credentials.ts --state-dir <STATE_DIR> --channel <name>

Parse the status block. Key fields: HAS_CREDENTIAL, CREDENTIAL_MASKED, NANOCLAWD_ENV_VAR.

If HAS_CREDENTIAL=false but the user expects a credential: The extraction script may not recognize the config structure. Fall back to reading the channel section of openclawd.json directly with the Read tool and look for any field that contains a token or key value. Ask the user to confirm.

If HAS_CREDENTIAL=true: Show the masked credential (CREDENTIAL_MASKED). AskUserQuestion:

1. Use this credential — run again with --write-env .env to save it
2. Enter a new one — ask in plain text, write to .env manually
3. Skip this channel — don't configure

If using the credential:

pnpm exec tsx ${CLAUDE_SKILL_DIR}/scripts/extract-channel-credentials.ts --state-dir <STATE_DIR> --channel <name> --write-env .env

The script writes the credential directly to .env using the correct NanoClawd variable name (e.g. TELEGRAM_BOT_TOKEN). Check the status block for WRITTEN_TO and WRITTEN_COUNT to confirm.

Credential destination note: Credentials are saved to .env for now. During /setup, the credential step will either keep them in .env (Apple Container) or migrate them to the OneCLI vault (Docker). The user doesn't need to worry about this now.

For Slack: there are two credentials (bot token + app token). The script handles both in one run — check HAS_CREDENTIAL_2 and NANOCLAWD_ENV_VAR_2 in the status block.

WhatsApp special case: WhatsApp uses QR/pairing-code authentication, not a token. Do not copy auth state from OpenClawd — encryption sessions become stale after copying and messages fail to decrypt. Authentication will be handled during /setup via the /add-whatsapp skill (takes about 60 seconds with a pairing code). Just note that WhatsApp was configured and move on.

Allowlist note: If the channel had allowFrom or group policies, these were already handled in Phase 2 (sender allowlists). Mention that the allowlist file was created earlier.

Unsupported channels (signal, matrix, irc, msteams, feishu, etc.)

Explain briefly: "NanoClawd doesn't have a <channel> integration yet, but channels are added over time via skills. Any groups from this channel were already registered in Phase 1 — they'll activate when the channel is added."

If there are credentials (tokens, keys) for the unsupported channel, offer to save them to .env with a descriptive variable name (e.g. SIGNAL_ACCOUNT, MATRIX_ACCESS_TOKEN) so they're available when the channel is eventually supported.

Don't invoke channel skills here — just prepare .env credentials. Channel code is installed during /setup.

Phase 5: Scheduled Tasks

Read <STATE_DIR>/cron/jobs.json with the Read tool. If the file doesn't exist or has no jobs, skip this phase.

If jobs exist, read ${CLAUDE_SKILL_DIR}/MIGRATE_CRONS.md for the full OpenClawd cron format, NanoClawd table schema, field mapping, and SQL insert template. Follow those instructions for each job.

Phase 6: Webhooks, MCP, and Other Config

Read relevant sections from <STATE_DIR>/openclawd.json directly with the Read tool. This phase is fully conversational.

MCP Servers

If MCP_SERVERS was non-empty in discovery, these can be ported. Claude Code supports MCP servers natively. Read the OpenClawd config's mcp.servers section to get each server's details (command, args, env, url).

MCP servers in NanoClawd are registered in the agent-runner source code. Before editing, grep for mcpServers in container/agent-runner/src/ to find the current location — it's expected to be in index.ts in the query() options, but may have moved. For each OpenClawd MCP server the user wants to bring over:

1. Read its config: command, args, env, url
2. stdio servers (have command): Add an entry to the mcpServers object in container/agent-runner/src/index.ts. The command runs inside the container, so it needs to be available there (Node.js/npx-based servers work; custom binaries would need to be added to the Dockerfile).
3. HTTP/SSE servers (have url): These work if the URL is accessible from inside the container. Add them the same way.
4. Environment variables: Any env values that reference secrets should be added to .env and passed through via process.env.* in the mcpServers entry.

After adding all MCP servers, a container rebuild is needed: ./container/build.sh

Show the user each server and ask which to bring over. For servers that need custom binaries not available in the container, note them for manual setup.

Webhooks and Endpoints

If the config has webhook sections (in cron.webhook, cron.failureDestination, or channel-specific webhooks):

• Explain what they were used for
• These don't map directly but NanoClawd can be customized to support them
• Discuss the use case with the user and propose a solution if it's important to them
• For simple webhook notifications: a task script with curl often suffices

Other Config

Scan the config for notable sections and briefly mention anything that doesn't carry over:

• Exec approvals / command allowlist: NanoClawd uses container isolation instead — the agent runs with --dangerously-skip-permissions inside a sandboxed container
• Human delay: Not applicable in NanoClawd's container model
• Compaction: Handled by Claude Code SDK automatically
• TTS: Not built into NanoClawd
• Model configuration: NanoClawd uses whatever Anthropic model the credential provides access to

Don't belabor these — just mention and move on.

Phase 7: Summary

Summary

Print a comprehensive summary:

Migrated:

• Assistant name → .env ASSISTANT_NAME + CLAUDE.md templates updated
• Groups → registered in database, folders created with CLAUDE.md templates
• Timezone → .env TZ
• Anthropic credential → .env (for setup to pick up)
• Sender allowlists → ~/.config/nanoclawd/sender-allowlist.json
• Personality → CLAUDE.md (core) + soul.md (extended), placed per Phase 1 decision (global or per-group)
• User context → user-context.md
• Memories → memories.md + daily memory files (copied to daily-memories/ or consolidated)
• OpenClawd skills → copied to container/skills/
• Channel credentials → .env (list which channels)
• Scheduled tasks → inserted into database or noted for post-setup
• MCP servers → registered in agent-runner

Noted for later:

• Channel code installation (happens during /setup)
• Task creation (if deferred due to no registered group yet)
• Container rebuild needed (if skills or MCP servers were added): ./container/build.sh

Not applicable:

• Unsupported channels (list them — groups registered for future)
• OpenClawd-specific features (exec approvals, human delay, TTS, model config, session reset policies, etc.)

Discussed and deferred:

• List any customizations agreed on but not yet implemented

Remind: "Run /setup next to complete your NanoClawd installation. Channel credentials are already prepared in .env. When setup asks which channels to enable, select the ones we configured."

Troubleshooting

Config parse error: If openclawd.json fails to parse, it may use JSON5 features the parser doesn't handle. Ask the user to check the file for unusual syntax. As a fallback, the agent can read the file directly and work with it manually.

Credential not found: If a channel credential resolves to empty, it may use source:"exec" or source:"file" SecretRef. These can't be auto-extracted. Ask the user to provide the value directly.

Multi-agent complexity: If the user had many agents with different configs, focus on the primary/default agent first. Additional agents can be set up as separate NanoClawd groups later.