Skip to main content
FetchSandbox
← Back to setup

Connect FetchSandbox to Codex

Codex CLI and IDE share ~/.codex/config.toml, so you set this up once. After that, your agent can check that your app's integrations actually work against isolated provider twins. You don't need live vendor keys.

What you need first

A FetchSandbox account and Codex CLI or IDE.

01

Get your account key

Grab a key from https://fetchsandbox.com/keys. Keep the real key private and out of chat.

Get account key
02

Configure Codex

In ~/.codex/config.toml, add a [mcp_servers.fetchsandbox] section with url https://fetchsandbox.com/mcp/v1 and an http_headers Authorization value of Bearer YOUR_FETCHSANDBOX_KEY. Replace the placeholder privately. Merge the section in without replacing your other servers. Putting the header in directly means you aren't assuming the IDE inherits your terminal environment. Reference: https://developers.openai.com/codex/mcp.

~/.codex/config.toml
[mcp_servers.fetchsandbox]
url = "https://fetchsandbox.com/mcp/v1"
http_headers = { Authorization = "Bearer YOUR_FETCHSANDBOX_KEY" }
03

Confirm an actual tool call

Reopen your session and run codex mcp list to see the registered configuration. Discovery isn't workflow proof. Next, ask Codex to actually call list_workflows with spec_slug=stripe. It's a read-only connection test.

Confirm an actual tool call
Call FetchSandbox list_workflows with spec_slug stripe and tell me the actual result.
04

Verify your running app and inspect a receipt

Ask Codex to use validate_integration. You agree on the observable behavior, point your app's calls at the supplied twins, invoke the app and inspect the receipt. Local apps use a managed tunnel transport. Hosted apps need a reachable, protected URL.

Verify your running app and inspect a receipt
Use FetchSandbox validate_integration for this running app. Agree the observable expected behavior with me, configure the isolated twins, invoke the actual app and report the receipt, including anything failed or unmeasured. Keep polling the same get_job until it reaches a terminal state.
Signs your setup works

You see an actual list_workflows result for spec_slug=stripe in Codex. After validate_integration, you can inspect a receipt from your own running app.

Scope of this evidence

That receipt records expected versus actual for the agreed scenarios, tested against your configured twins. Other scenarios are unmeasured. A passing reference quickrun doesn't test your code. Related public receipts illustrate workflows, are separate from verifying your own app through this builder, and aren't evidence a native Codex agent ran them. Local apps use the managed tunnel. Hosted apps need a reachable protected URL.

Related receipts

All workflows →

Historical runs recorded against isolated twins. You can inspect each receipt and its evidence. Not a new execution or production certification.

Duplicate charge remediation
stripehubspotgmailasanaslack

Duplicate charge remediation

Passed

Finance needs to refund customers who were charged twice by a billing incident, quickly and at scale, without refunding a disputed or ambiguous payment and with human approval above set limits.

23Passed0Failed0Not measured
Evidence details

Each receipt is one individual dated run against isolated provider twins, not live vendors. The caller declared the app revision, and it is not attested. Workflow docs are pinned to the commit shown here. A status appears only when the original verdict, counts, completeness and app_verified all support it, and counts are never merged. Some source exports, including the n8n lead flow, are not public. These public examples are separate from proving your own app through your builder, and they don't show that each native client was tested.

{"verdict":"verified","complete":true,"applicationVerified":true,"appVersion":{"value":"acme-ops-duplicate-charge-remediation-1.0.0-639dac1","source":"declared"},"sourceRevision":"48d4ded9832981e441fad4e83ed3daf838086ba4"}
zendeskstripesquareslack

Product cancellation and refund

Passed

Customer Experience needs to acknowledge cancellation requests, evaluate subscription terms, obtain exceptions where required, and let the correct customer choose an eligible refund method.

27Passed0Failed0Not measured
Evidence details

Each receipt is one individual dated run against isolated provider twins, not live vendors. The caller declared the app revision, and it is not attested. Workflow docs are pinned to the commit shown here. A status appears only when the original verdict, counts, completeness and app_verified all support it, and counts are never merged. Some source exports, including the n8n lead flow, are not public. These public examples are separate from proving your own app through your builder, and they don't show that each native client was tested.

{"verdict":"verified","complete":true,"applicationVerified":true,"appVersion":{"value":"acme-ops-product-cancellation-1.0.0-269e897","source":"declared"},"sourceRevision":"48d4ded9832981e441fad4e83ed3daf838086ba4"}