Installing AgentKit on cloud and CI: Claude Routine, GitHub Actions and a few traps

Article 9/20 in the AgentKit v3 onboarding series. About an 8 minute read.

Let me be clear up front: AgentKit's official docs do not yet have a dedicated cloud/CI page. This article is how my team and I do it, assembled from flags and behaviors that really exist in ak 3.0.0. Wherever something is my own recipe, I say so.

Good news: AgentKit itself is run by a Claude Routine that fires every hour, so none of what follows is theory.

1/ The simplest way: commit the kit into the repo ✅

If you install the kit at project scope (see article 4), all the skills, agents and hooks live inside the repo (for example ./.claude for Claude Code). Commit them to git:

ak kit init engineer --yes
git add .claude .agentkit
git commit -m "feat: add AgentKit engineer kit"

That covers most cloud cases. Claude Code on the web, Claude Routine, or any environment that clones the repo will see the skills immediately, with no need to install ak and no login.

This is the approach I recommend first, because: no secret has to go up to the cloud, and the whole team has the same skill version.

2/ When you need to run ak on a cloud machine ✅

If you really need ak on the cloud (installing the kit at run time, using ak secrets, running ak doctor...):

Install

curl -fsSL https://agentkit.best/install.sh | sh

Log in without a human

Use an API key (create one on the /account/api-keys account page on agentkit.best). Two safe ways, and both keep the key out of the process argument list:

printf '%s' "$AK_KEY" | ak login --api-key-stdin

or:

export AGENTKIT_API_KEY="..."   # take it from the environment secret store, do not hardcode
ak login

There is an --api-key flag, but it shows the key in the process list, and ak prints a warning. Don't use it on a shared machine.

Don't mix them up: the license key (ak_license_...) is only for activating the desktop app and cannot log the CLI in.

Install the kit without questions

ak kit init engineer --target claude-code --yes --no-interactive

Every ak command has --no-interactive and --json. With --json, non-interactive is implied.

Auto-update switches itself off in CI ✅

When the CI environment variable is present (GitHub Actions, GitLab CI... all set it automatically), ak's auto-update does not run. To be sure in other environments, also set:

export AK_NO_AUTO_UPDATE=1

Pin the kit version so every build is identical:

ak kit init engineer --version <kit-version> --yes --no-interactive

Check the kit version on your own machine with ak versions, then pin exactly that number.

3/ GitHub Actions example (my recipe)

name: agentkit-check
on: [pull_request]

jobs:
  doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install ak
        run: curl -fsSL https://agentkit.best/install.sh | sh
      - name: Log in with API key
        env:
          AGENTKIT_API_KEY: ${{ secrets.AGENTKIT_API_KEY }}
        run: ak login --no-interactive
      - name: Check the environment
        run: ak doctor --json

Notes:

• Keep AGENTKIT_API_KEY in GitHub Secrets, never in the workflow file.

• If the install step says ak is not on PATH, add the install folder (usually ~/.local/bin) to $GITHUB_PATH.

• Rely on exit codes instead of reading text: for example 15 means renewal required, 4 means another operation is holding the lock.

4/ Claude Routine: agents running on a schedule in the cloud

A Claude Routine is a Claude Code agent that runs on a schedule inside Anthropic's cloud environment. A real example: the AgentKit repo has a routine that runs every hour, gathers pull requests that are ready, rebases them, runs tools/preflight.sh on the cloud machine, then puts the whole batch onto the dev branch. It runs in Claude's cloud environment, not in GitHub Actions.

A few lessons I took from that routine, which apply to you too:

1. Run dry-run first until every condition is fine. AgentKit's routine has MODE: dry-run: it still reviews, checks and reports, but does not push git refs or write statuses.

2. Be explicit about which evidence is which. The preflight result on the cloud machine is the routine's evidence, not CI evidence. Don't blend the two.

3. Limit who may write results. Only listed accounts may mark something as "checked".

4. Use a lock. If two runs overlap, the later one has to wait.

Setting up a routine with the kit already committed in the repo (the approach in section 1) is enough for the agent to have the full /ak-plan, /ak-cook, /ak-ship skills.

5/ CloudHarness: running agents in a remote sandbox 🧪

Want the agent to work in an isolated clone on a server instead of on your machine? That is CloudHarness MCP's job. The v3.0.0 release has a ready-made cloud-harness kit package, but this runtime has no certified measurements yet. Details and security warnings are in article 10.

Cloud/CI checklist

• Prefer committing the project-scope kit into the repo

• Keep the API key in the environment's secret store, log in with --api-key-stdin or AGENTKIT_API_KEY

• --yes --no-interactive (or --json) on every command

• Pin --version for the kit

• AK_NO_AUTO_UPDATE=1 if the environment does not set CI

• Read exit codes, don't read text

Next article: The AgentKit ecosystem →

Sources

• ak login --help (ak 3.0.0): --api-key-stdin, AGENTKIT_API_KEY, the --api-key warning, license key only for the desktop app

• ak kit init --help (ak 3.0.0): --version, --no-interactive, --json, exit code table

• AgentKit's real routine: agentkit/docs/operations/beta-train-routine.md and docs/operations/ci-policy.md (tag v3.0.0)

• agentkit-docs documentation: no dedicated cloud/CI page (checked 02/11/2026), CI is only mentioned in reference/cli/login