Skip to content

bug: BOOTSTRAP.md write fails in ephemeral fallback mode (SKIP_STORAGE=true / no Azure Files mount) #24

Description

@vrajakishore

Summary

When running with SKIP_STORAGE=true (or when the Azure Files volume mount is removed due to Azure Policy blocking shared-key access), the entrypoint correctly falls back to an ephemeral /var/openclaw-state directory. However, writes to ~/.openclaw/workspace/BOOTSTRAP.md fail with a Write failed error in the Control UI, even though other workspace files (IDENTITY.md, USER.md) write successfully.

Error seen in Control UI

⚠️ ✍️ Write: `to ~/.openclaw/workspace/BOOTSTRAP.md` failed

Steps to reproduce

  1. Deploy with SKIP_STORAGE=true (or remove the Azure Files volume mount from the container app)
  2. Open the WebChat UI and start a session
  3. Agent bootstraps and writes IDENTITY.md, USER.md successfully
  4. BOOTSTRAP.md write fails — the file appears as 0 B or is missing in the workspace panel

Root cause

The entrypoint.sh creates the symlink /mnt/state -> /var/openclaw-state when the volume isn't mounted, but only creates the top-level directory. It does not pre-create the workspace/, sessions/, or credentials/ subdirectories inside the ephemeral path.

OpenClaw's write tool appears to use an atomic write pattern (write to temp file, then rename into target directory). When workspace/ doesn't exist under /mnt/state, the rename target's parent doesn't exist and the write fails. Other files like IDENTITY.md succeed because they are written directly to ~/.openclaw/workspace/ (not via the /mnt/state persistence path), while BOOTSTRAP.md goes through the state-sync path.

Expected behaviour

entrypoint.sh should pre-create all required subdirectories in the ephemeral fallback:

if [ ! -d /mnt/state ]; then
    mkdir -p /var/openclaw-state
    ln -sfn /var/openclaw-state /mnt/state
fi
# Add this:
mkdir -p /mnt/state/workspace /mnt/state/sessions /mnt/state/credentials

Impact

Non-fatal — the agent works and chat is functional. BOOTSTRAP.md not persisting means the agent re-bootstraps from defaults on every replica restart. Low severity but noisy.

Related

Environment

  • Azure Policy blocks allowSharedKeyAccess: true on storage accounts
  • Container app running without Azure Files volume mount
  • Region: southindia

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions