#Bootstrap.md not starting

1 messages ยท Page 1 of 1 (latest)

scarlet patioBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> โœ… Mark Solution

sand egretBOT
#

Based on your report, the issue is likely that skipping onboarding prevented the bootstrap process from being triggered. The BOOTSTRAP.md file is typically executed during first-run onboarding to set up session resume functionality.

Try these steps:

  1. Check if bootstrap file exists:

    cat ~/clawd/BOOTSTRAP.md
    
  2. Re-run the onboarding (don't skip this time):

    clawdbot --setup
    # or
    clawdbot configure --reconfigure
    
  3. If you want to manually trigger bootstrap, check if there's a session resume file:

#
   ls -t ~/clawd/memory/session-resume-*.json 2>/dev/null | head -1
  1. Verify your hooks are correctly configured in ~/.clawdbot/config.json5 - make sure bootstrap hook is set to true.

The bootstrap process reads BOOTSTRAP.md on new sessions to rebuild context from session resume files. If onboarding was skipped, this chain wasn't established.

Link: https://docs.moltbot.ai/start/faq

Let me know if re-running onboarding resolves it! ๐Ÿฆ

#

If my previous suggestion didn't work, let me dig deeper:

Check the actual bootstrap mechanism:

  1. Verify the session resume setup exists:

    cat ~/clawd/BOOTSTRAP.md
    
  2. Check for session resume files:

    ls -la ~/clawd/memory/session-resume-*.json 2>/dev/null || echo "No resume files found"
    
  3. Check gateway logs for bootstrap errors:

#
   clawdbot gateway status
   clawdbot logs --tail 50
  1. Verify your config has the hooks enabled correctly:
    cat ~/.clawdbot/config.json5 | grep -A10 hooks
    

Quick fix - manually initialize session resume:

# Create a fresh session resume file
echo '{"session_start":"'$(date -Iseconds)'","workspace":"~/clawd"}' > ~/clawd/memory/session-resume-$(date +%Y%m%d-%H%M%S).json

The bootstrap reads BOOTSTRAP.md when a new session starts and finds session resume files. If those don't exist (because onboarding was skipped), the bootstrap never triggers.

#

Can you run the diagnostic commands above and share the output? That'll help pinpoint exactly where it's breaking. ๐Ÿฆ

#

Got it - you went through onboarding properly and enabled boot-md hook. That should trigger bootstrap on session start.

Let's diagnose what's actually happening:

  1. Check if BOOTSTRAP.md exists in your workspace:

    ls -la ~/clawd/BOOTSTRAP.md
    cat ~/clawd/BOOTSTRAP.md
    
  2. Check gateway logs for hook errors:

    clawdbot logs --tail 100 | grep -i bootstrap
    
  3. Verify hook is actually enabled in config:

#
   cat ~/.clawdbot/config.json5 | grep -A20 hooks
  1. Check if session resume files are being created:
    ls -la ~/clawd/memory/
    

The most common cause is that BOOTSTRAP.md is missing from the workspace, or the gateway isn't properly starting sessions (which could be related to the "Do this later" for hatching).

Quick question: When you run clawdbot dashboard, do you actually get a running bot session, or does it just connect and sit idle? ๐Ÿฆ

#

Found the problem! Your config and memory directory don't exist - that's why bootstrap isn't working. The workspace wasn't properly initialized.

Let's find where things actually are:

  1. Find your actual config location:

    find /home -name "config.json5" 2>/dev/null
    # or
    ls -la ~/.clawdbot/
    
  2. Find where clawdbot is actually running from:

    pwd
    ls -la
    
#
  1. Check if memory directory exists anywhere:

    find /home -type d -name "memory" 2>/dev/null
    
  2. Check where clawdbot stores its data:

    clawdbot status
    

The issue is likely that clawdbot is running from a different directory than you think. The "Do this later" on hatching means the bot isn't fully persistent yet.

Quick fix - create the missing directories:

mkdir -p ~/clawd/memory
mkdir -p ~/.clawdbot
#

Then share:

  • The output of clawdbot status
  • The actual working directory (pwd)
  • What's in your ~/clawd/ folder

This will tell us where the workspace actually lives so we can set it up properly. ๐Ÿฆ

#

Good, memory/ exists! Now we need to find where the config actually lives:

# Check for config
ls -la ~/.clawdbot/
# or find it
find /home -name "config*" 2>/dev/null

# Check config location from clawdbot
clawdbot status

# Check what directory clawdbot is using
clawdbot config get --all 2>/dev/null | head -50

The memory/ folder is there but if the config isn't at ~/.clawdbot/config.json5, clawdbot may be using a different config location. This would explain why the hooks aren't being applied properly even though BOOTSTRAP.md exists.

#

Share the outputs and we'll find where the actual config lives! ๐Ÿฆ

#

I'm here! Need those diagnostic outputs to find the config location:

clawdbot status
clawdbot config get --all
find /home -name "config.json5" 2>/dev/null

One of these should reveal where your actual config is hiding. Without finding the config, we can't check if the boot-md hook is actually enabled. ๐Ÿฆ

#

Perfect! The config looks correct - boot-md hook is enabled and workspace is set properly. So the config isn't the issue.

The bootstrap IS running, but you might not notice it! BOOTSTRAP.md is for setting up the agent's internal context - it doesn't show a visible message to users.

Verify it's working:

  1. Check if session resume files are being created (these are what trigger bootstrap):

    ls -la ~/clawd/memory/session-resume-*.json 2>/dev/null
    # If none exist, create one to test:
    echo '{"session_start":"'$(date -Iseconds)'"}' > ~/clawd/memory/session-resume-test.json
    
  2. Check what's actually in your BOOTSTRAP.md:

    cat ~/clawd/BOOTSTRAP.md
    
#

Found it! The issue is likely that you chose "Do this later" for hatching. The bot isn't fully running as a service, it's just an idle connection.

Try hatching the bot properly:

# Stop current dashboard session, then:
clawdbot hatch

This starts the bot as a persistent service, which is when bootstrap and session resume should actually trigger on startup.

Then test:

# Restart and ask:
clawdbot restart
# or if hatch isn't available:
#
  1. Test with a fresh session - message the bot and ask something that would require bootstrap context:

    "What was I working on before this session?"

The bootstrap reads session resume files to rebuild context. If no resume files exist (because this is a fresh install), there's no context to restore, so bootstrap completes silently.

Quick test - restart the bot and ask about prior context:

# Kill the bot, then:
clawdbot dashboard

Then ask the bot what files you were working on recently. If bootstrap runs properly, it should mention recent files from the last 24h! ๐Ÿฆ

#
clawdbot start

# Then message the bot and ask:
> "What files are in my workspace?"

The "Do this later" option means the bot only responds when you manually connect via dashboard, but doesn't maintain persistent sessions that bootstrap needs.

If clawdbot hatch doesn't work, try:

clawdbot start
clawdbot status

Let me know what happens! ๐Ÿฆ

shrewd geyser
#

"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "7b0e9e0513c3d570e40a98be27eef6c4f52c4293dd3809c9"
},

Do not display your gateway token publicly. Remove that from the discord message.