#memory wiki setup

1 messages · Page 1 of 1 (latest)

icy delta
#

I am openclaw version 2026.4.9 -- I added memory wiki to openclaw json but get this error upon gateway restart: Invalid config at /Users/openclaw/.openclaw/openclaw.json:\n- memory: Unrecognized key: "memory-wiki"

"memory": {
    "backend": "qmd",
    "citations": "auto",
    "memory-wiki": {
      "enabled": true,
      "config": {
        "vaultMode": "bridge",
        "bridge": {
          "enabled": true,
          "readMemoryArtifacts": true,
          "indexDreamReports": true,
          "indexDailyNotes": true,
          "indexMemoryRoot": true,
          "followMemoryEvents": true
        },
        "search": {
          "backend": "shared",
          "corpus": "all"
        },
        "context": {
          "includeCompiledDigestPrompt": false
        }
      }
    },
    "qmd": {
      "command": "/Users/openclaw/.bun/bin/qmd",
      "searchMode": "search",
      "includeDefaultMemory": true,
      "paths": [
        {
          "path": "/Users/openclaw/.openclaw/charlotte-workspace/knowledge",
          "name": "knowledge",
          "pattern": "**/*.md"
        }
      ],
      "update": {
        "interval": "5m",
        "onBoot": true
      }
    }
  },
pliant topazBOT
pseudo daggerBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

pliant topazBOT
vocal walrusBOT
#

Yep, the problem is the config location.

memory-wiki is not a key under memory. It’s a plugin, so it belongs under:

plugins.entries."memory-wiki"

Your memory block should only keep the QMD settings.

Use this shape instead:

{
  memory: {
    backend: "qmd",
    citations: "auto",
    qmd: {
#
      command: "/Users/openclaw/.bun/bin/qmd",
      searchMode: "search",
      includeDefaultMemory: true,
      paths: [
        {
          path: "/Users/openclaw/.openclaw/charlotte-workspace/knowledge",
          name: "knowledge",
          pattern: "**/*.md",
        },
      ],
      update: {
        interval: "5m",
        onBoot: true,
      },
    },
#
  },

  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
#
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },
    },
  },
}

A couple notes:

#
  • If you already have a plugins section, merge this into the existing plugins.entries block, don’t create a second plugins.
  • The error happens because the memory schema only accepts things like backend, citations, and qmd.

After changing it, I’d run:

openclaw gateway restart
openclaw wiki doctor

Docs:

I think the QMD + bridge example in the docs is a bit misleading here, so you’re not crazy 😅

If you want, paste your full top-level plugins block and I can sanity-check the merged version.

icy delta
#

what is renderMode parameter?

vocal walrusBOT
#

It controls how the wiki files are written/rendered in the vault.

Specifically:

  • vault.renderMode: "native"
    OpenClaw’s normal wiki output, no Obsidian-specific behavior.

  • vault.renderMode: "obsidian"
    Writes Obsidian-friendly Markdown and can integrate with the official Obsidian CLI.

So if you want the wiki to live nicely inside an Obsidian vault, use obsidian.
If you’re just using memory-wiki internally, leave it native or omit it for now.

Also, the setting lives here:

icy delta
#

Ok here's what I have nested under "plugins"

"memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge",
          "vault": {
            "path": "~/.openclaw/wiki/main"
          },
          "bridge": {
            "enabled": true,
            "readMemoryArtifacts": true,
            "indexDreamReports": true,
            "indexDailyNotes": true,
            "indexMemoryRoot": true,
            "followMemoryEvents": true
          },
          "ingest": {
            "autoCompile": true,
            "maxConcurrentJobs": 1,
            "allowUrlIngest": true
          },
          "search": {
            "backend": "shared",
            "corpus": "all"
          },
          "context": {
            "includeCompiledDigestPrompt": false
          },
          "render": {
            "preserveHumanBlocks": true,
            "createBacklinks": true,
            "createDashboards": true
          }
        }
      },

And here's my memory

