Mermaid support (jsdom globals) trips the Anthropic SDK browser guard, killing runs on Vertex/gemini-enterprise

[ppsplus-bradh]

Summary

When mermaid + jsdom are resolvable at runtime, openwiki activates its Mermaid rendering path, which installs jsdom's browser globals (window, document, navigator, …) into the Node process. The Anthropic SDK then detects a "browser-like environment" and refuses to construct the client, aborting the whole run with exit code 1 — before any docs are generated.

This makes Mermaid support and the Anthropic/Vertex model client mutually exclusive as currently wired.

Environment

• openwiki fork tag: v0.1.1-vertex.1 (mediwareinc/openwiki, code --update)
• Provider: OPENWIKI_PROVIDER=gemini-enterprise (Claude on Vertex via the Anthropic Vertex SDK, ADC auth)
• Model: claude-opus-4-8, GOOGLE_CLOUD_LOCATION=global
• Runner: GitHub Actions ubuntu-latest, Node 22
• Command: node dist/cli.js code --update --recursive --print
• mermaid + jsdom installed alongside the built CLI (pnpm add mermaid jsdom)

Error

It looks like you're running in a browser-like environment.

This is disabled by default, as it risks exposing your secret API credentials to attackers.
If you understand the risks and have appropriate mitigations in place,
you can set the `dangerouslyAllowBrowser` option to `true`, e.g.,

new Anthropic({ apiKey, dangerouslyAllowBrowser: true });

##[error]Process completed with exit code 1.

Root cause (chain)

1. mermaid + jsdom resolve → openwiki enables the Mermaid code path.
2. That path defines jsdom browser globals (window, document, …) process-wide, at startup.
3. The Anthropic SDK constructor checks for window/document, concludes it's a browser, and throws unless dangerouslyAllowBrowser: true.
4. Because the globals are set before/around client construction, the model client can never be built → run dies.

The mermaid-only piece is fine; it's jsdom's global leakage colliding with the SDK's browser guard.

Suggested fixes (either, ideally both)

1. Construct the Anthropic client with dangerouslyAllowBrowser: true. openwiki runs in a CLI/CI Node process, not a real browser — the guard is a false positive here, and no credential is exposed to an untrusted page. This is the standard escape hatch for server/CLI code that pulls in DOM shims.
2. Scope the jsdom globals to only the Mermaid render call (create the JSDOM instance and pass its window/document locally, or set/tear down globals around just the render) instead of assigning them globally at startup. This avoids polluting the environment the SDK inspects.

Fix #1 is the smaller change and unblocks immediately; fix #2 is the cleaner long-term shape.

Impact / workaround

Until fixed, enabling Mermaid (installing jsdom) breaks the Vertex-backed run entirely. Current workaround is to not install mermaid/jsdom — which disables diagrams but keeps code --update --recursive working.

Repro

1. Build the fork at v0.1.1-vertex.1.
2. pnpm add mermaid jsdom into the CLI dir.
3. Run node dist/cli.js code --update --recursive --print with OPENWIKI_PROVIDER=gemini-enterprise and Vertex ADC.
4. Observe the browser-environment error above.

Failing run for reference: mediwareinc/Meridian.IMR Actions run 29974928100 (step "Run openwiki --update").

[ppsplus-bradh]

Update: in a subsequent CI run (mediwareinc/Meridian.IMR run 29976519621) with mermaid + jsdom still installed, the browser-environment guard did not recur. The run constructed the Anthropic/Vertex client fine and executed for ~1h43m before failing for an unrelated reason (see #4, a Gmail connector crash).

So the "browser-like environment" failure in the original report is not a deterministic collision from merely having jsdom installed. Two more likely explanations:

• Load-order / timing dependent — the SDK's window/document check only trips if jsdom's globals are established before the client is constructed. Whether that happens may depend on which code path runs first (e.g. whether the Mermaid render path initializes eagerly vs. lazily on first diagram).
• Version/path variance between the two runs.

Net: the fix suggestions still stand (construct the client with dangerouslyAllowBrowser: true, and/or scope jsdom's globals to just the render call so they never leak into the SDK's environment check) — that would make it robust regardless of ordering. But this is intermittent, not a hard block, so it should be prioritized below #4.