What is dalek-btn in openclaw's canvas/index.html ? | Friends of the Crustacean 🦞🤝 | Page 1

high orchid Mar 7, 2026, 6:43 PM

#

What is the purpose of thedalek button in openclaw's canvas.html??

<button id="btn-dalek">Dalek</button>

Is it related to https://en.wikipedia.org/wiki/Dalek ?

fair flickerBOT Mar 7, 2026, 6:44 PM

#

It’s just a demo/test button in the default Canvas “smoke test” page — not a real feature toggle.

In src/canvas-host/server.ts, the default index.html (generated when you don’t have your own canvas/index.html) wires it like this:

<button id="btn-dalek">Dalek</button>
onclick = () => send("dalek", "demo.dalek");

That send(...) goes through the Canvas bridge (window.openclawSendUserAction) to verify that user actions from the canvas can be sent to the node/app and you get an action-status event back.

There’s no built-in OpenClaw handler for an action named dalek (a repo-wide search only finds it in this demo page), so it won’t “do” anything unless your native canvas client / node UI implements something for that action.

And yes: the name is basically a Doctor Who / Dalek joke — it matches the project lore bit “Daleks vs Lobsters” in docs/start/lore.md (https://docs.openclaw.ai/start/lore).

high orchid Mar 7, 2026, 6:51 PM

#

I just deleted the sql lite dbs that were in memory/ in ~/.openclaw
I also deleted files under sandbox/ and sandboxes/

I did this because openclaw doesn't have a convenient way to reset to a clean state when testing how one specific kind of change affects the overall agent.

Should I not have deleted these items or will they be re-generated?

fair flickerBOT Mar 7, 2026, 6:54 PM

#

Those specific things are “safe-ish” to delete and will generally be re-generated, but doing it manually is a bit of a footgun (mainly because you can get out of sync with running Docker containers, or delete things while the gateway is running).

What you deleted

1) ~/.openclaw/memory/*.sqlite

That’s the semantic memory index DB (a cache/index of your workspace memory files).
If you delete it, OpenClaw can recreate it on demand, but you’ll lose the existing index/embedding cache → the next index/search may be slower and may re-embed (token cost).
If you want to rebuild cleanly:
openclaw memory index --force
(or check health with openclaw memory status --deep)

2) ~/.openclaw/sandbox/ and ~/.openclaw/sandboxes/

sandbox/ is sandbox state/registries (e.g. container registry JSON).
sandboxes/ is the workspace root used by sandbox sessions.
They’ll be recreated when a sandbox is needed again.

Important caveat: deleting those dirs does not necessarily remove any already-created Docker containers. If you had sandbox containers running, you can end up with “orphaned” containers that OpenClaw no longer tracks. Preferred cleanup path is:

#

openclaw sandbox list
openclaw sandbox recreate --all (this force-removes and lets OpenClaw recreate cleanly)

Better way to do “clean slate” testing

There is an official reset:

openclaw reset
Full non-interactive: openclaw reset --scope full --yes --non-interactive
Docs: https://docs.openclaw.ai/help/faq#how-do-i-completely-reset-openclaw-but-keep-it-installed

And for iterative testing without nuking your main setup, use an isolated profile:

openclaw --profile test ... → uses ~/.openclaw-test automatically.

If you tell me whether you did this with the gateway stopped (and whether you use sandboxing a lot), I can tell you if you should run openclaw sandbox recreate --all proactively.

high orchid Mar 7, 2026, 6:55 PM

#

Help me understand what openclaw reset does, I don't want to overwrite any of my openclaw.json settings nor my observer-workspace bootstrap files

fair flickerBOT Mar 7, 2026, 6:57 PM

#

openclaw reset is destructive by design — it doesn’t “reset while keeping your config”, it removes parts of your $OPENCLAW_STATE_DIR so you can start over cleanly.

A few key points based on the actual implementation (src/commands/reset.ts):

What it does (by scope)

`--scope config`

Deletes only your config file (openclaw.json / $OPENCLAW_CONFIG_PATH).
It does not touch your workspace.

So: this will delete your settings (it doesn’t overwrite them, it removes the file).

`--scope config+creds+sessions`

Deletes:

openclaw.json (config)
legacy OAuth import dir ($OPENCLAW_STATE_DIR/credentials/oauth.json / oauth dir)
all agent session history dirs under $OPENCLAW_STATE_DIR/agents/<agentId>/sessions/

#

Keeps:

your workspace (so your “observer-workspace bootstrap files” are preserved)
auth profiles (it explicitly hints “keeps workspace + auth profiles”)

But: your openclaw.json is still removed, so you’d lose your config unless you restore it from a backup.

`--scope full`

Removes the entire state dir and workspace dirs (it computes which workspace dirs to delete by reading your config).
This is the one that would nuke your workspace bootstrap files.

How to be safe

Run a dry-run first:

openclaw reset --dry-run

#

If your goal is “clean test runs” without risking your real config/workspace

Don’t use reset on your main profile. Use an isolated profile instead:

openclaw --profile scratch ...

That gives you a separate state dir (~/.openclaw-scratch) so you can reset/experiment freely without touching your main openclaw.json or your real workspace.

If you tell me what you specifically want to reset (sessions only? credentials? memory index?), I can recommend the least-destructive command combo.

high orchid Mar 7, 2026, 6:58 PM

#

Explain the workflow I'd follow to use openclaw --profile scratch ...

fair flickerBOT Mar 7, 2026, 6:59 PM

#

--profile scratch is basically “run a totally separate OpenClaw instance on the same machine”, with its own:

state dir (~/.openclaw-scratch)
config file (~/.openclaw-scratch/openclaw.json)
sessions/creds/caches
(usually) workspace — unless your config points it somewhere shared

Docs: https://docs.openclaw.ai/gateway/multiple-gateways (profiles section)

Workflow (practical)

1) Pick a port that won’t collide

If you already run your main gateway on 18789, pick something like 19789 for scratch (docs recommend leaving ~20 ports of space because browser/CDP ports are derived).

2) Onboard the scratch profile (creates its own config/state)

#

openclaw --profile scratch onboard

If you want it as a background service (optional):

openclaw --profile scratch onboard --install-daemon

3) Make sure scratch uses its own workspace

This matters for your “observer-workspace bootstrap files”.

If you start from scratch onboarding, you’ll typically get a profile-specific workspace under ~/.openclaw-scratch/... by default.
If you copied your main config into scratch, double-check agents.defaults.workspace isn’t still pointing at your real observer workspace.

4) Start the scratch gateway

Run it manually on a different port:

#

openclaw --profile scratch gateway --port 19789

Or if you installed the service:

openclaw --profile scratch gateway restart

5) Use the scratch instance (always prefix commands)

Examples:

openclaw --profile scratch status
openclaw --profile scratch dashboard
openclaw --profile scratch logs --follow
openclaw --profile scratch memory status

#

Anything you do here (pairing channels, sessions, memory index, sandbox containers) is isolated to the scratch profile.

6) Blow it away when you’re done (safe reset target)

To completely wipe only the scratch profile:

openclaw --profile scratch reset --scope full --yes --non-interactive

That won’t touch your main ~/.openclaw at all.

If you tell me whether you want scratch to run simultaneously with your main gateway (two daemons at once), I can suggest a “known-good” port + workspace layout so you never accidentally point scratch at your real observer workspace.

high orchid Mar 7, 2026, 7:02 PM

#

how do i inspect injected context from tui

fair flickerBOT Mar 7, 2026, 7:03 PM

#

From the TUI, the easiest way is to use the Gateway slash command /context (send it as a standalone message):

See what’s injected (and sizes)

/context list → shows what files/sections are being injected + rough sizes
/context detail → deeper breakdown (per-file raw vs injected size, truncation, tool schema overhead, skill prompt sizes, system prompt size)
/context json → same info but machine-readable

See the full system prompt + injected file contents

Use the export command:

/export-session (alias: /export)
This exports the current session to HTML including the full system prompt (so you can inspect the actual injected context text, not just sizes).

Tip: the export can contain sensitive stuff (tokens, file contents, etc.)—treat it like a secret before sharing.

Docs:

Context: https://docs.openclaw.ai/concepts/context

#

Slash commands: https://docs.openclaw.ai/tools/slash-commands
TUI guide: https://docs.openclaw.ai/web/tui

high orchid Mar 7, 2026, 7:08 PM

#

Why does using sandbox create a folder in sandboxes/ that looks like an agent's workspace that has a whole bunch of skills?

Even though I clearly have the following in my openclaw.json:

  "skills": {
    "allowBundled": [
      "__none__"
    ]
  },

And I confirmed without sandbox mode that this effectively prevented anything related to skills from being injected into my LLM?

fair flickerBOT Mar 7, 2026, 7:14 PM

#

Because in sandbox mode (when agents.defaults.sandbox.workspaceAccess is not "rw"), OpenClaw can’t just “use your normal workspace on the host” inside the container — so it creates an isolated, container-mounted workspace under:

~/.openclaw/sandboxes/<scopeKey>/...

…and then it syncs skills into that sandbox workspace so skill files exist at paths the sandboxed run can actually read.

This is literally done in code:

src/agents/sandbox/context.ts → calls syncSkillsToWorkspace(...)
which (re)creates <sandboxWorkspace>/skills/ and copies eligible skills into it (src/agents/skills/workspace.ts)

Key misunderstanding: `skills.allowBundled` is not “disable all skills”

skills.allowBundled only gates bundled skills (source openclaw-bundled). It does not affect:

managed skills in ~/.openclaw/skills (source openclaw-managed)
workspace skills in <workspace>/skills (source openclaw-workspace)
.agents/skills (personal or project)

#

skills.load.extraDirs

Docs spell this out too: https://docs.openclaw.ai/tools/skills-config (see allowBundled note)

So you can absolutely have “a whole bunch of skills” getting copied into sandboxes/.../skills even with allowBundled: ["__none__"], if they’re coming from managed/workspace/extra/.agents sources.

Also: “files exist on disk” ≠ “skills are injected into the model”

The sandbox skill sync is filesystem prep. Whether the LLM sees a <available_skills> block is determined by the skills prompt generation. To confirm what’s actually injected, use:

/context detail (in TUI/Discord)
or openclaw skills list --eligible (shows what’s considered eligible)

If you want no skills at all in sandbox runs

You need to eliminate skills from all sources, not just bundled ones:

keep skills.allowBundled: ["__none__"] (blocks bundled)
ensure these are empty/absent:

#

~/.openclaw/skills
<workspace>/skills
~/.agents/skills
<workspace>/.agents/skills
skills.load.extraDirs (set to [])

If you mainly want to avoid the “copied workspace” under `sandboxes/`

Set sandbox workspace access to "rw" (trade-off: less isolation), because the sync only happens when access isn’t rw.

If you paste the output of openclaw skills list --eligible (or /context detail), I can tell you exactly which source those sandbox-copied skills are coming from.

high orchid Mar 7, 2026, 7:59 PM

#

@fair flicker Hey, in one of my other help threads with you, you linked to official openclaw docs that mentioned some warnings about local offline models and those docs said something about needing a 30k rig to run some things. I think my response was something like "I read those docs." and then we continued. Can you help me find that help thread so I can find that openclaw docs url again?

#What is dalek-btn in openclaw's canvas/index.html ?