"memory": {
    "backend": "qmd",
    "citations": "auto",
    "qmd": {
      "command": "/Users/openclaw/.bun/bin/qmd",
      "searchMode": "search",
      "includeDefaultMemory": true,
      "paths": [
        {
          "path": "/Users/openclaw/.openclaw/charlotte-workspace/knowledge",
          "name": "knowledge",
          "pattern": "**/*.md"
        }
      ],
      "update": {
        "interval": "5m",
        "onBoot": true
      }
    }
  },

Looks good? I have currently one agent workspace (charlotte-workspace) at the moment. But plan to add more agents in the future.

vocal walrusBOT
#

Yep, that looks good to me, with one important gotcha:

It must be under plugins.entries, not directly under plugins.

So the shape needs to be:

plugins: {
  entries: {
    "memory-wiki": {
      enabled: true,
      config: {
        vaultMode: "bridge",
        vault: {
          path: "~/.openclaw/wiki/main",
        },
#
        bridge: {
          enabled: true,
          readMemoryArtifacts: true,
          indexDreamReports: true,
          indexDailyNotes: true,
          indexMemoryRoot: true,
          followMemoryEvents: true,
        },
        ingest: {
          autoCompile: true,
          maxConcurrentJobs: 1,
          allowUrlIngest: true,
        },
        search: {
          backend: "shared",
#
          corpus: "all",
        },
        context: {
          includeCompiledDigestPrompt: false,
        },
        render: {
          preserveHumanBlocks: true,
          createBacklinks: true,
          createDashboards: true,
        },
      },
    },
  },
}
#

A few notes:

  • Your memory block looks fine.
  • vault.path: "~/.openclaw/wiki/main" is actually a nice choice for future multi-agent use, since it gives you one shared wiki location.
  • Your QMD config currently only indexes:
    • /Users/openclaw/.openclaw/charlotte-workspace/knowledge

So when you add more agent workspaces later, you’ll probably also want to add their knowledge dirs to memory.qmd.paths if you want QMD to search them too.

For now, I’d say this is a solid setup 👍

After saving, I’d test with:

openclaw gateway restart
openclaw wiki doctor
icy delta
#
Wiki doctor: 1 issue(s) found

Wiki vault mode: bridge
Vault: ready (/Users/openclaw/.openclaw/wiki/main)
Render mode: native
Obsidian CLI: missing
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 619 sources, 0 entities, 0 concepts, 288 syntheses, 5 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 619 other

Warnings:
- Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.

Suggested fixes:
- Use a memory plugin that exports public artifacts, create/import memory artifacts first, or switch the wiki back to isolated mode.
Wiki vault mode: bridge
Vault: ready (/Users/openclaw/.openclaw/wiki/main)
Render mode: native
Obsidian CLI: missing
Bridge: enabled (0 exported artifacts)
Unsafe local: disabled
Pages: 619 sources, 0 entities, 0 concepts, 288 syntheses, 5 reports
Source provenance: 0 native, 0 bridge, 0 bridge-events, 0 unsafe-local, 619 other

Warnings:
- Bridge mode is enabled but the active memory plugin is not exporting any public memory artifacts yet.

Note: in wiki/main I have index.md populated and md files in sources and md files in syntheses I don't think I ran wiki compile before.

vocal walrusBOT
#

This actually looks mostly healthy now.

What wiki doctor is telling you:

  • Vault: ready → config is valid, plugin is loading
  • Obsidian CLI: missing → not a problem unless you want wiki obsidian ...
  • Bridge: enabled (0 exported artifacts) → this is the real warning

So the issue is no longer config parsing. Now it’s just:

bridge mode is on, but there’s nothing exported from the active memory layer for the wiki to import yet.

A couple important clarifications:

  • The files you already see in wiki/main/sources and wiki/main/syntheses are real wiki content, so the wiki is definitely working.
  • wiki compile is still worth running, but it will only compile what’s already in the vault. It does not by itself create bridge artifacts.
#

I’d do this next:

openclaw wiki compile
openclaw wiki bridge import
openclaw wiki status

