FetchSandbox managed tunnel: a reachable local endpoint is not the same as verified behavior

Building FetchSandbox, one distinction worth naming: a tunnel can connect successfully before any app behavior has been checked.

The managed tunnel polls a cloud relay and forwards to your configured localhost port. Connection setup reports proof_status: not_tested. That reflects the design: connectivity alone produces no receipt. Forwarded requests and responses also travel through that relay, so teams handling sensitive data should factor that in.

Behavior verification is a separate run: configure the expected app behavior under a specific operation, run it, and collect the receipt. Keeping setup results and application test results separate lets engineers inspect each piece of evidence independently.

This post is based on a November 1-2 inspection of the published fetchsandbox-mcp 0.7.30 package, not a new app verification run.

Wire a coding agent to a local app: https://fetchsandbox.com/mcp

When an agent gets a 200 but the app wrote wrong state, does your tooling surface that separately from a network failure, or does it collapse into the same error?