← View index

OpenClaw docs capability audit — safe step

過去レポートのView/ソース規律バックフィルで生成したView。

Generated: 2026-05-10T14:35:05+09:00

This is a read-only/internal audit step. It reads local OpenClaw docs and runtime/config snapshots. It does not change config, restart Gateway, or send external messages.

Source docs sampled

gateway/heartbeat.md

---
summary: "Heartbeat polling messages and notification rules"
read_when:
  - Adjusting heartbeat cadence or messaging
  - Deciding between heartbeat and cron for scheduled tasks
title: "Heartbeat"
sidebarTitle: "Heartbeat"
---

<Note>
**Heartbeat vs cron?** See [Automation & Tasks](/automation) for guidance on when to use each.
</Note>

Heartbeat runs **periodic agent turns** in the main session so the model can surface anything that needs attention without spamming you.

Heartbeat is a scheduled main-session turn — it does **not** create [background task](/automation/tasks) records. Task records are for detached work (ACP runs, subagents, isolated cron jobs).

Troubleshooting: [Scheduled Tasks](/automation/cron-jobs#troubleshooting)

## Quick start (beginner)

<Steps>
  <Step title="Pick a cadence">
    Leave heartbeats enabled (default is `30m`, or `1h` for Anthropic OAuth/token auth, including Claude CLI reuse) or set your own cadence.
  </Step>
  <Step title="Add HEARTBEAT.md (optional)">
    Create a tiny `HEARTBEAT.md` checklist or `tasks:` block in the agent workspace.
  </Step>
  <Step title="Decide where heartbeat messages should go">
    `target: "none"` is the default; set `target: "last"` to route to the last contact.
  </Step>
  <Step title="Optional tuning">
    - Enable heartbeat reasoning delivery for transparency.
    - Use lightweight bootstrap context if heartbeat runs only need `HEARTBEAT.md`.
    - Enable isolated sessions to avoid sending full conversation history each heartbeat.
    - Restrict heartbeats to active hours (local time).

  </Step>
</Steps>

Example config:

{

agents: {

defaults: {

heartbeat: {

every: "30m",

target: "last", // explicit delivery to last contact (default is "none")

directP


### automation/cron-jobs.md

---

summary: "Scheduled jobs, webhooks, and Gmail PubSub triggers for the Gateway scheduler"

read_when:

- Scheduling background jobs or wakeups

- Wiring external triggers (webhooks, Gmail) into OpenClaw

- Deciding between heartbeat and cron for scheduled tasks

title: "Scheduled tasks"

sidebarTitle: "Scheduled tasks"

---

Cron is the Gateway's built-in scheduler. It persists jobs, wakes the agent at the right time, and can deliver output back to a chat channel or webhook endpoint.

Quick start

<Steps>

<Step title="Add a one-shot reminder">

```bash

openclaw cron add \

--name "Reminder" \

--at "2026-02-01T16:00:00Z" \

--session main \

--system-event "Reminder: check the cron docs draft" \

--wake now \

--delete-after-run

```

</Step>

<Step title="Check your jobs">

```bash

openclaw cron list

openclaw cron show <job-id>

```

</Step>

<Step title="See run history">

```bash

openclaw cron runs --id <job-id>

```

</Step>

</Steps>

How cron works


### automation/tasks.md

---

summary: "Background task tracking for ACP runs, subagents, isolated cron jobs, and CLI operations"

read_when:

- Inspecting background work in progress or recently completed

- Debugging delivery failures for detached agent runs

- Understanding how background runs relate to sessions, cron, and heartbeat

title: "Background tasks"

sidebarTitle: "Background tasks"

---

<Note>

Looking for scheduling? See [Automation and tasks](/automation) for choosing the right mechanism. This page is the activity ledger for background work, not the scheduler.

</Note>

Background tasks track work that runs outside your main conversation session: ACP runs, subagent spawns, isolated cron job executions, and CLI-initiated operations.

Tasks do not replace sessions, cron jobs, or heartbeats — they are the activity ledger that records what detached work happened, when, and whether it succeeded.

<Note>

Not every agent run creates a task. Heartbeat turns and normal interactive chat do not. All cron executions, ACP spawns, subagent spawns, and CLI agent commands do.

</Note>

TL;DR

in-memory runtime state is gone, task maintenance first checks durable cron

run history before marking a task lost.

requester session/heartbeat when it finishes, so status polling loops are

usually the wrong shape.


### automation/taskflow.md

---

summary: "Task Flow flow orchestration layer above background tasks"

read_when:

- You want to understand how Task Flow relates to background tasks

- You encounter Task Flow or openclaw tasks flow in release notes or docs

- You want to inspect or manage durable flow state

title: "Task flow"

---

Task Flow is the flow orchestration substrate that sits above [background tasks](/automation/tasks). It manages durable multi-step flows with their own state, revision tracking, and sync semantics while individual tasks remain the unit of detached work.

When to use Task Flow

Use Task Flow when work spans multiple sequential or branching steps and you need durable progress tracking across gateway restarts. For single background operations, a plain [task](/automation/tasks) is sufficient.

| Scenario | Use |

| ------------------------------------- | -------------------- |

| Single background job | Plain task |

| Multi-step pipeline (A then B then C) | Task Flow (managed) |

| Observe externally created tasks | Task Flow (mirrored) |

| One-shot reminder | Cron job |

Reliable scheduled workflow pattern

For recurring workflows such as market intelligence briefings, treat the schedule, orchestration, and reliability checks as separate layers:

  1. Use [Scheduled Tasks](/automation/cron-jobs) for timing.
  2. Use a persistent cron session when the workflow should build on prior context.
  3. Use [Lobster](/tools/lobster) for deterministic steps, approval gates, and resume tokens.
  4. Use Task Flow to track the multi-step run across child tasks, waits, retries, and gateway restarts.

Example cron shape:

openclaw cron add \
  --name "Market intelligence brief

automation/standing-orders.md

---
summary: "Define permanent operating authority for autonomous agent programs"
read_when:
  - Setting up autonomous agent workflows that run without per-task prompting
  - Defining what the agent can do independently vs. what needs human approval
  - Structuring multi-program agents with clear boundaries and escalation rules
title: "Standing orders"
---

Standing orders grant your agent **permanent operating authority** for defined programs. Instead of giving individual task instructions each time, you define programs with clear scope, triggers, and escalation rules — and the agent executes autonomously within those boundaries.

This is the difference between telling your assistant "send the weekly report" every Friday vs. granting standing authority: "You own the weekly report. Compile it every Friday, send it, and only escalate if something looks wrong."

## Why standing orders

**Without standing orders:**

- You must prompt the agent for every task
- The agent sits idle between requests
- Routine work gets forgotten or delayed
- You become the bottleneck

**With standing orders:**

- The agent executes autonomously within defined boundaries
- Routine work happens on schedule without prompting
- You only get involved for exceptions and approvals
- The agent fills idle time productively

## How they work

Standing orders are defined in your [agent workspace](/concepts/agent-workspace) files. The recommended approach is to include them directly in `AGENTS.md` (which is auto-injected every session) so the agent always has them in context. For larger configurations, you can also place them in a dedicated file like `standing-orders.md` and reference it from `AGENTS.md`.

Each program specifies:

1. **Scope** — what the agent is authorized to do
2. **Triggers** — when t

concepts/commitments.md

---
summary: "Inferred follow-up memory for check-ins that are not exact reminders"
title: "Inferred commitments"
sidebarTitle: "Commitments"
read_when:
  - You want OpenClaw to remember natural follow-ups
  - You want to understand how inferred check-ins differ from reminders
  - You want to review or dismiss follow-up commitments
---

Commitments are short-lived follow-up memories. When enabled, OpenClaw can
notice that a conversation created a future check-in opportunity and remember
to bring it back later.

Examples:

- You mention an interview tomorrow. OpenClaw may check in afterward.
- You say you are exhausted. OpenClaw may ask later whether you slept.
- The agent says it will follow up after something changes. OpenClaw may track
  that open loop.

Commitments are not durable facts like `MEMORY.md`, and they are not exact
reminders. They sit between memory and automation: OpenClaw remembers a
conversation-bound obligation, then heartbeat delivers it when it is due.

## Enable commitments

Commitments are off by default. Enable them in config:

openclaw config set commitments.enabled true

openclaw config set commitments.maxPerDay 3


Equivalent `openclaw.json`:

{

"commitments": {

"enabled": true,

"maxPerDay": 3

}

}


`commitments.maxPerDay` limits how many inferred follow-ups can be delivered
per agent session in a rolling day. The default is `3`.

## How it works

After an agent reply, OpenClaw may run a hidden background extraction pass in a
separate context. That pass looks only for inferred follow-up commitments. It
does not write into the visible conversation and it does not ask the main agent
to reason about the extraction.

When it finds a high-confidence candidate, OpenClaw stores a commitment with:

- the agent id
- the

concepts/memory.md

---
summary: "How OpenClaw remembers things across sessions"
title: "Memory overview"
read_when:
  - You want to understand how memory works
  - You want to know what memory files to write
---

OpenClaw remembers things by writing **plain Markdown files** in your agent's
workspace. The model only "remembers" what gets saved to disk — there is no
hidden state.

## How it works

Your agent has three memory-related files:

- **`MEMORY.md`** — long-term memory. Durable facts, preferences, and
  decisions. Loaded at the start of every DM session.
- **`memory/YYYY-MM-DD.md`** — daily notes. Running context and observations.
  Today and yesterday's notes are loaded automatically.
- **`DREAMS.md`** (optional) — Dream Diary and dreaming sweep
  summaries for human review, including grounded historical backfill entries.

These files live in the agent workspace (default `~/.openclaw/workspace`).

<Tip>
If you want your agent to remember something, just ask it: "Remember that I
prefer TypeScript." It will write it to the appropriate file.
</Tip>

## Inferred commitments

Some future follow-ups are not durable facts. If you mention an interview
tomorrow, the useful memory may be "check in after the interview," not "store
this forever in `MEMORY.md`."

[Commitments](/concepts/commitments) are opt-in, short-lived follow-up memories
for that case. OpenClaw infers them in a hidden background pass, scopes them to
the same agent and channel, and delivers due check-ins through heartbeat.
Explicit reminders still use [scheduled tasks](/automation/cron-jobs).

## Memory tools

The agent has two tools for working with memory:

- **`memory_search`** — finds relevant notes using semantic search, even when
  the wording differs from the original.
- **`memory_get`** — reads a specific memory file

concepts/dreaming.md

---
summary: "Background memory consolidation with light, deep, and REM phases plus a Dream Diary"
title: "Dreaming"
sidebarTitle: "Dreaming"
read_when:
  - You want memory promotion to run automatically
  - You want to understand what each dreaming phase does
  - You want to tune consolidation without polluting MEMORY.md
---

Dreaming is the background memory consolidation system in `memory-core`. It helps OpenClaw move strong short-term signals into durable memory while keeping the process explainable and reviewable.

<Note>
Dreaming is **opt-in** and disabled by default.
</Note>

## What dreaming writes

Dreaming keeps two kinds of output:

- **Machine state** in `memory/.dreams/` (recall store, phase signals, ingestion checkpoints, locks).
- **Human-readable output** in `DREAMS.md` (or existing `dreams.md`) and optional phase report files under `memory/dreaming/<phase>/YYYY-MM-DD.md`.

Long-term promotion still writes only to `MEMORY.md`.

## Phase model

Dreaming uses three cooperative phases:

| Phase | Purpose                                   | Durable write     |
| ----- | ----------------------------------------- | ----------------- |
| Light | Sort and stage recent short-term material | No                |
| Deep  | Score and promote durable candidates      | Yes (`MEMORY.md`) |
| REM   | Reflect on themes and recurring ideas     | No                |

These phases are internal implementation details, not separate user-configured "modes."

<AccordionGroup>
  <Accordion title="Light phase">
    Light phase ingests recent daily memory signals and recall traces, dedupes them, and stages candidate lines.

    - Reads from short-term recall state, recent daily memory files, and redacted session transcripts when available.
    - Writes a managed `## Light Sleep` bl

concepts/queue.md

---
summary: "Auto-reply queue modes, defaults, and per-session overrides"
read_when:
  - Changing auto-reply execution or concurrency
  - Explaining /queue modes or message steering behavior
title: "Command queue"
---

We serialize inbound auto-reply runs (all channels) through a tiny in-process queue to prevent multiple agent runs from colliding, while still allowing safe parallelism across sessions.

## Why

- Auto-reply runs can be expensive (LLM calls) and can collide when multiple inbound messages arrive close together.
- Serializing avoids competing for shared resources (session files, logs, CLI stdin) and reduces the chance of upstream rate limits.

## How it works

- A lane-aware FIFO queue drains each lane with a configurable concurrency cap (default 1 for unconfigured lanes; main defaults to 4, subagent to 8).
- `runEmbeddedPiAgent` enqueues by **session key** (lane `session:<key>`) to guarantee only one active run per session.
- Each session run is then queued into a **global lane** (`main` by default) so overall parallelism is capped by `agents.defaults.maxConcurrent`.
- When verbose logging is enabled, queued runs emit a short notice if they waited more than ~2s before starting.
- Typing indicators still fire immediately on enqueue (when supported by the channel) so user experience is unchanged while we wait our turn.

## Defaults

When unset, all inbound channel surfaces use:

- `mode: "steer"`
- `debounceMs: 500`
- `cap: 20`
- `drop: "summarize"`

`steer` is the default because it keeps the active model turn responsive without
starting a second session run. It drains all steering messages that arrived
before the next model boundary. If the current run cannot accept steering,
OpenClaw falls back to a followup queue entry.

## Queue modes

Inbound messages

concepts/retry.md

---
summary: "Retry policy for outbound provider calls"
read_when:
  - Updating provider retry behavior or defaults
  - Debugging provider send errors or rate limits
title: "Retry policy"
---

## Goals

- Retry per HTTP request, not per multi-step flow.
- Preserve ordering by retrying only the current step.
- Avoid duplicating non-idempotent operations.

## Defaults

- Attempts: 3
- Max delay cap: 30000 ms
- Jitter: 0.1 (10 percent)
- Provider defaults:
  - Telegram min delay: 400 ms
  - Discord min delay: 500 ms

## Behavior

### Model providers

- OpenClaw lets provider SDKs handle normal short retries.
- For Stainless-based SDKs such as Anthropic and OpenAI, retryable responses
  (`408`, `409`, `429`, and `5xx`) can include `retry-after-ms` or
  `retry-after`. When that wait is longer than 60 seconds, OpenClaw injects
  `x-should-retry: false` so the SDK surfaces the error immediately and model
  failover can rotate to another auth profile or fallback model.
- Override the cap with `OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>`.
  Set it to `0`, `false`, `off`, `none`, or `disabled` to let SDKs honor long
  `Retry-After` sleeps internally.

### Discord

- Retries on rate-limit errors (HTTP 429), request timeouts, HTTP 5xx responses,
  and transient transport failures such as DNS lookup failures, connection
  resets, socket closes, and fetch failures.
- Uses Discord `retry_after` when available, otherwise exponential backoff.

### Telegram

- Retries on transient errors (429, timeout, connect/reset/closed, temporarily unavailable).
- Uses `retry_after` when available, otherwise exponential backoff.
- Markdown parse errors are not retried; they fall back to plain text.

## Configuration

Set retry policy per provider in `~/.openclaw/openclaw.json`:

{

chann


### gateway/sandboxing.md

---

summary: "How OpenClaw sandboxing works: modes, scopes, workspace access, and images"

title: "Sandboxing"

sidebarTitle: "Sandboxing"

read_when: "You want a dedicated explanation of sandboxing or need to tune agents.defaults.sandbox."

status: active

---

OpenClaw can run tools inside sandbox backends to reduce blast radius. This is optional and controlled by configuration (agents.defaults.sandbox or agents.list[].sandbox). If sandboxing is off, tools run on the host. The Gateway stays on the host; tool execution runs in an isolated sandbox when enabled.

<Note>

This is not a perfect security boundary, but it materially limits filesystem and process access when the model does something dumb.

</Note>

What gets sandboxed

<AccordionGroup>

<Accordion title="Sandboxed browser details">

- By default, the sandbox browser auto-starts (ensures CDP is reachable) when the browser tool needs it. Configure via agents.defaults.sandbox.browser.autoStart and agents.defaults.sandbox.browser.autoStartTimeoutMs.

- By default, sandbox browser containers use a dedicated Docker network (openclaw-sandbox-browser) instead of the global bridge network. Configure with agents.defaults.sandbox.browser.network.

- Optional agents.defaults.sandbox.browser.cdpSourceRange restricts container-edge CDP ingress with a CIDR allowlist (for example 172.21.0.1/32).

- noVNC observer access is password-protected by default; OpenClaw emits a short-lived token URL that serves a local bootstrap page and opens noVNC with password in URL fragment (not query/header logs).

- `agents.defaults.sandbox.browser.allowHos


### gateway/sandbox-vs-tool-policy-vs-elevated.md

---

summary: "Why a tool is blocked: sandbox runtime, tool allow/deny policy, and elevated exec gates"

title: Sandbox vs tool policy vs elevated

read_when: "You hit 'sandbox jail' or see a tool/elevated refusal and want the exact config key to change."

status: active

---

OpenClaw has three related (but different) controls:

  1. Sandbox (agents.defaults.sandbox.* / agents.list[].sandbox.*) decides where tools run (sandbox backend vs host).
  2. Tool policy (tools.*, tools.sandbox.tools.*, agents.list[].tools.*) decides which tools are available/allowed.
  3. Elevated (tools.elevated.*, agents.list[].tools.elevated.*) is an exec-only escape hatch to run outside the sandbox when you’re sandboxed (gateway by default, or node when the exec target is configured to node).

Quick debug

Use the inspector to see what OpenClaw is _actually_ doing:

openclaw sandbox explain
openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work
openclaw sandbox explain --json

It prints:

Sandbox: where tools run

Sandboxing is controlled by agents.defaults.sandbox.mode:

See [Sandboxing](/gateway/sandboxing) for the full matrix (scope, workspace mounts, images).

Bind mounts (security quick check)


### channels/telegram.md

---

summary: "Telegram bot support status, capabilities, and configuration"

read_when:

- Working on Telegram features or webhooks

title: "Telegram"

---

Production-ready for bot DMs and groups via grammY. Long polling is the default mode; webhook mode is optional.

<CardGroup cols={3}>

<Card title="Pairing" icon="link" href="/channels/pairing">

Default DM policy for Telegram is pairing.

</Card>

<Card title="Channel troubleshooting" icon="wrench" href="/channels/troubleshooting">

Cross-channel diagnostics and repair playbooks.

</Card>

<Card title="Gateway configuration" icon="settings" href="/gateway/configuration">

Full channel config patterns and examples.

</Card>

</CardGroup>

Quick setup

<Steps>

<Step title="Create the bot token in BotFather">

Open Telegram and chat with @BotFather (confirm the handle is exactly @BotFather).

Run /newbot, follow prompts, and save the token.

</Step>

<Step title="Configure token and DM policy">

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

Env fallback: TELEGRAM_BOT_TOKEN=... (default account only).

Telegram does not use openclaw channels login telegram; configure token in config/env, then start gateway.

</Step>

<Step title="Start gateway and approve first DM">

openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Pairing codes expire after 1 hour.

</Step>

<Step title="Add the bot to a group">

Add the bot to your group, then set channels.telegram.groups and groupPolicy to match your access model.

</Step>

</Steps>

<Note>

Token resolution order is account-aw


### gateway/health.md

---

summary: "Health check commands and gateway health monitoring"

read_when:

- Diagnosing channel connectivity or gateway health

- Understanding health check CLI commands and options

title: "Health checks"

---

Short guide to verify channel connectivity without guessing.

Quick checks

For Discord and other chat providers, session rows are not socket liveness.

openclaw sessions, Gateway sessions.list, and the agent sessions_list tool

read stored conversation state. A provider can reconnect and show healthy channel

status before any new session row is materialized. Use the channel status and

health commands above for live connectivity checks.

Deep diagnostics


### gateway/diagnostics.md

---

summary: "Create shareable Gateway diagnostics bundles for bug reports"

title: "Diagnostics export"

read_when:

- Preparing a bug report or support request

- Debugging Gateway crashes, restarts, memory pressure, or oversized payloads

- Reviewing what diagnostics data is recorded or redacted

---

OpenClaw can create a local diagnostics zip for bug reports. It combines

sanitized Gateway status, health, logs, config shape, and recent payload-free

stability events.

Treat diagnostics bundles like secrets until you have reviewed them. They are

designed to omit or redact payloads and credentials, but they still summarize

local Gateway logs and host-level runtime state.

Quick start

openclaw gateway diagnostics export

The command prints the written zip path. To choose a path:

openclaw gateway diagnostics export --output openclaw-diagnostics.zip

For automation:

openclaw gateway diagnostics export --json

Chat command

Owners can use /diagnostics [note] in chat to request a local Gateway export.

Use this when the bug happened in a real conversation and you want one

copy-pasteable report for support:

  1. Send /diagnostics in the conversation where you noticed the problem. Add a

short note if it helps, for example /diagnostics bad tool choice.

  1. OpenClaw sends the diagnostics preamble and asks for one explicit exec

approval. The approval runs openclaw gateway diagnostics export --json.

Do not approve diagnostics through an allow-all rule.

  1. After approval, OpenClaw replies with a pasteable report containing the local

bundle path, manifest summary, privacy notes, and relevant session ids.

In group chats, an owner can still run /diagnostics, but OpenClaw does not

post the diagnostic details back into th


## Runtime/config snapshots

### openclaw config get agents.defaults.heartbeat

Exit: 0

{

"every": "30m",

"target": "last",

"directPolicy": "allow",

"prompt": "Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. First run scripts/gateway_restart_resume_watch.py to resume safe post-restart checks from any approved restart checkpoint. Then run scripts/task_recovery_watch.py and scripts/task_autonomy_recovery_watch.py; if any recovery watcher prints output, send that concise recovery update. If all are quiet, run scripts/task_autonomy_step.py. If it reports idle, reply HEARTBEAT_OK. If it reports a status change, warning, blocked state, or user attention needed, send that concise update; otherwise reply HEARTBEAT_OK.",

"ackMaxChars": 300,

"lightContext": true,

"skipWhenBusy": true

}


### openclaw config get commitments

Exit: 0

{

"enabled": true,

"maxPerDay": 10

}


### openclaw tasks audit

Exit: 0

Tasks audit: 0 findings · 0 errors · 0 warnings

Task findings: 0 · TaskFlow findings: 0

No tasks audit findings.


### openclaw cron list

Exit: 0

ID Name Schedule Next Last Status Target Delivery Agent ID Model

0a6a28ee-5fe6-42ee-9bbe-e63120e9dc26 OpenClaw watchdog: Te... every 10m in <1m 10m ago ok isolated announce -> telegram:7789180125 (explicit) main -

92e9cbdd-69ce-46bb-9bbf-c684068ba773 Sync OpenClaw convers... every 5m in 2m 3m ago ok isolated not requested (not requested) main -

40ab7f7c-9259-4a19-b6ad-3a26451d200c Sync Claude recall to... cron 5 9 * * * @ Asia/Tokyo (... in 18h 6h ago ok current not requested (not requested) main -


### openclaw sandbox explain --json

Exit: 0

{

"docsUrl": "https://docs.openclaw.ai/sandbox",

"agentId": "main",

"sessionKey": "agent:main:main",

"mainSessionKey": "agent:main:main",

"sandbox": {

"mode": "off",

"scope": "agent",

"workspaceAccess": "none",

"workspaceRoot": "/Users/aiharataketo/.openclaw/sandboxes",

"sessionIsSandboxed": false,

"tools": {

"allow": [

"exec",

"process",

"read",

"write",

"edit",

"apply_patch",

"image",

"sessions_list",

"sessions_history",

"sessions_send",

"sessions_spawn",

"sessions_yield",

"subagents",

"session_status"

],

"deny": [

"browser",

"canvas",

"nodes",

"cron",

"gateway",

"feishu",

"wecom",

"googlechat",

"nostr",

"msteams",

"mattermost",

"nextcloud-talk",

"matrix",

"bluebubbles",

"line",

"zalo",

"yuanbao",

"zalouser",

"synology-chat",

"tlon",

"discord",

"imessage",

"irc",

"qqbot",

"signal",

"slack",

"telegram",

"twitch",

"whatsapp"

],

"sources": {

"allow": {

"source": "default",

"key": "tools.sandbox.tools.allow"

},

"deny": {

"source": "default",

"key": "tools.sandbox.tools.deny"

}

}

}

},

"elevated": {

"enabled": true,

"allowedByConfig": false,

"alwaysAllowedByConfig": false,

"allowFrom": {},

"failures": []

},

"fixIt": [

"tools.sandbox.tools.allow",

"tools.sandbox.tools.alsoAllow",

"tools.sandbox.tools.deny",

"agents.list[].tools.sandbox.tools.allow",

"agents.list[].tools.sandbox.tools.alsoAllow",

"agents.list[].tools.sandbox.tools.deny",

"tools.elevated.enabled"

]

}


### openclaw memory status

Exit: 0

Memory Search (main)

Provider: auto (requested: auto)

Model: auto

Sources: memory

Indexed: 3/3 files · 151 chunks

Dirty: no

Store: ~/.openclaw/memory/main.sqlite

Workspace: ~/.openclaw/workspace

Dreaming: off

By source:

memory · 3/3 files · 151 chunks

Vector store: unknown

FTS: ready

Embedding cache: enabled (0 entries)

Batch: disabled (failures 0/2)

Recall store: 64 entries · 0 promoted · 64 concept-tagged · 2 spaced · scripts=60 latin, 4 mixed

Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json

Recall updated: 2026-05-10T05:33:56.862Z

Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent

Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus

Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json

質問したい箇所を選択
この箇所について質問
✓ 質問を送信しました