Choosing an AI provider for the worker

The ShipifyAI worker does not write code itself. It drives an AI coding CLI in non-interactive mode, one step at a time: it asks the CLI whether a task is clear, lets it implement the change, review its own work, run the tests, describe the pull request, and later address review comments. Until now that CLI was always Claude Code. Every project can now pick one of six providers, and the rest of the workflow — Jira or GitHub Projects, GitHub or GitLab, Slack or Teams, company or freelancer mode — stays exactly the same.

This article explains what each provider needs, how to configure it in the dashboard and on the worker, and where the providers differ in ways that matter for automation.

The six providers at a glance

Antigravity CLI is Google's successor to Gemini CLI. Google moved Gemini CLI users to it in May 2026, so new projects that want Gemini models should pick Antigravity.

Configuring the provider in the dashboard

Open the project form and find the AI coding agent card. The AI provider select decides which CLI the worker runs. When you change it, the API key field relabels itself to the credential that provider expects, and the model field resets to that provider's default.

The model field is free text with suggestions. ShipifyAI does not hard-code a list of models, because vendors ship and retire models every few weeks and a fixed list would always be out of date. Pick a suggestion, type any model id your CLI accepts, or leave the field empty to let the CLI choose its recommended model. Typical values are `sonnet` or `opus` for Claude Code, `gpt-6.1-sol` for Codex, `auto` for Copilot, a slug from `agy models` for Antigravity, a model from `agent models` for Cursor, and a `provider/model` pair such as `anthropic/claude-sonnet` for OpenCode. The value is passed to the CLI through `--model` as a single argument and must start with a letter or digit, so it can never be mistaken for another flag.

Switching the provider of an existing project clears the stored API key and resets the model. An Anthropic key is useless to Codex, and a Claude model alias means nothing to Copilot, so the dashboard asks for the new provider's key before it saves the switch.

The Max budget per task field is shown only for Claude Code, because Claude Code is the only CLI with a hard per-invocation spend cap (`--max-budget-usd`). For the other providers, set spending limits in the provider's own account.

Credentials, provider by provider

Claude Code takes an Anthropic API key from console.anthropic.com. The worker exports it to the CLI as `ANTHROPIC_API_KEY`.

Codex CLI takes an OpenAI API key from platform.openai.com. The worker exports it as `CODEX_API_KEY`, the variable `codex exec` reads for a single run. Codex sessions authenticated with an API key are not affected by the retirement of older models for ChatGPT sign-in, which makes the key the more predictable choice for an unattended worker.

GitHub Copilot CLI needs a fine-grained personal access token with the "Copilot Requests" permission, created on an account that has an active Copilot subscription. Classic tokens that start with `ghp_` are not supported. The worker exports the token as `COPILOT_GITHUB_TOKEN`. Do not reuse the repository token of the project: give Copilot its own token so that revoking one does not break the other.

Cursor CLI takes an API key from the Cursor dashboard, exported as `CURSOR_API_KEY`.

Antigravity CLI uses the Google login cached on the worker by default. Run `agy` once interactively on the worker to sign in. If you prefer an API key, store a Gemini API key in the project and set `"modelProvider": "gemini"` in `~/.gemini/antigravity-cli/settings.json` on the worker; the key alone has no effect without that setting.

OpenCode works with many model vendors. The worker exports the stored key under the variable of the vendor named in the model prefix: `anthropic/...` as `ANTHROPIC_API_KEY`, `openai/...` as `OPENAI_API_KEY`, `google/...` as `GOOGLE_GENERATIVE_AI_API_KEY`, and similarly for OpenRouter, Groq, Mistral, xAI and DeepSeek. For any other vendor, or with no key stored, OpenCode uses whatever you configured with `opencode auth login` on the worker.

Installing the CLI on the worker

The official Docker image ships Claude Code, Codex CLI, Copilot CLI and OpenCode. Cursor CLI and Antigravity CLI are distributed only through vendor install scripts, so they are opt-in at build time:

```

docker build \

--build-arg INSTALL_CURSOR_CLI=true \

--build-arg INSTALL_ANTIGRAVITY_CLI=true \

-t shipifyai/worker:latest cli/

```

Outside Docker, `shipifyai start` checks that the selected CLI is installed and authenticated. A missing npm-distributed CLI (`@anthropic-ai/claude-code`, `@openai/codex`, `@github/copilot`, `opencode-ai`) is installed automatically with `npm install -g`. For Cursor and Antigravity the worker never pipes a remote script into a shell on your behalf: it prints the install command and exits, so you can review and run it yourself.

