From 2c48b48dd82a60bf215a34782f08d363f6e5094a Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Mon, 3 Aug 2026 14:45:16 +0200 Subject: [PATCH 1/3] Add Node.js runtime prerequisite check before machine setup Step 3 Type B gap (Francis): bc-mcp-bridge.js is a Node.js script and the businesscentral MCP registration launches it via 'node ...', but nothing in the setup checklist ever verified Node was actually installed. Found missing on a fresh machine during a full developer onboarding today -- the bridge deployed fine, the MCP server registered fine, and then every connection attempt would have failed with a generic timeout instead of a clear "Node missing" message. Checked first: this is genuinely uncovered, not a documentation-clarity issue -- ~/.bc-mcp.config.json's path is already stated unambiguously everywhere it's referenced, so no rule needed there. This is a different, real gap: no prerequisite check existed at all. --- custom/setup/curabis-standard.agent.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/custom/setup/curabis-standard.agent.md b/custom/setup/curabis-standard.agent.md index 5a40335..eeb3258 100644 --- a/custom/setup/curabis-standard.agent.md +++ b/custom/setup/curabis-standard.agent.md @@ -144,6 +144,17 @@ Check whether these paths exist: - `~/.claude/bc-mcp-bridge.js` → bridge already installed? - `~/.bc-mcp.config.json` → BC credentials present? +**Runtime prerequisite — check before Step 3, not after:** run `node --version`. +`bc-mcp-bridge.js` (Step 3a) is a Node.js script, and the `businesscentral` MCP +registration (Step 3c) launches it via `node ...` — without Node installed and on +PATH, the bridge can never run, and `claude mcp add` will register a server that +fails on every connection attempt with a generic timeout, not a clear "Node +missing" message. If `node --version` fails, stop and tell the developer to +install Node.js (LTS) before continuing — do not deploy the bridge or register +the MCP server on a machine that can't run either. 2026-08-03: found missing on a +fresh machine during a full developer onboarding; nothing in this checklist +would have caught it before Step 3 silently deployed a script that couldn't run. + Also run `claude mcp list` (or `claude mcp get al` / `claude mcp get businesscentral`) to check whether the two standard MCP servers are already registered at user scope. If any of the above machine-level artifacts are missing, Step 3 will deploy them via @@ -197,6 +208,10 @@ Do not proceed until all three are answered. #### 3a. bc-mcp-bridge.js +Node.js must already be confirmed present (Step 1's runtime prerequisite check) +before this step — a bridge script deployed onto a machine without Node to run +it is a silent dead end until Step 3c's registration fails. + 1. Fetch `{BASE}/bc-mcp-bridge.js` 2. Write to `~/.claude/bc-mcp-bridge.js` (overwrite silently — BCQuality is authoritative) 3. Confirm: "bc-mcp-bridge.js er opdateret på din maskine." From f7f20e8f9888b2de3074d80f9eb149e9b0ac1ca7 Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Mon, 3 Aug 2026 15:10:18 +0200 Subject: [PATCH 2/3] =?UTF-8?q?Sharpen:=20BC=20MCP=20company-header=20rule?= =?UTF-8?q?=20=E2=80=94=20correct=20header=20isn't=20proof=20against=20rec?= =?UTF-8?q?urrence?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Internal_CompanyNotFound recurred 2026-08-03 on two machines with the company header already matching Navn correctly, ruling out the original header-mismatch cause. Failure was intermittent and appeared to clear after restarting Claude Code, suggesting a separate, still-unconfirmed session/ bridge staleness issue. Adds a follow-up section with next steps so future sessions don't re-verify an already-correct header a third time. --- ...ny-header-must-match-exact-company-name.md | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md b/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md index 2985df7..4e21c0e 100644 --- a/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md +++ b/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md @@ -55,3 +55,32 @@ machine-local file, not something Mode B can fix centrally. The template (`bc-mcp.config.template.json`) carries an explicit warning about this distinction as of 2026-07-31, but a machine already onboarded before that date needs its existing file checked manually. + +## Follow-up (2026-08-03) — a correct header does not guarantee the request resolves + +The `Internal_CompanyNotFound` symptom recurred on 2026-08-03 on two +independent developer machines, both with `company` already set to the +correct `Navn` value (`"Curabis ApS"`) per this rule. The header-mismatch +cause above was confirmed absent both times — yet the error still occurred, +intermittently, within the same working day. Restarting Claude Code (which +respawns the `bc-mcp-bridge.js` process and re-establishes the MCP session) +was observed to restore working state, though this has not been root-caused. + +This means a correct `Navn`-matching header is **necessary but not proven +sufficient**: the same-looking error can have a second, distinct cause tied +to the long-running bridge/session rather than a static config value. A +developer who has already verified the header matches `Navn` character for +character should not keep re-checking that same field. Next steps, in order: + +1. Restart Claude Code once and retry. +2. If it recurs, check BC-side state that a config file can't reveal: the + Entra app registration's (`BC_DevelopmentMCP`) company-permission + assignment, and whether the relevant MCP Server Configuration + (`Model Context Protocol (MCP) Server Configurations`, BC page 8351) is + still Active. +3. If it recurs across restarts and BC-side checks pass, treat it as a + SaaS-side incident and escalate to Microsoft support rather than + re-diagnosing the client config a third time. + +Root cause of the session/restart-correlated failure mode is still open — +this section records the observed correlation, not a confirmed mechanism. From 8e85976fdbad130f1576c6ba98b795afde111e9d Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Mon, 3 Aug 2026 16:00:15 +0200 Subject: [PATCH 3/3] Sharpen: retract restart theory, confirm MS-support escalation for BC MCP company error The 2026-08-03 follow-up's "restart Claude Code" step was falsified same day by a full machine reboot that left Internal_CompanyNotFound unchanged. Records the two theories ruled out with evidence (stale bridge process; MCP config/company misconfiguration, both screenshot-verified) and states plainly that this is a client-unfixable, likely BC/SaaS-side condition requiring Microsoft support escalation. --- ...ny-header-must-match-exact-company-name.md | 50 ++++++++++++------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md b/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md index 4e21c0e..bf067a8 100644 --- a/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md +++ b/custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md @@ -62,25 +62,37 @@ The `Internal_CompanyNotFound` symptom recurred on 2026-08-03 on two independent developer machines, both with `company` already set to the correct `Navn` value (`"Curabis ApS"`) per this rule. The header-mismatch cause above was confirmed absent both times — yet the error still occurred, -intermittently, within the same working day. Restarting Claude Code (which -respawns the `bc-mcp-bridge.js` process and re-establishes the MCP session) -was observed to restore working state, though this has not been root-caused. +intermittently, within the same working day. -This means a correct `Navn`-matching header is **necessary but not proven -sufficient**: the same-looking error can have a second, distinct cause tied -to the long-running bridge/session rather than a static config value. A -developer who has already verified the header matches `Navn` character for -character should not keep re-checking that same field. Next steps, in order: +This means a correct `Navn`-matching header is **necessary but not +sufficient**: the same-looking error can have a second cause unrelated to +the header value. When this happens, the header-match check (Verification, +above) has nothing left to find — do not keep re-checking that same field. -1. Restart Claude Code once and retry. -2. If it recurs, check BC-side state that a config file can't reveal: the - Entra app registration's (`BC_DevelopmentMCP`) company-permission - assignment, and whether the relevant MCP Server Configuration - (`Model Context Protocol (MCP) Server Configurations`, BC page 8351) is - still Active. -3. If it recurs across restarts and BC-side checks pass, treat it as a - SaaS-side incident and escalate to Microsoft support rather than - re-diagnosing the client config a third time. +**Ruled out on 2026-08-03, with evidence — do not re-investigate these:** +- **Stale client process.** A theory that a long-running `bc-mcp-bridge.js` + process was running pre-fix code from before its 2026-08-01 update, and + that restarting Claude Code would pick up the fix. **Falsified same day:** + a full machine reboot (strictly stronger than a Claude Code restart — kills + every process, clears all in-memory state, re-establishes every network + connection) left the exact same error unchanged immediately after. An + earlier apparent "it works after a restart" observation was very likely + coincidental with an intermittent server-side state, not causal. +- **MCP Server Configuration misconfigured.** Verified via BC UI screenshot: + `CURABIS_DEV` configuration is `Aktiv` (Active) = on, `Standard` (Default) + = on, with the expected tool set and permissions present. +- **Company record wrong or `Navn` mismatched.** Verified via BC UI + screenshot of the company list: `Navn` = `Curabis ApS` exactly (matches + config character-for-character), `Vist navn` = `CURABIS ApS` (confirming + why the original 2026-07-31 mix-up was easy to make), setup status + `Completed`. -Root cause of the session/restart-correlated failure mode is still open — -this section records the observed correlation, not a confirmed mechanism. +**Conclusion:** with the header confirmed correct, the MCP configuration +confirmed active/default, and the company record confirmed correct — all +via direct BC UI inspection, not inference — and the error still recurring +intermittently, immune even to a full machine reboot, this is not a client- +fixable condition. Escalate to Microsoft support with the evidence bundle +(exact error text, `~/.bc-mcp.config.json` values, both BC UI screenshots, +and timestamps of both failing and working calls) rather than continuing +local troubleshooting. Root cause of the intermittent failure itself remains +unconfirmed — likely a BC/SaaS-side condition outside CURABIS's visibility.