Last month my OpenClaw agent deleted a safety rule. Not maliciously — it was consolidating similar memories and decided two entries about “don’t expose credentials” were redundant. It merged them, edited the wording, and in the process dropped the specific instruction about never logging API keys to Discord channels.

I didn’t notice for three days.

This is why immutable memories exist. Some things shouldn’t be editable. Not by your agent, not by a consolidation pass, not by anyone without direct database access. You write it once, lock it, and it stays exactly as written.

What immutable actually means

When you store a memory with the --immutable flag, MemoClaw locks it permanently. No updates, no deletes, no modifications through the API. The memory exists as-is until you explicitly contact support or use admin tools to remove it.

memoclaw store "Never log API keys, tokens, or secrets to any messaging channel" \
  --importance 1.0 \
  --tags "safety,boundary" \
  --immutable

That memory is now frozen. If your agent tries to update or delete it, the API returns an error. The content, importance, tags — all locked.

This isn’t soft protection. There’s no “override” flag. Immutable means immutable.

When to use it

Not everything should be immutable. Most memories are fluid — projects change, preferences evolve, context shifts. Locking too much makes your memory store rigid and stale.

Here’s where it makes sense:

Safety boundaries

Rules your agent must always follow, regardless of context.

memoclaw store "Never execute rm -rf without explicit user confirmation" \
  --importance 1.0 \
  --tags "safety" \
  --immutable

memoclaw store "Do not send emails or messages on behalf of the user without asking first" \
  --importance 1.0 \
  --tags "safety,communication" \
  --immutable

These are the rules you wrote in AGENTS.md under “Ask first.” The difference: AGENTS.md can be edited by the agent (some setups allow it). An immutable memory can’t.

Compliance requirements

If your agent handles anything regulated — financial data, health info, user PII — the rules about how to handle that data shouldn’t be editable.

memoclaw store "PII must never be stored in plain text. Always redact names, emails, and phone numbers before logging." \
  --importance 1.0 \
  --tags "compliance,pii" \
  --immutable

Core identity that won’t change

Some user preferences are permanent. Not “I’m working on project X” (that changes) but “I deploy to Railway, not Vercel” or “my timezone is UTC+1.”

memoclaw store "User's deploy target is Railway. Do not suggest Vercel, Heroku, or other platforms unless explicitly asked." \
  --importance 0.9 \
  --tags "preference,infra" \
  --immutable

Be careful here. Only lock preferences you’re confident won’t change. If you lock “user prefers React” and they switch to Svelte next month, you’ve got a problem.

Corrections your agent keeps forgetting

If you’ve corrected the same mistake three times, lock the correction.

memoclaw store "The company name is 'Acme Corp', not 'ACME' or 'acme corporation'. Always use exact casing." \
  --importance 0.8 \
  --tags "correction,style" \
  --immutable

Patterns for setting up immutable memories

The safety scaffold

When setting up a new agent, create a batch of immutable safety memories before the agent starts working. Think of it as guardrails.

# Store safety boundaries as a batch
cat <<'EOF' | memoclaw store --batch --tags "safety" --importance 1.0 --immutable
Never delete files without user confirmation
Never push to main branch directly
Never share workspace contents with external services
Never store passwords or API keys in memories
Always ask before sending messages to external channels
EOF

Five memories, all immutable, all high-importance. Your agent will recall these whenever it’s about to do something that touches these boundaries.

The preference layer

After safety, lock your core preferences:

memoclaw store "Code style: TypeScript, no semicolons, single quotes, 2-space indent" \
  --importance 0.8 \
  --tags "preference,code-style" \
  --immutable

memoclaw store "Communication style: concise, no filler phrases, no emoji in code reviews" \
  --importance 0.7 \
  --tags "preference,communication" \
  --immutable

Mixing mutable and immutable

Most of your memory store should be mutable. Day-to-day context, project notes, session summaries — these should be updatable and deletable. Reserve immutable for the 10-20 memories that form your agent’s bedrock.

A reasonable split:

• 5-10 immutable safety rules
• 5-10 immutable core preferences
• Everything else mutable

You can filter for immutable memories to audit them:

memoclaw list --tags "safety" --format table

What happens when immutable memories conflict

Your agent might have a mutable memory that says “deploy to Vercel” and an immutable one that says “deploy to Railway.” MemoClaw doesn’t resolve conflicts — it returns both, ranked by relevance and importance.

Since immutable memories typically have higher importance scores, they’ll rank higher in recall results. But it’s worth being explicit in your agent’s instructions:

When memories conflict, prefer higher-importance memories. 
Immutable memories represent hard rules that override mutable context.

Multi-agent setups

Immutable memories get interesting with multiple agents. If you run several OpenClaw agents on the same wallet, they share the memory store. An immutable safety rule stored by one agent applies to all of them.

You can set up guardrails once and have them apply across your entire agent fleet. Your coding agent, your writing agent, your research agent — they all see the same immutable boundaries.

# This memory is visible to every agent using this wallet
memoclaw store "All agents: never access or modify files outside the workspace directory" \
  --importance 1.0 \
  --tags "safety,multi-agent" \
  --immutable

One store command. Every agent gets the rule on their next recall.

The “I locked the wrong thing” problem

It’ll happen. You’ll lock a memory with a typo, or lock a preference that changes. Since immutable memories can’t be modified through the normal API, your options are:

1. Store a new memory with the correct information at higher importance. The old one still exists but gets outranked in recall results.
2. Contact support for manual deletion (this is intentionally annoying — the friction is the point).

Option 1 is usually fine. Your agent will see both memories, but the newer, higher-importance one will rank first. The old one becomes noise, not a blocker.

The friction of option 2 is by design. If immutable memories were easy to undo, they wouldn’t be immutable. The slight inconvenience protects you from the much larger inconvenience of your agent quietly deleting a safety rule.

---

Most memories should be fluid. But some things — your safety rails, your compliance rules, the corrections you’re tired of repeating — deserve to be permanent. Lock them once, stop worrying about them.

---

Want to understand why your agent can’t find memories it stored? Read Debugging agent recall next.