Feature request: opt-in fatal mode for ambiguous terminal response delivery

[PatrickM-Labs]

Summary

Would you consider an opt-in, default-off mode for security-sensitive MCP servers
where any non-definitive delivery of a terminal MCP response makes the entire
tunnel runtime fatal before another command-specific downstream action can begin?

The normal availability-oriented behavior should remain unchanged by default.
The requested mode is for local tools where a downstream operation may already
have caused an irreversible side effect and continued authority is unsafe if the
originating caller's result becomes uncertain.

Current behavior

In current v0.0.13 source, a matching terminal MCP response and delivery of that
response to tunnel-service are separate lifecycle stages:

• forwardResponses
  may finish after a terminal response POST fails without making the runtime
  globally fatal.
• QueueListener
  treats processor failures as per-command outcomes and continues draining work.
• PostResponse
  retries terminal response POSTs and treats both HTTP 200 and HTTP 404 as
  terminal success. The protocol describes 404 as “already fulfilled or no
  longer pending,” which is not a definitive distinction for this use case.

This appears intentional and useful for normal availability. I am not requesting
that it change globally.

Bounded reproduction

I reproduced the following with the exact official Windows run-only artifacts for
v0.0.12 and v0.0.13 in an offline synthetic harness:

1. A synthetic stdio MCP server receives a first tools/call, records one
   harmless first side effect, and returns the matching terminal result.
2. A loopback fake control plane reads the complete terminal response POST body
   but deliberately returns no HTTP acknowledgement until the client cancels the
   request.
3. Only after that delivery becomes ambiguous, the fake control plane supplies a
   distinct second tools/call with a distinct second label.
4. The runtime remains alive, delivers the second command, and the synthetic MCP
   server records exactly first, then second.

The harness uses control-plane in-flight work and MCP concurrency of one, requires
explicit second-command delivery, and rejects duplicate/reordered effects. The
result was reproduced repeatedly against v0.0.13.

This does not show automatic replay of the first operation. It shows continued
new authority after the completed first result becomes uncertain.

The reproduction uses no real tunnel, provider key, ChatGPT workspace, terminal,
credential, privileged process, external network, or private target.

Requested strict-mode contract

The exact configuration/API name is not important. The behavior I am looking for
is:

1. Default off. Existing behavior remains unchanged unless explicitly enabled.
2. One global dispatch fence. In strict mode, one fence (a permit or
   equivalent primitive) spans every command-specific downstream interaction
   through definitive terminal-response acknowledgement across all command
   variants, workers, channels, and transports. Admission is atomic with reading
   one monotonic fatal state. A queued or already-started worker must recheck that
   state under the same fence before it may connect, initialize, write, terminate
   a session, publish mutable auxiliary state, or otherwise reach downstream.
3. Definitive acknowledgement only. Release the fence only after
   tunnel-service returns its documented definitive acceptance bound to the exact
   tunnel request and terminal-response retry identity. HTTP 200 could satisfy
   this only if its committed meaning is documented.
4. 404 is not strict success under its current combined meaning. Treat it as
   fatal unless tunnel-service can return a distinct acknowledgement proving the
   same response was already accepted.
5. Retries may post the same response, never replay MCP. An ambiguous response
   attempt followed by a definitive acknowledgement may finish normally. The
   downstream MCP operation must never be re-dispatched.
6. Global fatal transition. Timeout, cancellation, graceful shutdown,
   deadline expiry, connection loss, exhausted retries, non-acknowledging status,
   or internal state-finalization failure after downstream dispatch but before
   definitive acknowledgement atomically latches fatal while the fence is still held. Once observed, fatal wins over a
   concurrent normal-stop completion and cannot become a clean result.
7. No later authority. Fatal stops polling, rejects/discards queued and
   prestarted work, prevents every future downstream interaction, closes
   downstream transport, and performs bounded cleanup without internal restart.
8. Machine-readable parent signal. The run-only CLI exits nonzero with a stable
   documented fatal category. If strict mode is exposed through the embedded
   client, it returns or exposes a typed fatal cause. Log, metric, health, UI, or
   stderr parsing is not required.
9. Privacy-safe error. The stable cause does not include raw MCP payloads,
   response bodies, authentication headers, runtime keys, or private URLs.

The important ordering is that fatal is latched while the global fence remains
held and before any queued or already-started worker can pass the same admission
check. Merely returning an error from one processor call would leave a race with
other workers, command variants, and channels.

Suggested acceptance cases

Case	Expected strict-mode result
Terminal POST receives documented acknowledgement	Release fence; later command may dispatch.
Ambiguous attempt followed by acknowledged identical retry	Do not replay MCP; release only after acknowledgement.
POST timeout/cancel/network loss/EOF/retry exhaustion	Fatal before any later downstream interaction.
HTTP 404 with current combined meaning	Fatal unless replaced by a definitive same-response acknowledgement.
Second command already queued or returned in the same poll	Never reaches downstream after fatal ambiguity.
Worker already started or blocked	Rechecks the same fence before connect/write/termination/auxiliary action and cannot proceed after fatal.
Different command variant or channel has work	Same global fatal fence prevents downstream interaction.
Effective downstream concurrency above one	Strict startup rejects it or enforces one global lifecycle.
Progress notification delivery fails	Keep fence; still attempt terminal response; terminal acknowledgement controls release.
Graceful stop before dispatch or after acknowledgement	Ordinary clean shutdown may complete.
Graceful stop after dispatch but before acknowledgement	Sticky fatal wins and remains machine-readable.
CLI runtime	Stable nonzero fatal exit after bounded cleanup.
Embedded client, if strict mode is exposed	Typed fatal cause observable without log parsing.
Strict mode disabled	Existing behavior remains unchanged.

Scope clarification

This request is not a claim that a client can prove a model read or understood the
response, defend against a control plane that falsely acknowledges it, report a
cause after an uncatchable external process kill, or prevent an external service
manager from restarting a new process. It asks for a documented
client-to-control-plane acknowledgement boundary and a fail-closed runtime
lifecycle when that boundary is uncertain.

It also does not ask the tunnel client to classify which MCP tools are destructive;
annotations are advisory and errors can follow partial effects. The opt-in mode can
conservatively apply to every downstream command.

Questions

1. Is HTTP 200 from the terminal response endpoint documented internally as a
   definitive accepted/completed acknowledgement for the originating call?
2. Could the current 404 cases be distinguished so strict mode can tell “same
   response already accepted” from “unknown/no longer pending”?
3. Would maintainers prefer a CLI-only nonzero-exit contract first, with typed
   propagation added if strict mode is later exposed through the embedded client?
4. Is a globally serialized opt-in mode acceptable, and where is the earliest
   shared admission point that covers connect/initialization, JSON-RPC,
   notification, session-termination, auxiliary, multi-channel, and already-
   started worker paths?

I can adapt the synthetic acceptance scenario to the interface you prefer. I am
primarily looking for a supported, documented contract rather than a particular
flag name or internal implementation.