Command failed inside sandbox (exit ${result.exitCode}): ${w

Error message

Command failed inside sandbox (exit ${result.exitCode}): ${what}\n${truncate(result.stderr || result.stdout, 4_000)}

What it means

A command executed inside the sandbox exited non-zero and allowFailure was not set. The error includes the exit code, a short label (or 120-char script excerpt — never the full script, which may contain secrets), and up to 4KB of stderr/stdout so you can diagnose the remote failure.

Source

Thrown at deployers/sandbox/src/shared.ts:73

  },
): Promise<{ stdout: string; stderr: string; exitCode: number }> {
  if (!sandbox.executeCommand) {
    throw new Error(
      `Sandbox provider "${sandbox.provider}" does not support executeCommand, which is required for sandbox deploys.`,
    );
  }
  // Run via `sh -c` (argv style): providers pass `command` straight to their
  // exec API as an executable, so a raw script string with spaces would fail.
  const result = await sandbox.executeCommand(
    'sh',
    ['-c', script],
    opts?.timeout ? { timeout: opts.timeout } : undefined,
  );
  if (!result.success && !opts?.allowFailure) {
    // Never echo the full script back: it can contain secrets (env values)
    // or entire base64 upload chunks. Use the label or a bounded excerpt.
    const what = opts?.label ?? truncate(script, 120);
    throw new Error(
      `Command failed inside sandbox (exit ${result.exitCode}): ${what}\n${truncate(result.stderr || result.stdout, 4_000)}`,
    );
  }
  return { stdout: result.stdout, stderr: result.stderr, exitCode: result.exitCode };
}

function truncate(value: string, max: number): string {
  return value.length > max ? `${value.slice(0, max)}… (truncated)` : value;
}

/**
 * Kill the previously launched server (if any) using its pidfile, waiting for
 * the process to exit (bounded, then SIGKILL) so the replacement never races
 * the old server for the port. Safe when nothing is running.
 */
export async function killPreviousServer(sandbox: WorkspaceSandbox, remoteDir: string): Promise<void> {
  const pidfile = shellQuote(`${remoteDir}/${SERVER_PIDFILE}`);
  const script = [

View on GitHub (pinned to 75dd419e61)

Solutions

Read the stderr/stdout excerpt in the message to identify the failing remote command.
Reproduce the command in the sandbox (e.g. via its logs/console) and fix the underlying cause (deps, env, paths).
If non-zero exit is expected for a probe, rerun with `allowFailure: true` and a `label` so the failure is tolerated and readable.
Verify required env vars and files were uploaded before the failing step.

Example fix

// before
await runInSandbox(sandbox, './start-server.sh', { label: 'start-server' });
// after (exit code tolerated)
await runInSandbox(sandbox, './start-server.sh', { label: 'start-server', allowFailure: true });

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await deployToSandbox({ sandbox });
} catch (e) {
  const m = e.message.match(/Command failed inside sandbox \(exit (\d+)\): (.*)/s);
  if (m) {
    logger.error(`sandbox step failed (exit ${m[1]}): ${m[2].slice(0, 500)}`);
    // inspect sandbox logs, then retry or abort
  } else throw e;
}

Prevention

Validate env, deps, and uploaded files before launch steps
Use `label` and `allowFailure` for probe commands with expected non-zero exits
Check the sandbox's own logs when the excerpt is insufficient

When it happens

Trigger: Any runInSandbox command (deployToSandbox, markerCheck, uploadFile, killPreviousServer, launchServer) whose provider result has success=false with opts.allowFailure unset — e.g. the app fails to launch, the upload decode fails, or a marker check misses.

Common situations: Server crashes on boot (bad env, missing deps), base64 upload chunk corruption, stale server process that killPreviousServer cannot kill, package install failures in the sandbox image.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/8fa96dd1b85e6687. Report an issue: GitHub.