When the project stores no API key, the worker checks the CLI's own login where the CLI offers a status command (`claude auth status`, `codex login status`, `agent status`) and stops with a clear message if you are not signed in.

Permissions and allowLists

Every CLI has its own permission model, and the worker maps the same two settings onto each of them.

When `SHIPIFYAI_DANGEROUSLY_SKIP_PERMISSIONS` is on, which is the default inside the official image, the implementation steps run with the provider's full bypass: `--dangerously-skip-permissions` for Claude Code and Antigravity, `--dangerously-bypass-approvals-and-sandbox` for Codex, and `--allow-all` for Copilot. Cursor runs with `--force` and OpenCode with `--auto` whenever a step needs to edit files.

When the bypass is off, each CLI falls back to its own allowList, and that allowList lives in a different place for each provider. Claude Code reads `permissions.allow` from `.claude/settings.json`. Codex follows its sandbox and approval policy, so the worker runs it with `--sandbox workspace-write` for steps that edit code and `--sandbox read-only` for steps that only answer questions; extra rules belong in `~/.codex/config.toml` or the repository's execpolicy `.rules` files. Copilot always runs with `--allow-all-tools`, which Copilot requires for programmatic use, and narrower rules can be expressed with `--allow-tool` and `--deny-tool`. Cursor reads `permissions.allow` from `.cursor/cli.json`, with entries such as `Shell(npm)`. OpenCode reads the `permission` section of `opencode.json`. Antigravity reads `permissions.allow` from its own settings on the worker.

When a CLI reports that a command was blocked, the worker reports it to the backend, and the Slack or Teams notification and the task comment name the command and the file where the selected provider expects the allowList entry.

The security model does not change with the provider. The real boundary is the isolated worker machine, the scoped repository token and branch protection, as the security article explains. Whatever provider you pick, keep the cheap deny rules for pushes to the default branch and force pushes in that provider's configuration.

Repository instructions

Each CLI reads its own instruction file from the repository. Claude Code reads `CLAUDE.md` and `.claude/`. Codex, Copilot, Cursor and OpenCode read `AGENTS.md`, and Antigravity reads `GEMINI.md` and `AGENTS.md`. Copilot additionally reads `.github/copilot-instructions.md`, and Cursor reads `.cursor/rules`. Vendors occasionally add or rename these files, so check the documentation of the CLI version on your worker if the AI seems to ignore your instructions.

If you might switch providers, or if different teams run different CLIs against the same repository, keep the real content in `AGENTS.md` and make `CLAUDE.md` a short file that points to it. Everything the Claude configuration article says about a good `CLAUDE.md` — a short overview, development commands, conventions, and above all an explicit checks section — applies to `AGENTS.md` word for word.

The review rules from project settings are provider-independent. The worker adds them to every review prompt, whatever CLI runs the review.

Behaviour that differs between providers

Session continuity works everywhere, but through different flags. After a rate limit the worker waits for the provider to answer again and resumes the latest session with `claude --continue`, `codex exec resume --last`, or the `--continue` flag of Copilot, Antigravity, Cursor and OpenCode. The pull request description and, in freelancer mode, the commit plan are produced in the same resumed session, so the CLI describes the change it actually made.

Freelancer mode removes AI markers for every provider. Claude Code additionally gets its own attribution disabled through settings. The other CLIs have no equivalent setting, so the worker tells them never to mention AI or tool names and never to create commits; the worker creates every commit itself, so no CLI can add a co-author trailer.

Antigravity CLI has a known issue where `agy -p` can print nothing when its output is captured by another process rather than shown on a terminal. If the worker logs show empty answers from Antigravity, update the CLI to the latest version before investigating anything else.

A worker can override the dashboard for local experiments: `SHIPIFYAI_AI_PROVIDER` selects another provider and `SHIPIFYAI_MODEL` another model on that one machine, for example to compare Codex with Claude Code on the same project without changing what other workers do.

Which provider to pick

Pick the provider your team already pays for and trusts with your code. If you have no preference, Claude Code remains the default and the best-documented path, with a hard spend cap and the richest permission settings. Codex is the natural choice for teams on OpenAI, Copilot for organisations that already manage Copilot seats centrally through GitHub, Antigravity for teams on Google's models, Cursor for teams whose developers already live in Cursor, and OpenCode when you want one CLI that can talk to many vendors or to your own model gateway.

Where to go next

The worker configuration article walks through every dashboard field and environment variable. The Claude configuration article explains instruction files, skills, MCP servers and allowLists in depth, using Claude Code as the example. The security article explains why isolation, not the CLI's own permission layer, is the boundary that keeps the AI inside its sandbox.

‍

AI Providers