fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945) (AI-assisted) by liuhao1024 · Pull Request #97954 · openclaw/openclaw

liuhao1024 · 2026-06-29T23:27:23Z

What Problem This Solves

openclaw wiki lint produces false-positive Broken wikilink target warnings for [[...]] patterns inside fenced code blocks and inline code spans. Bash test syntax ([[ "$name" == "Alice" ]]), Scala generics (Future[Option[User]]), and inline code examples are all misdetected as wikilinks. In real vaults with code snippets, this generates hundreds of noise warnings that obscure genuine link issues.

Why This Change Was Made

The extractWikiLinks function in extensions/memory-wiki/src/markdown.ts runs OBSIDIAN_LINK_PATTERN against the full markdown content, only stripping RELATED_BLOCK_PATTERN before matching. Fenced code blocks and inline code spans are not excluded, so any [[...]] pattern inside code is falsely detected as a wikilink.

The fix adds two preprocessing steps before the wikilink regex:

Strip fenced code blocks (triple-backtick delimited blocks)
Strip inline code spans (single-backtick delimited)

This preserves real wikilinks in prose while eliminating code-block false positives.

User Impact

Users with code snippets in their wiki vaults will see dramatically fewer false-positive lint warnings. The reporter observed 1,697 false Broken wikilink target warnings from ~2,626 total — the fix eliminates all code-block-originated false positives.

AI-assisted (Hermes Agent)

Evidence

Behavior addressed: openclaw wiki lint false-positive broken-wikilink warnings from [[...]] patterns in fenced code blocks and inline code
Environment tested: macOS 15.5.0 (arm64), OpenClaw 2026.5.28, memory-wiki plugin
Steps run after the patch:
1. Created test vault at /tmp/test-wiki-vault with sources/code-example.md containing bash [[ "$name" == "Alice" ]], Scala Future[Option[User]], and inline code [[ "$str" == "test" ]] inside fenced code blocks
2. Configured plugins.entries.memory-wiki.config.vault.path to point at the test vault
3. Ran ./node_modules/.bin/openclaw wiki lint --json
Evidence after fix:

Total issues: 4
broken-wikilink issues: 1
  entities/alpha.md: Broken wikilink target `real-link`.
✅ No false positive broken-wikilink warnings from code blocks

Observed result after fix: The 3 false-positive broken-wikilink warnings from code blocks ("$name" == "Alice", $count -gt 5, "$str" == "test") are eliminated. The only remaining warning is a genuine broken wikilink (real-link) in prose text.
What was not tested: Large vaults with mixed real wikilinks and code blocks (the test vault is minimal); Obsidian-specific rendering modes beyond obsidian

Real behavior proof

Behavior addressed: openclaw wiki lint false-positive broken-wikilink warnings from [[...]] patterns in fenced code blocks and inline code
Environment tested: macOS 15.5.0 (arm64), OpenClaw 2026.5.28, memory-wiki plugin
Steps run after the patch:
1. Created test vault at /tmp/test-wiki-vault with sources/code-example.md containing bash [[ "$name" == "Alice" ]], Scala Future[Option[User]], and inline code [[ "$str" == "test" ]] inside fenced code blocks
2. Configured plugins.entries.memory-wiki.config.vault.path to point at the test vault
3. Ran ./node_modules/.bin/openclaw wiki lint --json
Evidence after fix:

Total issues: 4
broken-wikilink issues: 1
  entities/alpha.md: Broken wikilink target `real-link`.
✅ No false positive broken-wikilink warnings from code blocks

Observed result after fix: The 3 false-positive broken-wikilink warnings from code blocks ("$name" == "Alice", $count -gt 5, "$str" == "test") are eliminated. The only remaining warning is a genuine broken wikilink (real-link) in prose text.
What was not tested: Large vaults with mixed real wikilinks and code blocks (the test vault is minimal); Obsidian-specific rendering modes beyond obsidian

