HCB business Google access is exposed as named-account MCP servers, not a single default

HCB business Google access is exposed as named-account MCP servers, not a single default

The rule

Shared business Google Workspace access (Gmail, Calendar, Drive, and any future workspace surface) MUST be exposed through per-account MCP launchers of the form hcb-{service}-{account}-mcp, one launcher per distinct human identity, registered across every active provider surface on every active fleet machine. Impersonation MUST NOT be hidden inside a single default launcher once more than one account is in scope.

Current roster (append-only, as of 2026-04-14):

• hcb-gmail-admin / hcb-gcal-admin → admin@heartwoodcustombuilders.com
• hcb-gmail-zack / hcb-gcal-zack → zack@heartwoodcustombuilders.com

The unsuffixed legacy launchers (hcb-gmail-mcp, hcb-gcal-mcp, hcb-gdrive-mcp) remain on disk under ~/.local/bin/ as historical default-impersonation surfaces but are NOT the pattern for new account additions. New accounts are added as new named launchers; old launchers are not renamed.

Scope

• Applies to: any shared HCB business identity accessible through Google Workspace from the fleet — Gmail, Calendar, Drive, Admin SDK, and any future workspace surface. Applies to every active fleet machine (MacBook Air, iMac, any future seat) and every active provider surface (Codex ~/.codex/config.toml, Gemini ~/.gemini/settings.json, Claude Desktop claude_desktop_config.json, Claude managed MCP).
• Does NOT apply to: personal Google accounts (Chad's chbarlow@gmail.com is outside HCB business scope). Does NOT apply to non-Google business connectors — this doctrine is about the account-disambiguation pattern, not a universal connector rule. Other HCB connectors (e.g. hcb-bt-, hcb-supabase-) follow the broader HCB namespace rule in the canonical bundle but only inherit this named-account sub-pattern if they end up servicing multiple distinct human identities.

Rationale

Before FLT-20260414, HCB Google access went through a single default launcher whose impersonation target was pinned inside config. Two problems followed from that:

1. Hidden identity. An agent calling gmail-mailbox had no way to tell from the MCP surface alone which mailbox it was reading or writing. Mailbox choice was a silent config side-effect. In a multi-agent fleet where any session may touch business comms, whose mailbox is being touched is the single most important fact — hiding it is a drafting error waiting to send mail as the wrong human. 2. Credit-burn and auth pinning. A single default launcher tied every call to one OAuth state. Swapping accounts meant re-auth, not server selection. With named launchers, account choice is a server name and every account has its own impersonation path through the Camber edge proxy.

Named launchers make identity explicit in the tool name itself. hcb-gmail-zack-mcp reads the same whether you see it in a config file, a capability list, or a tool-call log — you always know whose mailbox was touched.

Evidence trail

• ORA-2026-0003 (FAL) — captured the failure mode this rule prevents: a single default launcher hid mailbox identity and made account choice implicit.
• FLT-20260414 (implementation proof) — CODEX-DESKTOP-MacBook-Air-CAMBER+ORBIT-01 shipped the account-selectable seam on 2026-04-14T20:35:20Z. Live Gmail edge proof returned distinct From: Chad Barlow <admin@...> and From: Zack Sittler <zack@...> headers through hcb-gmail-admin-mcp and hcb-gmail-zack-mcp. Live Calendar edge proof returned distinct gcal_ping and gcal_list_events responses through hcb-gcal-admin-mcp and hcb-gcal-zack-mcp. Repo proof: sha=87e1a679 in /Users/chadbarlow/gh/camber.
• FLT-2026041402 (this doctrine request) — CODEX-DESKTOP-MacBook-Air-CAMBER+ORBIT-01 asked ORA to turn the pattern into durable fleet-visible process on 2026-04-14T20:38:11Z.
• Prior art — canonical bundle v1.6 §Coordination surfaces — already established the broader hcb-* namespace + parity-restamp rule. This doctrine adds the account-disambiguation refinement on top of that baseline.

Enforcement hook

• Machine-local launcher surface: ~/.local/bin/hcb-{service}-{account}-mcp binaries make the impersonated identity explicit at invocation time.
• Provider config surface: Codex ~/.codex/config.toml, Gemini ~/.gemini/settings.json, and Claude Desktop claude_desktop_config.json carry the named server registrations so account choice is visible in every tool list.
• Implementation substrate: Camber edge proxies at sha=87e1a679 enforce the impersonation path behind each named launcher.
• Standing doctrine surface: canonical bundle v1.6 §Coordination surfaces now carries the HCB connector namespace rule that this doctrine sharpens into the named-account pattern.

Discoverability

Any agent needing HCB business Google access on any provider MUST find the current named launchers through one of these surfaces, in this order:

1. This doctrine — ~/gh/ora/docs/entries/doctrines/ORA-2026-0002_hcb-named-account-mcp-pattern.md. Source of truth for the roster. 2. Canonical bundle head section — ~/.orbit/canonical_user_identity_v1.md / ~/.claude/CLAUDE.md / ~/.codex/AGENTS.md §0 / ~/.gemini/GEMINI.md. Bundle references this doctrine under the HCB connector namespace rule. 3. Fleet feed proof — FLEET_FEED.md posts under item FLT-20260414. Ground-truth for when a launcher first became operational. 4. On-disk binaries — ~/.local/bin/hcb--mcp. Ground-truth for what actually exists on a given machine. An agent can list ~/.local/bin/ | grep hcb- to see the current roster from inside any shell. 5. Per-provider config files — Codex ~/.codex/config.toml [mcp_servers.hcb-] blocks, Gemini ~/.gemini/settings.json hcb-* entries, Claude Desktop claude_desktop_config.json mcpServers entries, Claude managed MCP. Ground-truth for which launchers a given session actually has access to.

Names decode as hcb-{service}-{account}-mcp:

• service ∈ {gmail, gcal, gdrive, future Google Workspace services}
• account = the human identifier inside the heartwoodcustombuilders.com domain (e.g. admin, zack). Extends by adding new human identities; never by replacing or renaming existing ones.
• Trailing -mcp is the launcher suffix.

When to add a new account option vs replace an existing one

• Add a new launcher when the fleet needs addressable access to a new distinct human identity inside HCB Workspace (e.g. onboarding a new team member whose mailbox needs to be readable, or a shared role account like ops@). Adding is append-only — ship a new launcher under the next hcb-{service}-{new-account}-mcp name and restamp all providers.
• Never replace or rename an existing launcher. Launcher names are part of the cross-provider config surface. Renaming breaks every config file that references the old name on every machine. If an account is deprecated, keep the launcher registered but mark it deprecated in this doctrine and stop using it — do not delete.
• Do not re-pin the default. The old default-impersonation launchers (hcb-gmail-mcp, hcb-gcal-mcp, hcb-gdrive-mcp) are historical; do not change which account they silently impersonate. If you need an account, use the named launcher. Changing the default silently changes who the fleet is "speaking as" — that is the exact failure mode this doctrine exists to prevent.

Parity and maintenance

Named-launcher additions and removals MUST follow the parity discipline already established in the canonical bundle §4 and Standing Directive §15:

1. Ship the binary under ~/.local/bin/hcb-{service}-{account}-mcp on the single-writer machine (currently MacBook-Air). 2. Prove the wiring end-to-end — initialize + tools/list + at least one live call that returns distinct data proving the impersonation target. Post the proof to FLEET_FEED.md under an FLT-* item before declaring DONE. 3. Restamp every active provider surface on every active fleet machine:

• Codex ~/.codex/config.toml [mcp_servers.<name>] block + per-tool approval_mode gates
• Gemini ~/.gemini/settings.json mcpServers entry
• Claude Desktop claude_desktop_config.json mcpServers entry (and restart the app — Claude Desktop reads mcpServers only at launch)
• Claude managed MCP surface, if present

4. Run provider-parity-check --feed after the restamp round to surface drift. 5. Update this doctrine's roster section with the new launcher name, target email, and the FLT-* proof it landed under. Roster updates are append-only. 6. Update the on-disk inventory note in the canonical bundle head section if the HCB connector namespace entry needs to reference the new launcher by name.

A named-launcher addition is NOT done until steps 1–6 are complete on every machine. Partial parity is a regression.

Known exceptions

• Single-account HCB Google services. If a workspace service is only ever consumed under one HCB identity (e.g. Admin SDK calls that only make sense as a super-admin), a single unsuffixed launcher is acceptable. The moment a second identity is in scope, split it.
• Personal Google accounts. chbarlow@gmail.com is out of HCB scope and not covered by this doctrine.
• Experimental connectors under /private/tmp/ during active development. Graduate to ~/.local/bin/ and this parity process before declaring the launcher real.

Review cadence

• Next review: 2026-07-14 (90 days)
• Review trigger: any of — (a) a new HCB human identity is added to any launcher; (b) a Google Workspace service is added to the HCB namespace (e.g. hcb-gdrive-{account} appears); (c) Aleah-related IP dispute changes who can hold or impersonate admin@heartwoodcustombuilders.com; (d) any parity regression surfaces through provider-parity-check --feed.