How to migrate a coding agent in cron from one CLI to another

Swapping the CLI that runs a coding agent in cron looks like a one-liner: change the binary, keep the prompt. In practice, five layers break, and none of them is the prompt. We lived through that migration on 2026-11-05, when the pipeline that publishes this blog moved from one agent CLI to Verboo Code. Here is what broke and the command that fixes each layer, verified in the verbeux-ai/code v0.15.41 source.

Short answer: recheck the non-interactive mode (-p), auth without a browser, the config directory (~/.verboo), the runtime (engines.node) and the MCP tools protocol. If any of those five is still borrowed from the old CLI, the migration is not done.

Why is switching the agent's CLI not just switching the command?

Because the command is one line, but the environment around it is not. An agent that runs on its own, fired by cron, leans on five layers the old CLI solved silently. Change the binary and each of them can stop working with no warning:

• Non-interactive mode. Cron has no terminal. If the new CLI has no way to run without asking anything, it hangs on the first confirmation.
• Authentication. Cron has no browser. If the new CLI's login opens a page, the session never starts.
• Config directory. Commands, skills and permissions live in a folder that is probably not the old CLI's folder.
• Runtime. Every package declares the Node version it supports, and it is easy to install it on a server that does not match.
• External tools. MCP servers talk over a protocol. Client and server must speak the same revision.

How do you prove the new CLI runs without a terminal?

Before touching any script, run the binary with a harmless prompt and ask for JSON output. If that comes back, the non-interactive contract holds:

verboo -p "reply only: ok" --output-format json

-p (or --print) prints the answer and exits, which is useful for pipes. --output-format only works together with -p and accepts text (default), json (a single result) or stream-json (real-time events). In cron you want json: one object per run, easy to write to a log.

Three flags round out an unattended job. --max-turns caps how many back-and-forths the agent takes before stopping, so the job cannot hang. --max-budget-usd sets a spend ceiling per run. And --no-session-persistence keeps the run off disk, which stops a daily cron from piling up sessions nobody will resume. It is also worth knowing that in -p the workspace trust dialog is skipped, so point the job only at folders you trust.

Where does auth live when there is no browser?

Cron does not open a browser, so the standard interactive login does not work. Verboo Code covers this with two paths, and the choice depends on where the job runs:

Path	How it works	When to use it
verboo auth login --headless	No browser: it shows a URL to open on another device and asks for a code back	A machine you control, where the session can stay saved
ANTHROPIC_API_KEY	An API key passed through an environment variable, with no OAuth session	An ephemeral CI runner or a container that dies at the end of the job

For the key path, the variable is ANTHROPIC_API_KEY itself, not a differently named one. Setting it means you are storing a credential in the environment, so the minimum is to keep it out of the log and limit who can read the job's config.

Why does the old config contaminate the new job?

Because the new CLI does not read the old CLI's folder. Verboo Code keeps everything in ~/.verboo, and the source says explicitly that it neither reads nor migrates global files from another CLI. In practice that means your commands, skills and permissions do not come for free: skills live in ~/.verboo/skills, commands in ~/.verboo/commands and permissions in ~/.verboo/settings.json. Copying one CLI's folder onto the other's does not work, because the format is different.

The exception, and it is intentional, is the sessions directory. By default it stays in ~/.claude/projects, precisely to allow --resume across CLIs. If you want full isolation, just point it elsewhere. And if more than one job runs on the same machine, the cleanest route is to give each one its own config directory:

export VERBOO_CONFIG_DIR=/opt/jobs/blog/.verboo
verboo -p "sync the drafts" --output-format json

That way the job has its own key, its own permissions and its own history, without competing with the interactive session on the same machine.

Which runtime does the package require?

Install with the Node version in mind, not just the CLI version. The @verboo/code package declares engines.node >= 22.0.0. Check before installing on an older server:

node -v
npm install -g @verboo/code
verboo --version

If node -v returns 20, the shortest path is to upgrade Node before fighting npm install. The engine error shows up mid-install and looks like something else.

How do you know the MCP tools arrived?

By the symptom, which is silent. When the client's and the server's protocol revisions do not match, the handshake fails, the tool list comes back empty and the agent simply "does not use" the tool. There is no loud error: the prompt runs, output comes out, and the action that depended on that tool never happens.

So check the list before blaming the prompt. To pin exactly which servers enter the job, use --mcp-config with the right files plus --strict-mcp-config, which ignores any other MCP configuration on the machine. A cron job should always run with the same server list, never with whatever happened to be in the directory.

What should you check before switching the old CLI off?

Run both in parallel for a few days and compare the output, not the feeling. The bar for "migration done" is objective:

1. The job runs twice in a row with no one touching it, and the final artifact matches the old CLI's.
2. Each run's log records how many tools were called and which ones.
3. A simulated failure (bad key, network down) ends with a clear error, not a hung job.
4. The server's node -v matches the package's engines.node.
5. No step still depends on a file that only existed in the old CLI's folder.

If all five hold, you have migrated. If any still leans on the old CLI, that is where the next job will break on its own, on a weekend.