extractWikiLinks runs OBSIDIAN_LINK_PATTERN against full markdown including fenced code blocks and inline code spans, causing false positive 'Broken wikilink target' warnings for bash [[...]] test syntax and Scala generics inside code blocks. Strip fenced code blocks and inline code before running the wikilink regex to eliminate code-block false positives while preserving real wikilinks in prose. Fixes openclaw#97945

clawsweeper · 2026-06-29T23:28:34Z

Codex review: needs changes before merge. Reviewed June 30, 2026, 1:25 PM ET / 17:25 UTC.

Summary
The PR changes Memory Wiki wikilink extraction to strip backtick fenced code and inline code before link regexes, with a lint regression test for code-origin false positives.

Reproducibility: yes. Current main is source-reproducible because wikilink extraction still scans code-bearing markdown and lint turns unmatched extracted targets into broken-wikilink warnings; a read-only regex probe also reproduces the PR’s remaining parser gaps.

Review metrics: 1 noteworthy metric.

Actual merge delta: 2 files changed, +69/-1 in the potential merge commit. The live PR file list is polluted by stale-base history, but the actual current-main merge result is a narrow Memory Wiki patch.

Stored data model
Persistent data-model change detected: migration/backfill/repair: docs/tools/acp-agents.md, migration/backfill/repair: docs/tools/slash-commands.md, migration/backfill/repair: test/e2e/qa-lab/runtime/docker-e2e-lane.fixture.test.ts, migration/backfill/repair: test/e2e/qa-lab/runtime/docker-e2e-lane.fixture.ts, persistent cache schema: extensions/codex/src/app-server/app-inventory-cache.test.ts, persistent cache schema: src/plugin-sdk/memory-host-events.test.ts, and 5 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #97945
Summary: The canonical issue tracks Memory Wiki fenced-code and inline-code wikilink false positives; this PR is one candidate fix with sibling PRs competing for the same root cause.

Members:

canonical: memory-wiki lint: wikilink extractor still not markdown-aware — fenced code false positives (reopening #70986) #97945 - The issue directly tracks the Memory Wiki markdown-aware wikilink extraction bug that this PR targets.
fixed_by_candidate: fix(memory-wiki): ignore wikilink-like text in code spans during lint #97977 - This open sibling PR targets the same extractor false-positive class, but its current review still reports a parser false-negative risk.
fixed_by_candidate: fix(memory-wiki): ignore code spans during wikilink lint #97987 - This open sibling PR also targets the same Memory Wiki code-region wikilink masking bug but is not a merged canonical replacement.
fixed_by_candidate: fix(memory-wiki): strip fenced code and inline code before wikilink extraction #98095 - This open sibling PR targets the same canonical issue and includes broader fence variants, but it still has proof and parser-review blockers.
superseded: fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945) #97964 - This closed unmerged PR was an earlier narrower candidate for the same extractor bug.
1 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🐚 platinum hermit
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Repair tilde fenced-code and multi-backtick inline-code masking.
[P2] Add focused regression coverage for the two parser gaps.

Risk before merge

[P1] The current regex still leaves wikilink-like text inside tilde fenced code blocks visible to the extractor, so some false broken-wikilink warnings remain.
[P1] The inline-code regex can remove a genuine prose wikilink between double-backtick code spans, hiding a real diagnostic.
[P1] Several open sibling PRs target the same canonical Memory Wiki bug, so maintainers need to choose one repaired landing branch before merge.

Maintainer options:

Repair this branch before merge (recommended)
Update the Memory Wiki masking to handle tilde fences and multi-backtick inline spans correctly, then add focused regressions for both parser gaps.
Adopt a sibling branch only after proof
If maintainers prefer a sibling PR, use it only after it is proof-positive and covers the same parser edge cases without new lint false negatives.
Pause duplicate landing work
Leave competing PRs open until one repaired branch is selected, then close the remaining candidates as superseded with links to the chosen path.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Update Memory Wiki wikilink extraction so code masking handles tilde fenced blocks and multi-backtick inline spans without hiding prose links between code spans; keep the change scoped to extensions/memory-wiki/src/markdown.ts and focused Memory Wiki tests.

