ORA-2026-0014

Resolution (2026-04-16T01:02Z)

Chad chose Option C — abolish the shared form. Executed by CLAUDE-CLI-MacBook-Air-ORA-01:

• ~/.orbit/claude/managed-mcp.json: removed unsuffixed hcb-gmail / hcb-gcal keys; added hcb-gmail-admin, hcb-gmail-zack, hcb-gcal-admin, hcb-gcal-zack (kept hcb-gdrive as canonical single-identity per ORA-2026-0002).
• ~/.orbit/claude/managed-settings.json: removed mcp__hcb-gmail / mcp__hcb-gcal from allow list; added the four per-identity prefixes.
• provider-parity-check lines 137–146 rewritten: 2 unsuffixed Claude CLI assertions replaced with 4 per-identity assertions + 1 negative-invariant check (Claude managed-mcp.json has no unsuffixed hcb-gmail/hcb-gcal keys — Option C invariant).
• Audit pass confirmed Codex / Gemini / Claude Desktop had no residual unsuffixed leftovers; "more thorough" scope of C collapsed to a clean audit.
• Parity check result: 152/152 PASS (up from 149/149 — net +3 invariants: 5 added, 2 removed).

Shared wrappers retained at ~/.local/bin/hcb-gmail-mcp and ~/.local/bin/hcb-gcal-mcp — they are the impersonation delegation layer that the per-identity wrappers exec into.

Pending for Chad: restart Claude CLI to flush old mcp__hcb-gmail__ / mcp__hcb-gcal__ tool names from the live tool list. After restart, tools resolve as mcp__hcb-gmail-admin__, mcp__hcb-gmail-zack__, mcp__hcb-gcal-admin__, mcp__hcb-gcal-zack__.

---

Observation

As of 2026-04-15, the fleet has three provider surfaces using per-identity HCB Google launchers per ORA-2026-0002 (hcb-gmail-admin, hcb-gmail-zack, hcb-gcal-admin, hcb-gcal-zack) — Codex Desktop, Gemini CLI, and Claude Desktop. A fourth surface, Claude CLI, still declares unsuffixed shared-impersonation MCP keys (hcb-gmail, hcb-gcal) in ~/.orbit/claude/managed-mcp.json. This is not dead legacy — the unsuffixed form routes through the shared wrapper (~/.local/bin/hcb-gmail-mcp) which uses whichever default impersonation the wrapper was built with.

Why this matters (not just cosmetic)

The per-identity launcher pattern is load-bearing for addressable impersonation: each named launcher (hcb-gmail-admin-mcp, hcb-gmail-zack-mcp) is a thin shell that sets HCB_GMAIL_IMPERSONATED_USER before exec-ing into the shared wrapper. Under this pattern, a seat can choose which identity to read/write as on a per-call basis by picking the launcher. Under the shared form, the identity is fixed at wrapper-build time — the caller cannot distinguish admin@heartwoodcustombuilders.com from zack@heartwoodcustombuilders.com at MCP-invocation time.

Current functional asymmetry: a Claude CLI seat cannot natively send a Gmail draft as Zack vs as Admin. A Codex/Gemini/Claude Desktop seat can. For HCB operations involving cross-identity triage (e.g., reading Zack's inbox while drafting from Admin), this is a real capability gap, not a naming preference.

What was already audited

• ~/.orbit/claude/managed-mcp.json: 3 unsuffixed entries (hcb-gmail, hcb-gcal, hcb-gdrive). hcb-gdrive is canonical single-identity per ORA-2026-0002 (only one Drive); hcb-gmail/hcb-gcal are the gap.
• ~/.orbit/claude/managed-settings.json: permissions allow mcp__hcb-gmail / mcp__hcb-gcal (unsuffixed prefix — broad match).
• provider-parity-check lines 137–146: asserts grep -q '"hcb-gmail"' against Claude CLI managed-mcp.json — this hardcodes the unsuffixed form as canonical for Claude CLI specifically. Migrating Claude CLI to per-identity would require updating this assertion OR the parity check would flip to FAIL.
• The shared wrappers ~/.local/bin/hcb-gmail-mcp and ~/.local/bin/hcb-gcal-mcp are NOT deletable — they are the impersonation delegation layer that the per-identity wrappers exec into. Audit confirmed this on 2026-04-15.

Options on the table (no verdict yet)

Option A — Migrate Claude CLI to per-identity parity with the other three surfaces.

• Add 4 entries to managed-mcp.json: hcb-gmail-admin, hcb-gmail-zack, hcb-gcal-admin, hcb-gcal-zack
• Remove 2 unsuffixed entries: hcb-gmail, hcb-gcal
• Keep hcb-gdrive (canonical single-identity)
• Update managed-settings.json allow list: mcp__hcb-gmail → mcp__hcb-gmail-admin + mcp__hcb-gmail-zack
• Update parity script lines 137–146 to assert per-identity forms on Claude CLI
• Cost: ~6 edits + parity update. Restart Claude CLI session to reload MCP list.
• Benefit: full capability parity; no functional gap.
• Risk: any Claude CLI session that referenced mcp__hcb-gmail__ tool names in memory/docs will need to re-learn the mcp__hcb-gmail-admin__ / mcp__hcb-gmail-zack__* forms.

Option B — Codify the asymmetry as intentional and document why.

• Leave Claude CLI on shared-impersonation because (hypothesis) Claude CLI sessions tend to be scoped to single-identity work and the shared form is lower-cognitive-load.
• Update ORA-2026-0002 to explicitly state that Claude CLI is exempt from per-identity requirement.
• Cost: 1 doctrine amendment.
• Risk: locks in the functional gap permanently; future Claude CLI work needing cross-identity Gmail triage will re-discover this and re-open the question.

Option C — Abolish the shared form on all surfaces, including the other three.

• Delete the managed-mcp.json entries for unsuffixed hcb-gmail/hcb-gcal on Claude CLI AND remove any remaining unsuffixed references elsewhere.
• The shared wrapper files on disk stay (still needed as the impersonation delegation target), but no MCP key points at them directly.
• Cost: similar to A but more thorough.
• Benefit: single canonical form across all 4 provider surfaces. Simpler mental model.
• Risk: small — verify no scripts directly invoke the unsuffixed MCP keys.

Recommendation (pending Chad's call)

Option A or C. Both close the functional gap. C is slightly cleaner because it removes the ambiguity entirely rather than leaving the shared form as a "Claude CLI quirk." A is safer if we're unsure whether any Claude CLI workflow implicitly depended on the shared form.

What to check before choosing

1. Do any active Claude CLI workflows (prompts, scripts, docs) invoke mcp__hcb-gmail__* tools? If yes, they would need updating to pick an identity. 2. Does ORA-2026-0002 have language that could be read as permitting Claude CLI exempt? (Spot check: current doctrine text says "current roster: hcb-gmail-admin / hcb-gmail-zack / hcb-gcal-admin / hcb-gcal-zack" — suggests per-identity is canonical for all surfaces.) 3. What breaks if a Claude CLI session tries to send Gmail and the tool name doesn't resolve (user experience of the migration moment)?

Enforcement hook (if Option A or C adopted)

Update provider-parity-check to assert per-identity forms on Claude CLI managed-mcp.json (replacing current line 137–146 unsuffixed assertions). This is the enforcement seam that prevents the gap from re-opening.

Review cadence

Revisit on next HCB cross-identity operation where the gap bites — that's the forcing function. Alternatively, trigger review when ORA-2026-0002 is next amended.