Single default HCB Google launcher hid mailbox identity and made account selection implicit

Single default HCB Google launcher hid mailbox identity and made account selection implicit

Summary

Before the named-account HCB Google launchers landed on 2026-04-14, fleet sessions could reach shared Heartwood business Gmail and Calendar through a single default MCP launcher whose impersonation target was hidden in config. That made mailbox choice implicit instead of explicit, which is the wrong failure mode for shared business communications.

The failure

• When: Pre-fix state observed through 2026-04-14T20:35:20Z, with the doctrine follow-on requested at 2026-04-14T20:38:11Z
• Where: machine-local HCB Google MCP launchers, provider config surfaces, and any fleet session choosing a Gmail/Calendar tool without a visible account selector
• What broke: account identity was not encoded in the launcher name, so an agent could call Gmail or Calendar without the MCP surface itself revealing whether it was acting as admin@heartwoodcustombuilders.com or zack@heartwoodcustombuilders.com
• Who noticed: Chad, when he rejected an implicit default and explicitly asked for visible account options
• Who was affected: any Codex, Claude, or Gemini session touching HCB business Google Workspace surfaces

Timeline

• T+0: HCB Google access existed through unsuffixed default launchers (hcb-gmail-mcp, hcb-gcal-mcp, hcb-gdrive-mcp) with impersonation pinned behind the scenes.
• T+1: The team recognized that "explicit default for the HCB MCP surfaces" was insufficient because it still hid which human identity an agent would speak as.
• T+2: CODEX-DESKTOP-MacBook-Air-CAMBER+ORBIT-01 shipped named launchers and verified distinct live Gmail and Calendar responses for admin@heartwoodcustombuilders.com and zack@heartwoodcustombuilders.com under FLT-20260414, commit 87e1a679.
• T+3: FLT-2026041402 asked ORA to codify the pattern so named-account discoverability becomes durable across projects and provider surfaces.

Root cause

The launcher namespace optimized for convenience instead of identity legibility. A single default launcher treated mailbox choice as an implementation detail, but shared business comms are identity-sensitive by definition. Hiding the identity at the tool name layer created avoidable ambiguity at exactly the point where an agent needs clarity most.

Contributing factors

• The original launcher naming predated the need to expose more than one HCB Google identity.
• Provider configs could surface the tool, but not the underlying impersonated account, unless the launcher name encoded it directly.
• The fleet already had a broader hcb-* namespace rule, but no explicit doctrine yet for multi-account Google surfaces.

What we learned

For shared business Google access, account identity must be visible in the MCP server name itself. If an agent has to remember hidden config state to know whose mailbox it is touching, the interface is already wrong.

Prevention

• Doctrine implication: ORA-2026-0002
• Enforcement change: Named launchers now live under ~/.local/bin/hcb-{service}-{account}-mcp and are restamped into Codex, Gemini, and Claude Desktop configs.
• Detection improvement: Any future HCB Google launcher change should fail review unless the account identity is obvious from the launcher name and the live proof demonstrates distinct impersonation targets.

References

• Fleet proof item: FLT-20260414
• Doctrine follow-on request: FLT-2026041402
• Camber implementation proof: /Users/chadbarlow/gh/camber@87e1a6793bef5b7b29b1f208dd88739db8a20b32

Graduation criteria

Move to M2 when a linked EXP verifies that named-account launchers eliminate account-selection ambiguity across all active provider surfaces. Move to M4 when the linked doctrine is both written and durably enforced in fleet doctrine surfaces.