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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions