If the blocker is a security review, Claude Code CLI is the one to take into the room. It is the only one of the four that publishes a procedure you can actually run: a GPG-signed manifest of SHA256 checksums for every release, signed apt, dnf and apk repositories with a published key fingerprint, Apple notarization on macOS and an Authenticode signature on Windows. It is also the only one with a documented setting that makes the agent refuse to start outside an approved version range, and the only one with a hard dollar ceiling on an unattended run. OpenAI, GitHub and Cursor all document how to install their CLI and none of them document how to verify what you just installed.
That is a narrow claim and it is worth stating precisely, because it is easy to turn into an unfair one. Not documenting a verification procedure is not the same as not signing a binary. Homebrew, WinGet and npm each perform their own integrity checks on the packages they serve, so a developer installing Codex CLI through a cask is not running something unchecked. The difference is whether your organization can produce evidence on demand. A reviewer asking "how do we know this binary is the one the vendor shipped" wants a command and an expected value, not an argument about transitive trust in a package manager. Only one of these four hands you that command.
Every fact below was read from the vendors' own documentation on September 2, 2026.
What each vendor documents, side by side
| Claude Code CLI | Codex CLI | Copilot CLI | Cursor CLI | |
|---|---|---|---|---|
| Published checksum or signature check | Yes, signed manifest per release | Not documented | Not documented | Not documented |
| Signed OS package repositories | apt, dnf, apk with a published fingerprint | No repositories | No repositories | No repositories |
| Platform code signing stated | macOS notarized, Windows Authenticode | Not documented | Not documented | Not documented |
| Slow release channel | Yes, stable, about a week behind | Not documented | Not documented | Not documented |
| Version floor for updates | minimumVersion | Not documented | Not documented | Not documented |
| Refuses to run outside a version range | requiredMinimumVersion, requiredMaximumVersion | Not documented | Not documented | Not documented |
| Auto-update can be switched off | DISABLE_AUTOUPDATER, DISABLE_UPDATES | Update is a manual command | Update is a manual command | On by default, no documented off switch |
| Hard dollar cap on one unattended run | --max-budget-usd | None published | None published | None published |
| Turn cap on one unattended run | --max-turns | None published | None published | None published |
What a security review actually asks about a coding agent
Reviews vary, but the questions converge. Where did this binary come from and can we prove it. Which version is running on which machine, and who decided that. What can it read, and what can it execute. What happens when it runs without a person watching. And what does it cost when that goes wrong. Notice that only the last of those is a finance question, and notice that three of the five are really the same question about change control wearing different clothes.
The reason coding agents attract more scrutiny than a typical developer tool is not that they are AI. It is that they read your entire codebase and execute commands on a machine that has credentials. A linter reads your code. A test runner executes commands. An agent does both, decides which commands to run on its own, and does it against whatever the developer happened to have authenticated to that morning. That is a legitimate reason for a reviewer to slow down, and the vendors that make this easy are the ones that hand you controls rather than assurances.
Verifying the binary you install
Anthropic publishes a manifest.json for each release containing SHA256 checksums for every platform binary, signed with a GPG key, so verifying one signature transitively verifies every binary the manifest lists. The key lives at a fixed URL, and the fingerprint you should see is 31DDDE24DDFAB679F42D7BD2BAA929FF1A7ECACE. Manifest signatures exist for releases from 2.1.89 onward; earlier releases publish the checksums without a detached signature. On macOS the binary is signed by Anthropic PBC and notarized by Apple, verifiable with codesign. On Windows it carries an Authenticode signature you can check with Get-AuthenticodeSignature. Linux binaries are not individually code-signed, which Anthropic says plainly rather than glossing over, and points you at the manifest instead.
The apt, dnf and apk repositories matter more than they look. They are the route that puts the agent inside your existing patching workflow instead of alongside it, which is usually what a reviewer wants: one process for updating software on a machine, not one process plus an application that updates itself. There is a trap worth knowing before you write the runbook. If the signing key download fails, nothing breaks at install time. It breaks later, at apt update, with NO_PUBKEY BAA929FF1A7ECACE, by which point nobody remembers the step that was skipped.
The other three vendors document install commands and stop there. That is a reasonable choice for a developer tool aimed at individuals, and it is a gap the moment the tool has to clear a formal review.
Pinning the version your team runs
This is where the gap is widest, and where two similarly named settings are routinely confused into a guarantee nobody actually has. minimumVersion constrains updates only: background updates and claude update refuse to install anything below it. It does not stop an older build already sitting on a laptop from running. If your control needs to be enforced rather than encouraged, requiredMinimumVersion and requiredMaximumVersion in managed settings are the pair that makes Claude Code refuse to start at all outside the range you approved.
Underneath that sits a release-channel choice. The stable channel serves a build roughly a week old and skips releases with major regressions, against latest which ships everything immediately. A week of soak time is a modest control, but it is a real one and it costs nothing. One quirk to write down: on Homebrew the channel is chosen by which cask you install, claude-code for stable and claude-code@latest for latest, not by the setting. A team that sets autoUpdatesChannel and installs the wrong cask has configured nothing.
There is a related decision most rollouts get backwards. Only the native install auto-updates. Homebrew and WinGet do not unless you opt in with CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE, and apt, dnf and apk never can, because those upgrades need elevated privileges. Teams often pick a package manager for governance reasons and then discover six months later that half the fleet is running builds from the spring. Decide which of those you want, then configure it, rather than inheriting it from a habit.
Capping what an unattended agent can spend
An interactive agent is bounded by a person's patience. An agent behind a webhook or a nightly job is bounded by nothing until you bound it. Claude Code's print mode takes --max-budget-usd, a hard dollar ceiling for a single run, and Anthropic documents that subagent spend counts toward the same cap, with further subagents failing once it is reached. Pair it with --max-turns, because a dollar cap stops runaway spend while a turn cap stops a runaway loop before it becomes spend. The default for turns is no limit at all, which is the sort of default people discover the expensive way.
We went looking for the counterexample before writing that. OpenAI's codex exec documentation publishes neither a per-run dollar cap nor a turn cap; Codex meters a rolling five-hour message window instead, which protects OpenAI's capacity rather than your budget. Cursor CLI bills two monthly pools at model rates and tells you afterwards. Both are workable, and neither lets you name the number before the run starts. If your review includes a financial control rather than only a security one, that distinction is the answer to it.
Is Claude Code CLI safe to run on a work machine?
Safe is the wrong frame; scoped is the right one. The agent runs locally and executes real commands with your credentials, so the meaningful controls are the permission mode it starts in, whether command execution is sandboxed, and what it is allowed to reach. One detail deserves to be in your rollout doc: the default permission mode is not the same on every plan. Anthropic documents auto mode, where a classifier approves actions instead of prompting you, as the built-in starting mode on Pro, Max and Team plans, and manual mode on other plans. So a pilot run on personal Pro seats behaves less conservatively than the Enterprise rollout that follows it, which is a good way to be surprised twice.
On Windows, sandboxing is not universal either. Native Windows and WSL 1 do not support sandboxed command execution; only WSL 2 does. If your security posture assumed the sandbox was always present, that assumption is worth checking against how your developers actually installed the thing.
Which one should you take to your security review?
A regulated or change-controlled team: Claude Code CLI, installed from the signed apt, dnf or apk repository on the stable channel, with requiredMinimumVersion and requiredMaximumVersion set in managed settings. That combination gives you a verifiable package source, a deliberately aged build and a version range outside which the agent will not run. Nothing else in the category offers all three.
An organization already standardized on GitHub: Copilot CLI, because the governance you care about lives in your GitHub organization rather than in the binary, and because a tool your admins already control centrally is worth more than a verification procedure nobody will run twice. We break its costs down in GitHub Copilot CLI pricing and install.
A team that wants several model vendors on one invoice: Cursor CLI, with the understanding that it auto-updates by default and that your change-control story will have to be built around it rather than configured into it.
A team already paying for ChatGPT: Codex CLI, which is the cheapest evaluation in the category because it is already bought. Note the trade you are making: its five-hour window is a ceiling you cannot exceed, which is a budget control of a sort, but it is OpenAI's control rather than yours. The detail is on our Codex CLI page.
Whichever you pick, the review will go faster if you arrive with the controls written down rather than described. Reviewers are not looking for a tool with no risk, they are looking for evidence that someone thought about the risk and can show the control that answers it, mapped to the framework clause it satisfies. Half the delay in approving a developer tool is not the tool, it is the two weeks spent assembling that paperwork after the fact.
Where an agent that opens pull requests changes the question
All four of these put an agent in a terminal on a developer's laptop, which is why the review is about binaries, versions and local permissions. That is a real set of questions and it is worth answering properly. It is also worth noticing that the questions exist because of where the agent runs.
Agentcode connects to a GitHub or GitLab repository, takes a task, plans it, edits the code, runs your test suite and opens a pull request. There is no binary on a laptop to verify, no version to pin across a fleet, and no unattended local shell to scope. What it produces is a diff that goes through the review your team already has, and it never merges on its own, so branch protection and reviewers stay exactly where they are. It costs $29 a month billed yearly, flat. That is a narrower product than a terminal agent and we would rather say so than pretend otherwise. If you are weighing both shapes, the full Claude Code CLI breakdown covers the terminal side honestly, and the AI coding tools worth shortlisting covers the field.