e2e + mockServer proxy can break HTTPS dapp navigation due TLS trust/cert validation

[cryptotavares]

Summary

When running in e2e context with mockServer.enabled=true, HTTPS dapps (e.g. https://metamask.github.io/test-dapp/) can fail to load because all traffic is routed through the mock proxy and TLS validation/certificate trust breaks in practice.

This makes mockServer mode unreliable for workflows that need to open real HTTPS dapps while still mocking selected APIs.

Why this is relevant to client-mcp-core

client-mcp-core defines and forwards context configuration (mm_set_context -> setContext(context, options)) and exposes context metadata (mm_get_context), so this is the right place to define safer/clearer proxy-mode semantics and expected behavior.

Observed behavior

• Context is set to e2e with mock server enabled.
• Launch succeeds, but navigating to HTTPS dapps may fail with certificate/SSL-style errors.
• In this mode, operator expectation is usually: "mock specific endpoints, but still open normal HTTPS dapps".

Reproduction

1. mm_cleanup
2. mm_set_context { "context": "e2e", "options": { "mockServer": { "enabled": true, "port": 8000 } } }
3. mm_launch { "stateMode": "default" }
4. mm_navigate { "screen": "url", "url": "https://metamask.github.io/test-dapp/" }
5. Observe TLS/cert failures or inability to load the dapp in some runs/environments.

Local research notes

In client-mcp-core

• mm_set_context forwards options transparently to the session manager (src/mcp-server/tools/context.ts).
• ISessionManager.setContext(context, options) and getContextInfo() are generic and currently expose capability availability, not operational proxy/TLS status (src/mcp-server/session-manager.ts).

In MetaMask extension consumer implementation (where issue manifests)

• Mock server starts and, when running, its host:port is passed as browser proxy.
• Browser launch uses proxy args and ignoreHTTPSErrors when proxy is set.
• Mock server uses HTTPS via generated CA cert.
• This combination means HTTPS trust behavior is critical and can still fail depending on proxy mode / cert trust path.

External context

• Playwright ignoreHTTPSErrors is not always sufficient for all proxy-intercept TLS scenarios.
• Mockttp HTTPS interception requires proper CA trust strategy.

Proposal

Introduce explicit proxy/TLS mode semantics at the API level (even if implemented by consumers):

1. Add explicit proxy mode concept for e2e context options:
   • proxyMode: "tunnel" | "mitm" (or equivalent)
   • Default should favor safer/more compatible behavior for opening normal HTTPS dapps.
2. Document expected TLS trust requirements for MITM mode.
3. Extend mm_get_context to surface operational proxy/mock TLS state (not only capability presence), e.g. whether mock server is enabled/running and effective proxy mode.
4. Clarify recommended behavior for mixed usage: "mock API X but still navigate to arbitrary HTTPS dapps".

Acceptance criteria

• Clear documented behavior for HTTPS navigation under mockServer.enabled=true.
• Deterministic way to run e2e with mock server and still open HTTPS dapps.
• Context/status APIs expose enough runtime state to diagnose this quickly.

Additional note

I already opened a related issue to improve mm_get_context state visibility:

• Enhance mm_get_context to expose mockServer state in e2e #13