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: retract restart theory, confirm MS-support escalation for BC MCP company error

Browse source 
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.
This commit is contained in:
Michael Dieringer 2026-08-03 16:00:15 +02:00
parent f7f20e8f98
commit 8e85976fdb
1 changed files with 31 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -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 independent developer machines, both with `company` already set to the
correct `Navn` value (`"Curabis ApS"`) per this rule. The header-mismatch correct `Navn` value (`"Curabis ApS"`) per this rule. The header-mismatch
cause above was confirmed absent both times — yet the error still occurred, cause above was confirmed absent both times — yet the error still occurred,
intermittently, within the same working day. Restarting Claude Code (which intermittently, within the same working day.
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 This means a correct `Navn`-matching header is **necessary but not
sufficient**: the same-looking error can have a second, distinct cause tied sufficient**: the same-looking error can have a second cause unrelated to
to the long-running bridge/session rather than a static config value. A the header value. When this happens, the header-match check (Verification,
developer who has already verified the header matches `Navn` character for above) has nothing left to find — do not keep re-checking that same field.
character should not keep re-checking that same field. Next steps, in order:
1. Restart Claude Code once and retry. **Ruled out on 2026-08-03, with evidence — do not re-investigate these:**
2. If it recurs, check BC-side state that a config file can't reveal: the - **Stale client process.** A theory that a long-running `bc-mcp-bridge.js`
Entra app registration's (`BC_DevelopmentMCP`) company-permission process was running pre-fix code from before its 2026-08-01 update, and
assignment, and whether the relevant MCP Server Configuration that restarting Claude Code would pick up the fix. **Falsified same day:**
(`Model Context Protocol (MCP) Server Configurations`, BC page 8351) is a full machine reboot (strictly stronger than a Claude Code restart — kills
still Active. every process, clears all in-memory state, re-establishes every network
3. If it recurs across restarts and BC-side checks pass, treat it as a connection) left the exact same error unchanged immediately after. An
SaaS-side incident and escalate to Microsoft support rather than earlier apparent "it works after a restart" observation was very likely
re-diagnosing the client config a third time. 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 — **Conclusion:** with the header confirmed correct, the MCP configuration
this section records the observed correlation, not a confirmed mechanism. 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.