How I’d interpret your setup:

If your goal is:

“I want a wiki over my current markdown now”
Use isolated mode.

If your goal is:

“I want memory-wiki to ingest exported memory artifacts from the memory layer over time”
Keep bridge mode, but expect that warning until the active memory side is actually exporting something public.

#

So short version:
not broken anymore, just bridge mode has nothing to bridge yet.

If you want, I can help you decide whether bridge or isolated is the better fit for your exact Charlotte setup.

icy delta
#

Compiled wiki vault at /Users/openclaw/.openclaw/wiki/main (912 pages, 0 indexes updated).

vocal walrusBOT
#

Nice, that means the compile worked

Compiled wiki vault ... (912 pages, 0 indexes updated) is generally a good result:

  • 912 pages = the vault was successfully processed
  • 0 indexes updated = no index files needed changes on that run, not an error

So at this point:

  • your config is loading
  • the wiki vault is compiling
  • the remaining bridge warning is probably just “nothing exported to bridge yet”, not a broken setup

I’d just sanity check with:

#
openclaw wiki doctor
openclaw wiki status

If those look clean enough for your use case, you’re basically in business.

If you want, next step I can help with:

  1. deciding whether to stay on bridge or switch to isolated, or
  2. setting this up cleanly for multiple agent workspaces.

Glad we got past the config error 😌

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

icy delta
#

Should I run bridge import now?

vocal walrusBOT
#

You can, but with doctor showing:

  • Bridge: enabled (0 exported artifacts)

…I’d expect bridge import to be basically a no-op right now.

So my take:

  • Safe to run once as a sanity check
  • Don’t expect it to change anything yet

If you run:

openclaw wiki bridge import
#

and it says nothing/new imports, that’s totally consistent with the current status.

Recommendation:

  • If you’re just testing, run it once
  • If it imports nothing, that’s fine, and I’d stop there for now
  • Re-run it later only after the memory side is actually exporting public artifacts

So: yes, but mostly for confirmation, not because I think it’ll do much yet.

icy delta
#

Ok got it. Looks like we are good now. What is the main difference between bridge mode and isolated mode?

I currently have a cron that distills stuff from my knowledge base and then places them into the wiki/main/synthesis folder

vocal walrusBOT
#

Main difference, pretty simply:

isolated

The wiki is its own source of truth.

  • you write/import pages directly into the wiki vault
  • the wiki does not depend on exported memory artifacts
  • best when your own cron/jobs are already populating sources/ or syntheses/

bridge

The wiki is a compiled layer on top of the active memory system.

  • it imports public artifacts from the active memory plugin
  • useful when you want memory to own recall/dreaming/etc, and wiki to organize that output
  • best when the memory side is actually exporting things to bridge in

Given what you said:

#

cron distills stuff from my knowledge base and places it into wiki/main/syntheses

…I’d honestly say isolated sounds like the cleaner fit.

Why:

  • your cron is already treating the wiki as the destination
  • you’re not really relying on bridge imports
  • your earlier doctor output showed bridge had 0 exported artifacts anyway

So my recommendation:

  • stay on bridge only if you expect OpenClaw’s memory layer to start exporting artifacts that the wiki should ingest
  • otherwise switch to isolated and treat the wiki as the maintained knowledge vault directly

For your setup, I’d probably choose isolated.

Also, after your cron writes new syntheses, it’s a good idea to run:

#
openclaw wiki compile

and optionally:

openclaw wiki lint

Docs: https://docs.openclaw.ai/plugins/memory-wiki

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

icy delta
#

What does wiki lint do?

vocal walrusBOT
#

It’s basically a health check for the wiki, not a Markdown style linter.

openclaw wiki lint looks for things like:

  • structural issues
  • provenance gaps
  • contradictions
  • open questions
  • low-confidence pages/claims
  • stale pages/claims

So for your setup, it’s useful after your cron writes/updates syntheses, because it can catch stuff like:

  • a synthesis with weak or missing sources
  • stale pages that need refresh
  • contradictory claims across pages
  • incomplete wiki structure
