Scenario 39: MCP auth, environments, and account switching

Frequency: Occasional · Status: Documented

← Back to scenarios index

Use this when you need to switch Slack workspaces, API tokens, or deployment targets across profiles/layers — or when OAuth MCP servers do not respond after an environment switch.

Quick decision

Full reference: Environments — MCP authentication limitations

Static token workflow (supported)

# Seed from layer MCP env keys
ht environment create work --from-layer my-setup
ht environment edit work --secret SLACK_BOT_TOKEN:keychain:harnesstap/slack-work

ht environment create personal --from-layer my-setup
ht environment edit personal --secret SLACK_BOT_TOKEN:keychain:harnesstap/slack-personal

# Switch and materialize
ht environment use work
ht profile use default --reapply
# or: ht layer apply my-setup --project . --harness claude-code,cursor

Layer MCP definitions should use placeholders, not literals:

"env": { "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}" }

Verify resolved keys before apply:

ht environment show work --layer my-setup
ht profile use default --dry-run

OAuth MCP (host-managed)

After apply, open the target harness and complete OAuth there (Cursor MCP panel, claude mcp, Copilot /mcp auth, etc.). HarnessTap only writes server URL / transport — not OAuth tokens.

Known gaps

• Shipped: Cursor MCP scan/emit and HTTP headers round-trip (via mcp-config-bridge).
• OAuth sessions: Browser OAuth tokens remain host-managed — environment switch does not re-auth for you.

Remaining limitations: Known gaps and fix plan.

Related: Portability limits, Scenario 36.