Next step before merge

The remaining blockers are narrow parser and regression-test repairs that automation can attempt on this branch.

Security
Cleared: No concrete security or supply-chain issue was found in the actual merge delta, which is limited to Memory Wiki parsing and a colocated test.

Review findings

[P2] Handle standard fenced code markers — extensions/memory-wiki/src/markdown.ts:393
[P2] Preserve links between multi-backtick spans — extensions/memory-wiki/src/markdown.ts:394

Review details

Best possible solution:

Keep the fix at the Memory Wiki extractor boundary, but replace the ad hoc masking with scanner-grade handling for standard fenced and inline code spans before choosing this branch as the landing path.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main is source-reproducible because wikilink extraction still scans code-bearing markdown and lint turns unmatched extracted targets into broken-wikilink warnings; a read-only regex probe also reproduces the PR’s remaining parser gaps.

Is this the best way to solve the issue?

No, not as submitted. The extractor is the right layer, but the current regex masking is too narrow for standard fenced-code forms and unsafe for multi-backtick inline spans.

Full review comments:

[P2] Handle standard fenced code markers — extensions/memory-wiki/src/markdown.ts:393
The new masking only removes backtick fences, so Markdown code blocks opened with ~~~ still reach OBSIDIAN_LINK_PATTERN and can keep producing false broken-wikilink warnings. Please handle standard fenced-code forms before merge.
Confidence: 0.9
[P2] Preserve links between multi-backtick spans — extensions/memory-wiki/src/markdown.ts:394
The inline-code regex can consume from inside one double-backtick span through the next span. For text like code`` [[missing]] ``more, the real prose wikilink disappears before lint can report it; mask each inline span independently and cover this case.
Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f284ce3b4df7.

Label changes

Label justifications:

P2: This is a bounded bundled Memory Wiki lint bug fix with real diagnostic impact but limited plugin blast radius.
merge-risk: 🚨 other: Merging the current parser regex can both leave code-origin false positives and hide genuine broken-link diagnostics in multi-backtick inline-code layouts.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes copied after-fix openclaw wiki lint --json output from a configured test vault showing code-origin warnings removed while a genuine broken link remains.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied after-fix openclaw wiki lint --json output from a configured test vault showing code-origin warnings removed while a genuine broken link remains.

Evidence reviewed

Acceptance criteria:

[P1] node scripts/run-vitest.mjs extensions/memory-wiki/src/lint.test.ts.
[P1] node scripts/run-vitest.mjs extensions/memory-wiki/src/markdown.test.ts extensions/memory-wiki/src/lint.test.ts if a markdown extractor test file is added.
[P1] git diff --check.

What I checked:

Repository policy read: Read the full root AGENTS.md plus relevant scoped extension/plugin/docs/gateway policy files; the root high-confidence PR review and extension boundary guidance apply to this Memory Wiki plugin fix. (AGENTS.md:20, f284ce3b4df7)
Current main extractor behavior: Current main builds searchable markdown by removing only the managed related block before running Obsidian and Markdown link regexes, so code-bearing markdown is still scanned. (extensions/memory-wiki/src/markdown.ts:389, f284ce3b4df7)
Lint warning path: Unmatched extracted linkTargets are emitted as broken-wikilink warnings, making leaked code-region matches user-visible in wiki lint output. (extensions/memory-wiki/src/lint.ts:68, f284ce3b4df7)
Actual merge delta: The potential merge commit compares against current main as only two Memory Wiki files changed, despite GitHub's stale displayed PR file list showing 128 files. (83d37f96f4b1)
PR parser implementation: The PR head uses a backtick-only fenced-code regex and a single-backtick inline-code regex before related-block removal. (extensions/memory-wiki/src/markdown.ts:393, 1e1ae6f6f0fb)
Parser gap proof: A read-only Node probe of the PR regex leaves a wikilink-like target inside a tilde fence and drops a real wikilink placed between double-backtick spans. (extensions/memory-wiki/src/markdown.ts:393, 1e1ae6f6f0fb)

