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] =?UTF-8?q?Sharpen:=20BC=20MCP=20company-header=20rule=20?=
 =?UTF-8?q?=E2=80=94=20correct=20header=20isn't=20proof=20against=20recurr?=
 =?UTF-8?q?ence?=
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.