FFmpeg in AI Agent Sandboxes: Disk, CPU and Timeout Limits

AI agent sandboxes are good for running code, but video jobs push them past their limits. A typical sandbox has one or two CPUs, a few GB of disk, a session or tool-call time limit, and often no network. FFmpeg may not be installed at all. The fix is to keep the sandbox for code and give the agent a tool that runs FFmpeg somewhere else.

This guide lists the limits of two common sandboxes, with sources, explains how each one breaks a video job, and shows how to give an agent FFmpeg through MCP. For all the ways an agent can reach Xora, see FFmpeg for AI agents.

Sandbox limits that matter for video

Sources linked in the table, checked on 16 October 2026.

The Claude code execution tool lists its pre-installed libraries and command-line tools, and FFmpeg is not among them. Because the container has no internet access, it also cannot install FFmpeg or download a video. Other sandboxes let you build an image with FFmpeg in it; the CPU, disk and time limits still apply.

How each limit breaks a video job

• No FFmpeg. The agent writes a correct command and gets command not found. Many agents then try pip install or apt-get, which fails without network access.
• No network. The input is usually a URL. A sandbox with no outbound access cannot read it, and cannot send the output anywhere either.
• Small disk. Input plus output plus temporary files must fit. A 2 GB upload and its re-encode do not fit in 5 GiB with room to spare.
• Few CPUs. Software encoding is CPU-bound. On one CPU, a long 1080p re-encode can take longer than the call or the session allows, and the work is lost when it ends.
• Getting the file out. Even when the job finishes, the output sits in the sandbox. The agent then needs a way to hand the user a large file.

Move FFmpeg out of the sandbox

The agent is good at the part that needs judgment: picking the operation and writing the arguments. The part that needs CPU, disk and network can run in a service built for it. With an MCP tool, the call goes from the agent’s host to the service, not from inside the sandbox, so the sandbox needs no network and no space for the video.

With the Xora MCP server connected, the agent’s tool call looks like this:

{
  "mode": "ffmpeg",
  "input_files": { "in_1": "https://example.com/interview.mov" },
  "output_files": { "out_1": "interview_720p.mp4" },
  "ffmpeg": {
    "args": ["-i", "{{in_1}}", "-vf", "scale=-2:720", "-c:v", "libx264", "-crf", "23", "-c:a", "aac", "{{out_1}}"]
  },
  "idempotencyKey": "interview-720p"
}

The server returns { id, state: "queued" } at once. The agent polls get_job until the state is completed, failed, rejected or cancelled, then gives the user the signed URL. Nothing runs in the sandbox, so there is nothing to time out there.

When the file is on the user’s machine and has no URL, the agent can call create_upload, send the file with one HTTP PUT, and pass the uploadId to create_job. This step needs network access from wherever the agent runs, such as Claude Code on the user’s computer.

Keep the sandbox for what it does well

A good split for agent workflows:

Failed and rejected Xora jobs cost nothing, and errors come back as JSON with a code, so the agent can read what went wrong and try again. Read more in LLMs write good FFmpeg commands.

Next steps

• How to give Claude FFmpeg with an MCP server.
• Run FFmpeg jobs from Cursor with MCP.
• FFmpeg for AI agents: MCP server, REST API and agent skill.

Frequently asked questions

Can Claude's code execution tool run FFmpeg?

Not reliably. Its documented pre-installed tools do not include FFmpeg, and the container has no internet access, so it cannot install FFmpeg or download an input video. It also has 1 CPU, 5 GiB of RAM and 5 GiB of workspace storage. Give Claude an FFmpeg tool through MCP in place of the sandbox.

Why do FFmpeg jobs fail in agent sandboxes?

Usually for one of four reasons: FFmpeg is not installed, the sandbox cannot reach the input URL, the files do not fit on the sandbox disk, or the encode takes longer than the tool call or session allows.

How can an agent run FFmpeg without a sandbox?

Give it a tool that runs FFmpeg somewhere else. With the Xora MCP server, the agent sends the FFmpeg arguments in a create_job call, polls get_job, and gets a signed URL for the output. The MCP call comes from the agent's host, so the sandbox needs no network access or disk for the video.

Is it safe to let an agent run FFmpeg commands?

Running them in an isolated service is safer than running them on your own machine. Send arguments as an array, not a shell string, so the agent cannot run other shell commands. Limit what the API key can do and how much it can spend, and keep inputs to URLs you allow.