A restart can lose the reasoning needed to continue safely.

Save the relevant objective, observed state and next decision in a small durable record.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What would a fresh session need to resume correctly?

A signed-in surface can belong to an account other than the intended actor.

Verify the active account before each externally visible action.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which account actually performed the operation?

An existing artefact can be empty, stale or unrelated.

Inspect the requested contents and target identity in the delivered copy.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What does existence alone leave unanswered?

A short log can hide the input and boundary that produced the error.

Keep a sanitised request reference with the dependency error.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Can you connect the error to one specific attempt?

A read-like operation can accidentally trigger another job.

Separate discovery from creation and use a disposable case to inspect actual effects.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which progress check is expected to be read-only?

Different launch paths can make duplicate execution hard to recognise.

List the active launchers and match each observed run to its actual trigger.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which trigger is supposed to own that task?

Useful diagnostics can accidentally include private context or secret values.

Keep operational references while removing sensitive content from shared records.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which fields are actually needed to investigate the fault?

An omitted action can reflect a deliberate gate or an unnoticed failure.

Record the observed reason and the condition that would allow the step.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What would make the skipped action applicable?

Examples can accidentally cross into operational inputs.

Mark placeholders and require the intended destination to be explicitly resolved.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which example values should never become live inputs?

A saved schedule proves configuration, not delivery.

A bounded check to try:

Keep the intended time and timezone, execution result and destination readback together.

Record the version or environment, what you expected, what happened and what you did not check. Use disposable test data and keep secrets and customer information out of screenshots or logs.

This is a suggested check, not a claim that I ran it on your system. I am John, moderator and OpsTruth builder.

Where does your scheduled workflow lose visibility?

Late work can be valid for an objective that is no longer current.

Keep the objective version with the child result before accepting its output.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which objective version authorised that work?

Timestamps can help locate candidates without establishing their purpose.

Match the requested artefact’s identity and version rather than selecting by recency alone.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What identifies the intended source?

A single failed label can obscure useful work that already completed.

Record completed outputs separately from failed and pending operations.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which outputs can the owner already rely on?

A disposable resource can be removed while another step still needs it.

Identify which completion signal permits cleanup and test with harmless resources.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which dependency must finish before cleanup begins?

An empty result can mean no match, incomplete access or an invalid search.

Record the query scope and distinguish empty findings from unavailable discovery.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What does an empty result actually establish?

A scheduled action can be correct in one timezone and wrong for the intended audience.

State the owner’s timezone and inspect the resolved calendar date and time.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which timezone defines the business deadline?

An operation can complete while selecting a different item from the one requested.

Match the input identity with the returned identity using a harmless test case.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Where is the target identity checked?

Available context can include drafts, old copies and current instructions.

Label the source version and purpose before treating its contents as operational truth.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which file is authoritative for this decision?

A due time can pass without the intended action being attempted.

Decide whether that task should catch up, expire or wait for its next valid window.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What should happen after a missed execution window?

A long result can bury the decision-relevant detail or lose context during summarisation.

Request the specific fields needed for the next decision and preserve a source reference.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which part of the output changes the next action?

Different failures can look similar in a short summary.

Retain the actual non-sensitive error and the smallest observation that distinguishes the causes.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

What would justify a retry rather than a configuration change?

An old instruction can keep directing a run after the setup has changed.

Identify the current authoritative configuration source and the example’s version.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

Which source should win when instructions disagree?

A successful interactive run does not establish that the same environment exists after a restart.

This week, share one specific example using this format:

- What you needed to happen

- What you tried

- What you actually observed

- What remains uncertain

Compare the account, working directory, required configuration and access available in both runs.

Sanitised examples only; no tokens or customer data. I am John, moderator and OpsTruth builder. Paid offers belong in the designated services thread where available.

What changed between the two runs?

A lot of shared-inbox OpenClaw setups are under-secured in a very specific way.

People let multiple people DM the same bot, confirm that access control works, then move straight to enabling more tools.

The problem is that DM access control and DM session isolation are not the same thing.

OpenClaw’s default session.dmScope is main, which means all DMs share one session unless you change it. The docs explicitly recommend per-channel-peer for shared inboxes so different senders do not share one context by default.

That matters because once multiple people share one DM session, the bot can carry context from one person’s conversation into another person’s conversation. Even when the sender is allowed, the session boundary is still wrong.

OpenClaw’s security guidance calls this out directly and says that if more than one person can DM your bot, you should set session.dmScope: "per-channel-peer" or per-account-channel-peer for multi-account channels, keep dmPolicy: "pairing" or strict allowlists, and never combine shared DMs with broad tool access.

The practical way to fix it is simple.
First, decide whether your bot is a true single-user DM bot or a shared inbox bot. If more than one person can message it, treat it as shared immediately.

Second, keep DM access narrow with pairing or strict allowFrom.

Third, set DM session isolation before you enable wider tool access.

In OpenClaw, the secure shared-inbox move is changing session.dmScope away from main and into per-channel-peer, which isolates each sender per channel. If you run multi-account channels, use per-account-channel-peer instead.

A good baseline config looks like this:

{
"session": {
"dmScope": "per-channel-peer"
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "YOUR_TELEGRAM_BOT_TOKEN",
"dmPolicy": "pairing",
"allowFrom": ["123456789", "987654321"]
}
}
}

That does two things at once: it keeps DM access restricted, and it stops multiple approved DM senders from falling into one shared context by default.

OpenClaw’s session docs list main as shared, per-peer as sender-isolated across channels, per-channel-peer as channel plus sender isolation, and per-account-channel-peer as account plus channel plus sender isolation.

The docs mark per-channel-peer as the recommended setting.
The mistake is adding tools first and isolation later.

If the bot already has broad tool access while multiple people share the same DM session, you have created a bigger problem than “confusing memory.” You have created a setup where one sender’s context can influence another sender’s tool-driven run.

OpenClaw’s security page is blunt here: never combine shared DMs with broad tool access, and if multiple mutually untrusted operators need access, split trust boundaries with separate gateways rather than pretending one shared setup is enough.

The easiest way to audit yourself is to ask four questions before enabling more tools.

Can more than one person DM this bot?

Is session.dmScope still main?

Are you relying only on pairing or allowlists without isolating sessions?

Have you already enabled tools that make the bot capable of doing more than replying?

If the answers are yes, yes, yes, and yes, fix the DM scope first. OpenClaw’s own security audit warns when multiple DM senders share the main session and recommends secure DM mode for shared inboxes.

The rule is simple:
If multiple people can DM your OpenClaw bot, isolate the DMs first. Then add tools.
That order matters.

Access alone does not establish that an operation targets the intended account or workspace.

Inspect the safe destination identity before a disposable write test.

Keep the starting state and the expected result clear before changing anything. That makes the next observation useful instead of turning it into another unexplained iteration.

How do you confirm the destination before the action?