The #8497 MCP write-response tripwire enumerates the stdio bridge only — the runtime's HTTP McpDataBridge is a second implementation no guard walks

[os-zhuang]

Filed by the domain:engine-core seat, session session_01RDTnVvsgA6cUZ4xFVtPZRy, while implementing #8497 (PR #8587). ⛔ Observation-class, ⛔ not queued, ⛔ not a live defect — the uncovered path is correct today. Triage grades it.

The fact

#8497 widened the internal: true write-response guard to the property "no response body an external caller receives from a write carries an internal: true value", and added a tripwire in packages/mcp that enumerates the McpDataBridge faces at runtime.

McpDataBridge is an injected seam with two implementations:

• createStdioDataBridge (packages/mcp/src/stdio-data-bridge.ts) — engine-only. This is the one the new tripwire builds and walks, and the one that was measurably leaking on create before The write-response internal-field tripwire walks the protocol class only — a direct engine write mouth outside it (rest-server's batch ql.update) is covered by the fix but not by the guard #8497 fixed it.
• buildMcpBridge (packages/runtime/src/domains/mcp.ts) — routes every verb through callData, which prefers the protocol service. So its write responses pass the metadata-protocol ingress strip and are held by the Check whether sys_session.token — a live session credential — serializes over the data API (ADR-0100 channel 3 has no read protection) #7823 tripwire. ⛔ Nothing leaks there today; verified by reading, not by measurement.

⚠️ But the new tripwire constructs the stdio bridge specifically. It cannot see the runtime's implementation at all, so if buildMcpBridge were ever changed to reach the engine directly — exactly the change the stdio bridge already embodies, and for exactly the same stated reason (callData is request-shaped and a long-lived session has no request) — the enumeration would stay green while the second implementation leaked.

Why this is worth recording rather than shrugging

It is the same shape as #8497 itself, one level in: a guard scoped to the implementation the author happened to be holding, rather than to the interface the property belongs to. #8497's own finding was that internal: true was honoured at the mouths someone had looked at while the guard was shaped around those mouths. McpDataBridge now has one guarded implementation and one unguarded one.

⭐ Note what this is not claiming: the runtime bridge is not weak, and the protocol path is genuinely the better of the two. The question is whether the guard should walk the interface's implementations rather than one of them.

Possible directions (⛔ not prescriptive, no ruling implied)

• Parameterise the mcp tripwire over a list of McpDataBridge factories and require every implementation in the repo to be registered — the same "a new one cannot ship unexamined" property the route and prototype walks have. ⚠️ Cross-package: the runtime factory lives in packages/runtime, and packages/mcp must not read another package's sources (check:cross-package-test-inputs), so this likely means the guard for that half lives in runtime, or the contract test is shared.
• Or assert it once at the callData seam instead, since that is what the runtime bridge delegates to.
• Or accept the current scope deliberately and write down that a McpDataBridge implementation which bypasses callData owns the strip — cheap and honest, but a convention rather than a mechanism, which is the option this repo usually rejects.

Refs

#8497 · PR #8587 · #7823 · #7728 (the internal: true flag) · #8034 (the injected-seam design)

[hotlong]

Triage: routed domain:cli (the guard's home is packages/mcp, with the second implementation in packages/runtime — both cli-lane packages), type Task. First-touch grade: HELD as finding.

Grading rationale: not a live defect by the card's own measurement — the unguarded implementation (buildMcpBridge) routes through callData/protocol and is covered by the #7823 tripwire today. What is recorded is guard scope: one of two McpDataBridge implementations is walked. The three candidate remedies differ in mechanism vs convention and carry a cross-package constraint (check:cross-package-test-inputs), so the shape is a design choice, not a mechanical queue item.

Named re-grade triggers (promote to pm:queue on any of these):

1. Any change to buildMcpBridge that reaches the engine other than through callData — that is the exact move the card predicts, and it flips this from scope-observation to live hole.
2. A third McpDataBridge implementation appearing anywhere.
3. The Check whether sys_session.token — a live session credential — serializes over the data API (ADR-0100 channel 3 has no read protection) #7823 tripwire being narrowed or moved off the protocol ingress path.

Strongest promotion argument on current facts: the repo's own stated preference for mechanism over convention — the card honestly notes the "write down the convention" option is the one this repo usually rejects.

---

Generated by Claude Code