Agent Skills Runtime Constraints Differ by Surface

Agent Skills use one format everywhere: a directory with a SKILL.md at the top, YAML frontmatter carrying a name and description, and optional bundled scripts and resources. That uniformity is deceptive. The file is the same across claude.ai, the Claude API, and Claude Code / Agent SDK deployments — but the runtime underneath it differs sharply, and Anthropic's own documentation calls out three different constraint profiles. Teams that author a skill on one surface and deploy it on another hit these differences as mysterious failures, so it pays to know them up front.

Three surfaces, three sandboxes

On the API, skills execute inside Anthropic's code execution container — a sandbox with Python 3.11 on Linux, 1 CPU, 5 GiB of RAM and disk, and, critically, no internet access and no runtime package downloads. A skill script that calls pip install or fetches a URL will fail here by design. The container does ship a substantial pre-installed library set (pandas, numpy, scipy, scikit-learn, matplotlib, and more), so data-wrangling skills usually work; anything that assumes connectivity does not. The same constraints apply where the API skills surface extends to third-party platforms — Claude Platform on AWS and Microsoft Foundry with a Hosted-on-Anthropic deployment inherit the same skills behavior as the Claude API.

In Claude Code and the Agent SDK, skills load from .claude/skills/ on the local filesystem and run with full network access — because "the environment" is simply your machine or your server. This is the most permissive surface, which makes it both the easiest place to develop a skill and the easiest place to develop a skill that won't survive contact with the API sandbox.

On claude.ai, network access varies with workspace admin settings, so the identical skill may behave differently between two organizations — or between two workspaces in one organization.

Designing skills that travel

If a skill might ever run on the API surface, author it against the strictest sandbox from the start:

Bundle, don't fetch. Reference data, schemas, templates, and lookup tables should ship inside the skill directory (the upload limit is 30 MB total) rather than being downloaded at runtime. This also aligns with the security guidance — skills that fetch external URLs are flagged as deserving heightened scrutiny, so a no-fetch design is easier to audit as well as more portable.

Stick to pre-installed packages. Write scripts against the libraries the API container already has. If a niche dependency is unavoidable, the skill is effectively Claude Code-only — document that limitation in the skill itself.

Fail loudly and early. A script can check for connectivity or a required import at the top and print a clear message ("this skill requires network access; run via Claude Code") instead of dying halfway through a task with a cryptic traceback that Claude then tries to debug on your token budget.

The 3P angle

These runtime profiles map directly onto platform choices. Amazon Bedrock and Google Vertex AI don't offer the Messages-API skills surface at all, so on those platforms the only skills are Agent SDK filesystem skills — which means every Bedrock/Vertex skill runs in the permissive profile, on infrastructure you must sandbox yourself. Conversely, a Foundry team using Hosted-on-Anthropic skills gets Anthropic's locked-down container but must design within its no-network rules. Neither is wrong; they are different risk postures, covered from the security side in Auditing Agent Skills Like Installing Software.

Where to go next

For where skills are available at all, see Agent Skills on 3P Platforms; for how the loading model keeps them cheap, three-level loading; and for the container itself, the code execution tool.

Sources

• Agent Skills overview
• Code execution tool
• Agent Skills guide (Messages API)