#

Good mental model:

  • wiki compile = build/refresh the wiki
  • wiki lint = sanity-check the wiki

Docs: https://docs.openclaw.ai/cli/wiki

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

icy delta
#

How often should wiki compile and wiki lint be run?

vocal walrusBOT
#

Good default:

  • wiki compile: run after each batch of wiki changes
  • wiki lint: run less often, like daily/nightly or after major updates

For your setup, since you have a cron writing into wiki/main/syntheses/, I’d recommend:

Practical schedule

  • your distill cron writes/updates pages
  • then run openclaw wiki compile at the end of that cron
  • run openclaw wiki lint nightly or after especially important updates

Why:

  • compile refreshes dashboards, related blocks, and compiled digests
  • lint is more of a QA pass, not something you need on every tiny change
#

So the simple version is:

  • compile often
  • lint periodically

If your cron runs very frequently, like every few minutes, I’d batch it a bit:

  • compile: every 30 to 60 min, or after meaningful batches
  • lint: once per day

One extra nuance: ingest.autoCompile mainly helps when using wiki ingest.
If your cron writes files directly into the vault, I’d still explicitly run wiki compile after it.

Docs: https://docs.openclaw.ai/cli/wiki

icy delta
#

What does this QMD error mean?

memory {"subsystem":"memory"} qmd collection add skipped for memory-alt-main: qmd collection add /Users/openclaw/.openclaw/charlotte-workspace --name memory-alt-main --glob memory.md failed (code 1): A collection already exists for this path and pattern:
  Name: memory-root-main (qmd://memory-root-main/)
  Pattern: **/*.md

Use 'qmd update' to re-index it, or remove it first with 'qmd collection remove memory-root-main'

04:55:01+00:00 info gateway {"subsystem":"gateway"} qmd memory startup initialization armed for agent "main"
04:56:26+00:00 warn plugins {"subsystem":"plugins"} [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-telegram-file-browser (/Users/openclaw/.openclaw/extensions/.openclaw-install-stage-aFBEzk/index.ts). Set plugins.allow to explicit trusted ids.
vocal walrusBOT
#

That QMD message basically means:

OpenClaw tried to add a new QMD collection for memory.md, but QMD says that workspace is already covered by an existing broader collection.

In your log:

  • attempted new collection: memory-alt-main
  • existing collection: memory-root-main
  • existing pattern: **/*.md

So QMD is saying, “I already index this area, don’t add another overlapping collection.”

What that means in practice

Usually this is more annoying than dangerous.

If memory search is still working, I’d read this as:

#
  • memory.md is probably already getting indexed via the broader memory-root-main collection
  • the extra add attempt got skipped because it would be redundant

So this does not look like a memory-wiki problem.

Separate warning

This part is unrelated:

plugins.allow is empty; discovered non-bundled plugins may auto-load...

That means you have a non-bundled extension installed:

  • openclaw-telegram-file-browser

…and OpenClaw is warning that without plugins.allow, discovered extensions may auto-load. That’s a security/trust warning, not a QMD failure.

#

My read

  • QMD warning: likely safe to ignore if search/indexing behaves normally
  • plugins warning: worth cleaning up later by setting an explicit plugins.allow

If the QMD warning keeps happening on every startup and you notice indexing weirdness, I’d call that worth a GitHub issue, because it looks like OpenClaw is trying to register an overlapping collection it should probably recognize upfront.

If you want, paste the output of openclaw status --all and I can help tell whether this is harmless noise or something actually broken.

icy delta
#
Diagnosis (read-only)

Gateway connection details:
  Gateway target: ws://127.0.0.1:18789
  Source: local loopback
  Config: /Users/openclaw/.openclaw/openclaw.json
  Bind: loopback

✓ Config: /Users/openclaw/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

Gateway last log line:
  2026-04-17T12:56:26.793+08:00 [plugins] openclaw-telegram-file-browser: loaded without install/load-path provenance; treat as untracked local code and pin trust via plugins.allow or install records (/Users/openclaw/.openclaw/extensions/.openclaw-install-stage-aFBEzk/index.ts)
! Port 18789
  Port 18789 is already in use.
  - pid 56629 openclaw: openclaw-gateway (127.0.0.1:18789)
  - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 42 eligible · 0 missing · /Users/openclaw/.openclaw/charlotte-workspace
✓ Plugin compatibility (none)
vocal walrusBOT
#

This looks pretty healthy, honestly.

What I see:

  • Config is valid
  • Gateway is already running
  • Port 18789 is in use by OpenClaw itself → not a real problem, just means you already have a gateway on that port
  • No secret/config diagnostics
  • No plugin compatibility issues

So from this report, I do not see evidence that the earlier QMD message is breaking anything.

The only real warning here

This line:

#
openclaw-telegram-file-browser: loaded without install/load-path provenance

means you have a non-bundled plugin sitting in the extensions dir, and OpenClaw is warning that it’s effectively untracked local code unless you pin trust with plugins.allow.

That’s more of a security/trust warning than a runtime failure.

My read overall

I’d interpret your current state as:

  • memory/wiki setup is basically working
  • the earlier QMD collection warning is probably harmless overlap/noise
  • the thing worth cleaning up later is the plugin trust warning

Also, this part:

#
! Port 18789 is already in use.
- pid 56629 openclaw: openclaw-gateway

just means “don’t start a second gateway on the same port.” It’s not saying the running one is bad.

So unless you’re seeing actual symptoms, like bad recall, missing wiki results, or failed indexing, I’d stop worrying about the QMD warning for now.

If you want a practical final check, the best test is just:

  • does memory_search behave normally?
  • does wiki_search behave normally?

If yes, I’d call this good.

icy delta
#

Does my openclaw agent automatically know how to use wiki_search and stuff since I have the plugin installed or must I specify?

vocal walrusBOT
#

Usually yes, automatically.

If memory-wiki is enabled and loaded, it registers the tools:

  • wiki_status
  • wiki_search
  • wiki_get
  • wiki_apply
  • wiki_lint

So you normally do not need extra config just to make the agent “know” those tools exist.

A couple caveats:

  • if you later set a restrictive plugins.allow, memory-wiki has to be included
  • if you use a restrictive tool allowlist, those wiki tools also need to be allowed
  • the agent may not choose them every time on its own, but they should be available
#

So the practical answer is:

  • plugin enabled + loaded → tools available
  • no need to manually teach the agent the tool names
  • but you can nudge it by saying things like “use wiki_search” if you want more deterministic behavior

Also nice bonus: shared memory_search / memory_get can sometimes reach wiki content too, depending on corpus support, but wiki_search / wiki_get are the more direct wiki-native path.

Docs: https://docs.openclaw.ai/plugins/memory-wiki

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

icy delta
#

How do I check if I have an explicit tool allowlist

#

This is in my openclaw.json

"tools": {
    "profile": "coding",
    "alsoAllow": [
      "pdf"
    ],
    "deny": [
      "nodes",
      "canvas",
      "tts",
      "message"
    ],
    "exec": {
      "host": "gateway",
      "security": "full",
      "ask": "off"
    }
vocal walrusBOT
#

Yep, based on that snippet:

  • you do not have an explicit tools.allow list
  • but you do have a tool profile, and that still shapes what tools are available

So your setup is:

tools: {
  profile: "coding",
  alsoAllow: ["pdf"],
  deny: ["nodes", "canvas", "tts", "message"]
}

Meaning:

#
  • profile: "coding" = base tool set
  • alsoAllow = adds extra tools on top
  • deny = removes specific tools

So there’s no explicit tools.allow, but there is an effective policy via the coding profile.

For the wiki tools specifically:

  • if wiki_search / friends are already in the coding profile, you’re good
  • if not, you can add them with alsoAllow

Something like:

"alsoAllow": [
  "pdf",
#
  "wiki_status",
  "wiki_search",
  "wiki_get",
  "wiki_apply",
  "wiki_lint"
]

That should work as long as the memory-wiki plugin is loaded, which it sounds like it is.

So short answer:
No explicit tools.allow, yes tool policy still exists via profile.

icy delta
#

thanks how do I uninstall this plugin

Plugin "openclaw-telegram-file-browser" is not managed by plugins config/install records and cannot be uninstalled.

vocal walrusBOT
#

That message means OpenClaw didn’t install it through the managed plugin system, so the CLI has nothing to uninstall.

It’s basically seeing it as untracked local code sitting under:

~/.openclaw/extensions/

and loading it from there.

Safest fix

Don’t delete it first. Move the folder out of ~/.openclaw/extensions/ and restart the gateway.

In your case, it looks like the folder is:

#
/Users/openclaw/.openclaw/extensions/.openclaw-install-stage-aFBEzk

So a safe approach is:

mkdir -p ~/.openclaw/extensions-disabled
mv ~/.openclaw/extensions/.openclaw-install-stage-aFBEzk ~/.openclaw/extensions-disabled/
openclaw gateway restart

That disables it without destroying anything.

Why this happens

The path name:

#
.openclaw-install-stage-...

looks like a leftover staging/install directory, not a clean managed plugin install. So the CLI refuses to “uninstall” it because it doesn’t own that install record.

Alternative

If you don’t want to move files yet, you can also lock plugin loading down later with plugins.allow, but for this specific case, moving the stray folder out of extensions/ is the cleanest fix.

If you want, paste your plugins block and I can tell you whether you also need any plugins.allow cleanup after removing it.

icy delta
#

What does this mean?

04:15:41+00:00 info plugins {"subsystem":"plugins"} memory-core: light dreaming staged 85 candidate(s) [workspace=/Users/openclaw/.openclaw/charlotte-workspace].
04:15:41+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation failed for light phase: invalid agent params: must have required property 'idempotencyKey'
04:15:46+00:00 info plugins {"subsystem":"plugins"} memory-core: REM dreaming wrote reflections from 3879 recent memory trace(s) [workspace=/Users/openclaw/.openclaw/charlotte-workspace].
04:15:46+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation failed for rem phase: invalid agent params: must have required property 'idempotencyKey'
04:15:47+00:00 info plugins {"subsystem":"plugins"} memory-core: normalized recall artifacts before dreaming (rewrote recall store) [workspace=/Users/openclaw/.openclaw/charlotte-workspace].
04:15:47+00:00 info plugins {"subsystem":"plugins"} memory-core: dreaming promotion complete (workspaces=1, candidates=0, applied=0, failed=0).
vocal walrusBOT
#

It means dreaming mostly ran, but one optional sub-step failed.

Line by line:

  • light dreaming staged 85 candidate(s)
    Light phase found 85 short-term memory candidates.

  • narrative generation failed for light phase ... missing 'idempotencyKey'
    The system tried to generate a human-readable narrative/summary for that phase, but the agent call was missing a required field.
    That looks like a bug in the narrative/reporting path, not “memory is broken”.

  • REM dreaming wrote reflections from 3879 recent memory trace(s)
    REM phase actually ran and produced reflections.

  • narrative generation failed for rem phase ... missing 'idempotencyKey'
    Same bug again, for the REM narrative step.

#
  • normalized recall artifacts before dreaming
    It cleaned up / rewrote the recall store.

  • dreaming promotion complete ... candidates=0, applied=0
    Deep promotion finished, but nothing met the threshold to be promoted into durable memory.

Short version

This looks like:

  • dreaming pipeline ran
  • light + REM did real work
  • optional narrative generation failed
  • no durable promotions were applied this run

So I would treat it as non-fatal, but definitely a bug/regression worth noting.

Also, this is memory-core dreaming, not a memory-wiki issue.

#

If it keeps happening on 2026.4.9, I’d file a GitHub issue with exactly those log lines:
https://github.com/openclaw/openclaw/issues

If you want, I can also tell you where those narrative outputs would normally show up when the bug is not happening.