Likely related people:

vincentkoc: Git history shows this account introduced the Memory Wiki ingest/compile/lint pipeline and later restored/expanded the affected markdown and lint behavior; this account also authored the latest commit on the PR branch. (role: feature introducer and recent area contributor; confidence: high; commits: 516a43f9f28c, 5716d83336fd, 1e1ae6f6f0fb; files: extensions/memory-wiki/src/markdown.ts, extensions/memory-wiki/src/lint.ts, extensions/memory-wiki/src/lint.test.ts)
steipete: Recent Memory Wiki link-target and lint-helper history points to adjacent ownership around the same lint and markdown surfaces. (role: recent adjacent area contributor; confidence: medium; commits: 2dcc13d6859d, dffa88f39615, 77d9ac30bb8d; files: extensions/memory-wiki/src/markdown.ts, extensions/memory-wiki/src/lint.ts, extensions/memory-wiki/src/lint.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

clawsweeper · 2026-06-30T17:11:44Z

ClawSweeper applied the proposed close for this PR.

Action: closed this PR.
Close reason: low-signal unmergeable PR.
Evidence: durable ClawSweeper review.

vincentkoc · 2026-06-30T17:27:01Z

Merged via squash.

Prepared head SHA: 1e1ae6f6f0fbff5cc223435d0c604617093a2b82
Landed commit: c896718acb2ac565da79a6f019bca943eb87721b

…fixes openclaw#97945) (AI-assisted) (openclaw#97954) * fix(memory-wiki): strip fenced code blocks before wikilink extraction extractWikiLinks runs OBSIDIAN_LINK_PATTERN against full markdown including fenced code blocks and inline code spans, causing false positive 'Broken wikilink target' warnings for bash [[...]] test syntax and Scala generics inside code blocks. Strip fenced code blocks and inline code before running the wikilink regex to eliminate code-block false positives while preserving real wikilinks in prose. Fixes openclaw#97945 * fix(memory-wiki): strip fenced code blocks before wikilink extraction --------- Co-authored-by: Vincent Koc <[email protected]>

…fixes openclaw#97945) (AI-assisted) (openclaw#97954) * fix(memory-wiki): strip fenced code blocks before wikilink extraction extractWikiLinks runs OBSIDIAN_LINK_PATTERN against full markdown including fenced code blocks and inline code spans, causing false positive 'Broken wikilink target' warnings for bash [[...]] test syntax and Scala generics inside code blocks. Strip fenced code blocks and inline code before running the wikilink regex to eliminate code-block false positives while preserving real wikilinks in prose. Fixes openclaw#97945 * fix(memory-wiki): strip fenced code blocks before wikilink extraction --------- Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit c896718)

openclaw-barnacle Bot added extensions: memory-wiki size: S labels Jun 29, 2026

fix(memory-wiki): strip fenced code blocks before wikilink extraction

1e1ae6f

clawsweeper Bot closed this Jun 30, 2026

vincentkoc reopened this Jun 30, 2026

clawsweeper Bot had a problem deploying to qa-live-shared June 30, 2026 17:13 Failure

vincentkoc merged commit c896718 into openclaw:main Jun 30, 2026
386 of 413 checks passed

github-actions Bot mentioned this pull request Jun 30, 2026

📡 Upstream Digest — 2026-06-30 17:46 UTC curtismercier/openclaw-mods#1177

Open

vincentkoc mentioned this pull request Jul 1, 2026

fix(memory-wiki): strip fenced code and inline code before wikilink extraction #98075

Closed

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945) (AI-assisted)#97954

fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945) (AI-assisted)#97954
vincentkoc merged 2 commits into
openclaw:mainfrom
liuhao1024:fix/memory-wiki-fenced-code-false-positive

liuhao1024 commented Jun 29, 2026

Uh oh!

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

Uh oh!

vincentkoc commented Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

liuhao1024 commented Jun 29, 2026

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Real behavior proof

Uh oh!

clawsweeper Bot commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

Uh oh!

vincentkoc commented Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading