Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Sharpen: BC MCP company-header rule — correct header isn't proof against recurrence

Browse source 
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.
This commit is contained in:
Michael Dieringer 2026-08-03 15:10:18 +02:00
parent 0874af2e8a
commit f7f20e8f98
1 changed files with 29 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

29
custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md
View file

@ -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.