ant CLI Just Got ant apply. It Provisions Agents, Environments, Skills, Memory Stores, and Deployments From Files in Your RepoHey guys, Mr. Technology here.
Anthropic added a new subcommand to the [ant CLI](https://github.com/anthropics/anthropic-cli) on September 3, 2026: ant apply. It creates and updates Claude API resources — agents, environments, skills, memory stores, and deployments — from files in your repository. You describe each resource in a YAML, JSON, or Markdown file, run ant apply, approve the plan it prints, and commit the claude-lock.json lockfile it writes so that the next run, on your machine or in CI, updates the same resources instead of creating new ones. (Claude Platform release notes — September 3, 2026, Manage resources as code with ant apply)
This is a documentation-comparison report. Every claim below is sourced verbatim from the Anthropic platform release notes and the ant apply reference page. I have not run ant apply against a live organization; the operational mechanics below are what the documentation says, not what I tested.
ant apply lands as part of the [ant CLI v1.30.0](https://github.com/anthropics/anthropic-cli) release, with the following documented surface:
1. Five managed resource types. Agents (agents/), environments (environments/), memory stores (memory_stores/), deployments (deployments/), and skills (a directory containing SKILL.md, conventionally under skills/). Each is declared as a file in your repo. 2. claude-lock.json lockfile. Records the ID of each managed resource plus the organization and workspace it lives in, with two hashes (one of what was last sent, one of what the API returned) that detect edits inside or outside the repo. 3. Path-based references between resources. Wherever the API expects another resource's ID, write the relative path to that resource's file instead. ant apply creates them in dependency order and fills in the real IDs. 4. Kind inference from file location. Top-level type field → directory name (agents/, environments/, memory_stores/, deployments/) → file name prefix. Files that match none are skipped unless named explicitly. 5. GitHub URL pinning for skills. A skill reference can be a GitHub URL of the form https://github.com/<owner>/<repo>/tree/<branch>/<dir>. ant apply downloads and uploads that directory, pinned to the resolved commit until you run with --upgrade (set GITHUB_TOKEN for a private repository). 6. CI-grade flags. --dry-run (print the plan, exit 0 even when blocked), --yes (apply without confirmation, required when there is no terminal), --force (overwrite edits made outside the files), --prune (remove resources that are in the lockfile but no longer declared), --upgrade (re-resolve GitHub-pinned skills), --lock-file <path>, --verbose.
The verbatim changelog entry from the September 3, 2026 release notes is the primary source: "Version 1.30.0 of the ant CLI adds ant apply, which creates and updates agents, environments, skills, memory stores, and deployments from files in your repository. Describe each resource in a file, run ant apply, and approve the plan it prints. Commit the claude-lock.json lockfile it writes so that later runs, on your machine or in CI, update the same resources instead of creating new ones. See Manage resources as code with ant apply."
Agent definitions are now reviewable in pull requests. Until today, an "agent" in the Claude API lived in the Claude Console or was created with the older ant beta:agents create flow. Neither was peer-reviewable. With ant apply, the agent file goes through the same review as your application code. A reviewer can comment on the system prompt, the tool list, the model choice, and the agent-to-agent references, all in a diff. The lockfile is committed alongside the change so the next apply on main updates the same agent_011... resource instead of creating a sibling. (ant apply docs — Apply your first agent)
Resource drift between Console and CLI is now detected. If a resource was edited, archived, or deleted in the Claude Console between applies, the plan ends with This plan cannot be applied: and the reason, and ant apply exits with refusing to apply. Pass --force to overwrite the edit or create a replacement. The lockfile also catches silent edits — ant apply walks every file the lockfile tracks, diffs against the remote hash, and refuses to apply if the remote has changed outside these files. (ant apply docs — Edit and reapply)
Multi-resource projects express as a tree of files. The docs example is six files for a one-agent-plus-skill review workflow: agents/reviewer.md, agents/lead.md (a coordinator that delegates to reviewer.md), skills/pr-summary/SKILL.md (the review skill), environments/cloud.yaml, memory_stores/review-notes.yaml, and deployments/nightly.md (a cron-driven deployment that names the agent, environment, and memory store by relative path). ant apply . provisions the whole tree in dependency order. claude-lock.json then has one entry per file. (ant apply docs — Grow it into a project)
GitHub-pinned skills replace ad-hoc copy-paste. A skill reference can be a GitHub URL pointing at a directory in a repo (e.g., https://github.com/anthropics/skills/tree/main/<dir>). ant apply downloads and uploads that directory, pinned to the resolved commit. To upgrade, run with --upgrade. This is the same pattern Terraform uses for module sources and the same pattern npm uses for GitHub-pinned dependencies: one declaration, one lockfile entry, predictable upgrades. (ant apply docs — Grow it into a project)
CI requires Workload Identity Federation, not a stored API key. The docs are direct: "Authenticate with Workload Identity Federation rather than a stored API key, as an identity that reaches the organization and workspace recorded in claude-lock.json. ant apply refuses credentials that resolve to any other organization or workspace." This is the same WIF trust-anchor machinery OpenAI shipped GA for on August 29 (covered in our mTLS + X.509 WIF GA article). For teams that already use WIF in CI, ant apply plugs into the same identity flow. (ant apply docs — Run ant apply in CI)
CI pattern is documented end-to-end. The docs page spells out the four-job recipe: run ant apply --yes . on the default branch after merge (a bare ant apply --yes reconciles only files the lockfile already tracks and skips a newly added one); run ant apply --dry-run . on pull requests to print the plan for reviewers (informational only, exits 0 even when the plan is blocked); commit the updated claude-lock.json at the end of the job even when the apply step failed partway (because a partial apply still records what it created); and run one apply at a time (because nothing locks the lockfile). A complete GitHub Actions workflow is referenced at the CLI README. (ant apply docs — Run ant apply in CI)
For the platform engineer building a Claude deployment pipeline: this is the missing piece. Until today, the only ways to create or update a Claude agent were the Claude Console UI, the older ant beta:agents create flow, or the raw Admin API. None of those were peer-reviewable. With ant apply, an agent definition is a file in your repo, the apply is a CI job, and the rollback is git revert. If your team already runs Terraform, Pulumi, or Helm in CI, the operational model translates directly.
For the founder or VP Engineering scaling agent infrastructure: the lockfile pattern (claude-lock.json) is the architectural choice worth flagging. It is the same answer Terraform gave to "how do I know what is provisioned in production?" — declare everything in files, record the IDs in a lockfile, commit both. The result is that any teammate, any CI runner, any future fork of the repo can reproduce the same agent fleet without poking the Console. If you have ever lost an agent definition when the engineer who wrote it left the company, this is the fix.
For the developer who already uses the Claude API: if you only have one or two agents and you create them in the Console by hand, ant apply is not for you today. The docs are explicit: ant apply cannot adopt a resource you created in the Console or with ant beta:agents create. "Only what's in the lockfile is managed, and applying a file that describes an existing agent creates a second one." If you want to migrate an existing Console-managed agent, you have to export it as code (Claude Console has an Export as code action that produces its own claude-lock.json), then ant apply it from the export. (ant apply docs — Edit and reapply)
For the security team reviewing the change: the deletion semantics matter. Removing a file leaves its resource in place with a warning; --prune removes it (archiving it, or deleting it for a skill — note that skills are deleted, not archived). Renaming a file therefore declares a new resource and leaves the old one in place until you prune. This is closer to kubectl delete semantics than to Terraform's default behavior: a typo in a path can produce a ghost resource. Plan the rename-then-prune dance in your code-review checklist.
Every capability claim in this article is sourced from one of the following primary sources:
ant CLI adds ant apply, which creates and updates agents, environments, skills, memory stores, and deployments from files in your repository. Describe each resource in a file, run ant apply, and approve the plan it prints. Commit the claude-lock.json lockfile it writes so that later runs, on your machine or in CI, update the same resources instead of creating new ones. See Manage resources as code with ant apply."ant apply](https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply) — confirmed verbatim at fetch time 2026-09-05 14:10 UTC. Confirms the five resource kinds, the lockfile shape (version, origin with base_url, organization_id, workspace_id, per-resource kind, id, version, hash, remote_hash), the kind-inference rules, the GitHub-URL skill pinning, the four-job CI recipe, the deletion semantics (warn-then-prune, with skill deletion being destructive), and the flag table (--dry-run, --yes, --force, --prune, --upgrade, --lock-file <path>, --verbose, -v).ant apply CI section. Same WIF trust-anchor machinery OpenAI shipped GA for on August 29.ant apply-managed agents run on.The source-watch signal that surfaced this entry was sourcechange-anthropic_platform_release_notes-ec940b48277b at 2026-09-04 21:02 UTC, ~17 hours after the prior desk sweep at 2026-09-04 20:08 UTC. The ant apply entry was not in the visible top of the release-notes page during the Sep 4 evening sweep.
Cost. The ant CLI is free; the Claude API resources it provisions are billed at the model rates documented in our Anthropic Fable 5.1 / Mythos 5.1 launch article. There is no ant apply-specific fee in the docs.
Risk — ant apply cannot adopt Console-managed resources. The docs say it directly: ant apply cannot adopt a resource you created in the Console or with ant beta:agents create. Only what's in the lockfile is managed, and applying a file that describes an existing agent creates a second one. Migrating an existing Console fleet requires exporting each agent as code (the Claude Console Export as code action), then applying from the export. This is not a transparent upgrade path for fleets already in production. (ant apply docs — Edit and reapply)
Risk — skill deletion is destructive. Removing a file leaves the resource in place with a warning; --prune removes it (archiving it, or deleting it for a skill). The docs explicitly note that skill deletion is destructive, not archival. A botched --prune on a renamed skill directory is unrecoverable from the API side. (ant apply docs — Edit and reapply)
Risk — concurrent applies are unsafe. The docs are direct: "Run one apply at a time, because nothing locks the lockfile." If two CI jobs apply concurrently — for example, a merge to main while a stale scheduled job is still running — the lockfile and the API state can diverge. Plan CI concurrency carefully: a single concurrency group on the apply job is the minimum. (ant apply docs — Run ant apply in CI)
Risk — credentials are pinned to organization and workspace. ant apply refuses credentials that resolve to any other organization or workspace than the one recorded in claude-lock.json. This is a security feature (it prevents an attacker who compromises one CI identity from promoting resources to another org), but it also means you cannot trivially migrate a project from one Anthropic organization to another — you have to regenerate the lockfile.
Limitation — what I did not test. This is a documentation-comparison report. I have not run ant apply against a live organization, not exported an existing Console agent as code, not set up a CI job that runs --yes after merge, not benchmarked the apply time on a multi-resource project, and not validated the GitHub-URL skill pinning against a private repository. The four-job CI recipe, the kind-inference rules, and the flag table are all documentation claims, not tested behavior.
Limitation — coverage of ant CLI surface. This article covers ant apply only. The ant CLI has additional subcommands (ant beta:agents, ant beta:environments, etc.) that are not part of the v1.30.0 ant apply story. If you already use those subcommands, the migration story is out of scope for this article.
ant apply is the change that takes Anthropic's resource model from "managed in the Console" to "managed in your repo." For the half of teams that have been managing Claude agents as bespoke one-offs in the Console and trying to recreate them in each new environment, this is the moment to migrate to files in version control. For the half that was already comfortable with the Console workflow, the migration is real work (export, regenerate lockfile, train the team on the new apply semantics) and the payback is the same payback Terraform has delivered for infrastructure: every agent change goes through PR review, every apply is reproducible, every drift is detected.
The lockfile pattern is the right architectural choice and the deletion semantics are the right conservative defaults (warn-then-prune rather than implicit delete). The CI recipe is honest about its limitations (no concurrent applies, no API-key auth, requires WIF). The migration story for Console-managed fleets is the obvious next product gap; expect that to be filled in a future release.
If you are standing up a new Claude agent project today, write the agent as a file from day one. If you already have Console-managed agents, plan a deliberate migration — exporting each one as code, applying it from a clean directory, retiring the Console counterpart, and adding ant apply --dry-run . to a PR job before you turn on --yes. The four-job CI recipe in the docs is a fine starting point; the only operational discipline you need to add is "one apply at a time."
Today. If you maintain a non-trivial Claude API deployment — agents, environments, skills, memory stores, or scheduled deployments — read the [ant apply docs page](https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply) end to end. The page is short (~1,400 words) and the four-job CI recipe is the operational pattern.
This week. Stand up a test directory with one agent file and a lockfile, run ant apply . against a sandbox organization, and validate that the kind-inference rules match your directory layout. If you already use the Claude Console, export one of your existing agents as code and confirm the export's claude-lock.json applies cleanly to a fresh directory. Add ant apply --dry-run . to a pull-request CI job before you turn on --yes on the default branch.
This month. Migrate your Console-managed agents to file-based definitions. Plan the rename-then-prune dance in your code-review checklist so reviewers catch path typos before they produce ghost resources. Authenticate CI with Workload Identity Federation, not stored API keys; ant apply will refuse any other credential.
Skip if not in scope. If you only have one or two agents and you create them in the Console by hand, ant apply is overkill. The docs are explicit that it cannot adopt Console-managed resources without an export; for a small fleet, the migration cost is larger than the operational benefit. Wait until you have three or more agents, or until you put a Claude agent in a CI-driven workflow, before you adopt this.
ant apply](https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply) (verified verbatim 2026-09-05 14:10 UTC)ant apply CI section)ant CLI GitHub repository](https://github.com/anthropics/anthropic-cli) (referenced for ant apply v1.30.0 source and CI workflow example)ant apply relies on)ant apply-managed agents run on)Originally published: 2026-09-05 14:08 UTC Last verified: 2026-09-05 14:10 UTC No corrections at this time.
This is a documentation-comparison report, not a firsthand test. Every operational claim is sourced from the Anthropic platform release notes and the ant apply reference page. The verification level is documentation comparison + verbatim primary-source quotes.