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

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

• #22, #23: Other RBAC gaps in the same deployment path
• The SKIP_STORAGE flag is documented as a workaround for Azure Policy restrictions on shared-key storage access

Environment

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

Start by inspecting entrypoint.sh and the SKIP_STORAGE fallback path that creates the /mnt/state symlink. Reproduce the deployment without the Azure Files mount, then verify that workspace, sessions, and credentials are available and that BOOTSTRAP.md writes successfully; done means the fallback no longer produces the Control UI write failure.