Troubleshooting

Most run problems fall into a handful of categories: billing gates, approval gates, connector auth, sandbox limits, and outbound-request blocking. This page covers the common ones and how to fix them.

A run won't start

If a run fails before doing any work, it's almost always the billing gate. The platform checks, in order: do you have a BYOK key saved, are you on a paid plan with a positive credit balance, or neither.

• FREE plan, no key: the run can't start. Add a BYOK key (see Bring your own keys) or upgrade to a paid plan.
• Paid plan, credit balance at zero: same result — either wait for your plan's next credit refresh, upgrade, or add a key so the run stops drawing from platform credits.

See Plans and credits for the full metering breakdown.

A destructive action didn't happen

This is expected behavior, not a bug. When an agent's tool call is destructive, the run halts at an approval gate and waits for a human to approve before it acts — it does not execute the action and then ask. Check the run's execution trace for a pending approval, review what the agent is proposing, and approve (or reject) it. The run resumes from that point once you respond.

A connector call is failing

Connector calls fail most often because the underlying credential has expired or been revoked on the third-party side. Steps to fix:

1. Re-authenticate the connector — re-run the OAuth flow, or re-paste a fresh API key/token, depending on how that connector authenticates.
2. If the connector recently changed its API in a way that broke the integration, the platform can propose a self-healing patch — an approval-gated auto-patch to the connector call. Check for a pending patch proposal and approve it if it looks correct.

A code_execution step is erroring

code_execution runs in a sandbox with intentional limits:

• JavaScript runs in a QuickJS WASM isolate: no host filesystem, no network, no process access, a 64MB memory ceiling, and a 5-second hard timeout.
• Python runs via Pyodide (CPython compiled to WASM) in a worker thread with the JS FFI bridge stripped — import js will fail by design.

If a step errors, check whether it's hitting one of these boundaries: trying to read/write files, make a network call, exceed the timeout, or use the stripped FFI bridge. These aren't bugs to work around inside the sandbox — rewrite the step to avoid the restricted operation, or use api_call or a connector instead of trying to reach the network from inside code_execution.

An api_call step is blocked

Outbound api_call requests are IP-pinned for SSRF protection: connections are pinned to a pre-validated public IP, and private, loopback, link-local, and cloud-metadata addresses are blocked outright. If a call is blocked, check the target URL — if it resolves to a private or internal address, it will not be allowed regardless of intent. This applies to all outbound connections the platform makes on your behalf, including MCP transports and webhook delivery, not just api_call.

Still stuck

If none of these match what you're seeing, check the run's execution trace first — every step records the tool called, its arguments, and its output, and the "explain this run" narration can suggest a fix for a failed run. Beyond that, visit the help center or contact us directly.