What Coding Agents Do Without Asking: A Permission-Defaults Census

Coding-agent permission defaults are the least documented and most consequential setting in the headless-agent toolchain. Twelve coding-agent CLIs were checked on the same two questions: invoked non-interactively, does the agent write files without asking, and does it run shell commands without asking. The answers split three ways, and two of the twelve sit at opposite ends of the range.

The reason the question matters is that the headless flag is where most automation lives. A CI job, a cron task, a fleet of agents booted in parallel: none of these has a human attached to answer a prompt. Whatever the CLI does when nobody answers is what it does in production. Some CLIs treat that case as “refuse”; some treat it as “go ahead”; one treats it as “go ahead, and there is no flag to say otherwise”.

This page is the dataset, not an argument about it. The complete table is below, every row labelled with whether the behaviour was observed on a machine or read from documentation only. The prose around it points at the rows worth reading twice and records what could not be resolved. It is a companion to the data-terms census that asked a different six questions of an overlapping set of agents.

Every coding-agent CLI has an interactive mode, and in interactive mode the permission story is easy: the agent proposes, the human approves. The census deliberately ignores that path. It looks only at each CLI’s one-shot, non-interactive invocation, the thing you would put in a script, and asks what happens when there is nobody to answer.

The two primary fields are file writes and shell execution, each scored as one of three states: refuses until a flag is passed, asks (or only proposes) and therefore stalls or fails headless, or proceeds without asking. Six secondary fields ride alongside: the flag that enables writes, whether a genuine read-only option exists, what the sandbox isolates and whether it is on by default, how a new directory is trusted, the version checked, and the invocation form actually used.

The scoring is against the CLI’s default configuration on a fresh install. Pre-approved rules, such as Claude Code’s permissions.allow list or Kimi’s static deny rules, change the picture and are noted where they do, but the table records the shipped default, because that is the state a new machine, a CI runner, or a colleague’s laptop starts from. One row is an exception it states on its face: Grok Build’s cell records the value in this machine’s config, because no vendor statement of the factory default was located.

Every row carries one of three source statuses. The difference between the second and third is the part a reader citing a single cell needs most:

The table below is the asset: all 13 rows, no summary substitution. Product names link to the primary vendor page each row was scored against; rows whose source is the CLI itself say so in place of a link. The last column is the confidence tier and, for observed rows, the observation date. Data as of August 22, 2026. The table scrolls horizontally.

Three conventions keep the cells citable. Where a vendor doc states the default, the cell quotes it. Where the default was observed but no doc states it (rows 7, 9, 10), the cell says “direct testing” or names the CLI output it came from. Where neither a doc nor a test resolves the question (Grok’s factory default, Muse under a billed call), the cell records the gap instead of a guess.

The grid plots the two primary columns of the table against each other. Columns are the headless file-write default; rows are the headless shell default. Each CLI sits in exactly one cell. Six of the nine cells are empty, which is itself a finding: no CLI in the set asks about writes but runs shell freely, or the reverse. The two behaviours travel together.

Read the grid as a distribution, not a league table. Seven of 13 rows, a clear majority, ask and therefore stall or fail when nobody answers. Two refuse outright until flagged, which for an unattended job is the same outcome with a cleaner exit. Four proceed. Of those four, one has no flag that changes the behaviour under -p(Kimi Code), one is a bare binary the local wrapper never calls without a mode (ZCode), one is confined to a directory by design (DeepSeek Harness), and one is a configured value rather than a shipped one (Grok Build).

Two CLIs in the same rough category, bulk and mechanical coding agents sold on prepaid quota, answer the headless question in exactly opposite ways. Kimi Code’s -p mode writes files and runs shell commands with no approval step, and the vendor documentation is explicit that the flags which would tighten it cannot be combined with --prompt. On the census machine, a headless Kimi run wrote a file and executed a shell command with zero flags and no warning, which matches the docs exactly. It is the only row in the table where the read-only column says “none”.

Qwen Code does the reverse. Invoked with -p and no other flag, it generates the code, prints it, exits with status 1 and writes nothing. The vendor calls the headless default Ask Permissions mode; because there is nobody to ask, the practical effect is refusal. Passing -y switches to YOLO mode, which the docs describe as automatically approving all operations including file editing and shell commands. The failure mode is worth naming: a Qwen job that forgot -y does not damage anything, but it also reports failure for work it visibly completed in stdout, which is a confusing signal to debug.

Neither default is wrong in the abstract. Kimi’s position is that a non-interactive call is by definition an unattended one, and its backstop is the static deny list in config.toml, which the docs say remains in effect. Qwen’s position is that unattended should mean inert unless told otherwise. The census records both without ranking them; what it does insist on is that the two positions are a full spectrum apart and that a team moving work between the two CLIs needs to know which end it is standing on. The rest of what Kimi K3 does well, including its 1M-token context and video input, is covered in the K3 capabilities guide; this page is only about the permission default.

A permission prompt and a sandbox are different controls. The prompt decides whether an action is attempted; the sandbox decides what the action can reach if it runs. Most of the table has the first and not the second. Only two rows run headless writes and shell inside a real OS-level sandbox with no flag passed: Codex CLI, whose default sandbox is read-only and which stays sandboxed once workspace-write is enabled (Seatbelt on macOS, bubblewrap on Linux, per OpenAI’s docs), and Muse Code, whose own --help states that approval and an OS sandbox are both on by default.

Gemini CLI (legacy) is the interesting third case and the one most likely to be misread. Its configuration reference states that the sandbox is enabled when --yolo or --approval-mode yolo is used, running inside a pre-built gemini-cli-sandbox Docker image. That is the inverse coupling of every other row: the isolation arrives precisely when the approvals leave. It is a documented-only row, so the behaviour has not been reproduced here, and the track is explicitly a preview release on a product Google has steered users away from since June 2026.

Two negative findings belong in this section. Claude Code has no built-in sandbox beyond OS-level file rules; what changed in the window is narrower than a sandbox: v2.1.236 (August 19) added macOS sandbox wildcard-deny hardening for files like **/.env, and v2.1.234 (August 17) closed the remaining pre-approval file accesses against the NTLM credential-leak vector, both per the changelog and covered in the operator-changes post. And Antigravity CLI’s --sandbox flag, combined with --dangerously-skip-permissions, carries an open vendor-tracked issue in which the agent can bypass the sandbox. A sandbox flag that exists is not the same as a sandbox that holds; the general escape patterns are catalogued in the sandbox-escapes reference, and the isolation models themselves in the sandboxing patterns guide.

Folder trust is the gate most automation hits first and documents least. An agent booted in a directory it has never seen either prompts, refuses, or proceeds, and in a headless pane a prompt is indistinguishable from a hang. The fleet boot of August 17 was specifically a zero-dialog boot: every trust store was pre-seeded before the agents started, which is how the mechanisms in this column were verified. They differ more than the permission modes do.

Three rows record no folder-trust gate at all: Qwen Code, Grok Build and bare ZCode (“none observed”). DeepSeek Harness has none for CLI use; the nearest analogue is the web UI’s permission setting, which is not retroactive to sessions already running. That last detail came from a direct finding on August 17, when a web-UI session was discovered set to danger-full-access and reset to workspace-write; the reset applied only to new sessions.

Cursor CLI, GitHub Copilot CLI and Gemini CLI (legacy) are in the table because a permission census of coding agents that omitted them would be incomplete, and they are marked documented-only because none is installed on the census machine. Their cells carry the vendor’s wording and nothing else. A documentation error in any of the three would propagate into the row unchallenged, which is the precise reason the tier is labelled rather than blended into the observed rows.

Two facts adjacent to the Copilot CLI row are deliberately kept out of it. GitHub’s changelog dated August 18 describes enterprise managed settings for Copilot in JetBrains, including permission-mode controls that can disable “Bypass Approvals” and “Autopilot” server-side. That is a control surface for the JetBrains plugin under enterprise administration, not the standalone CLI’s own default, so it is recorded here as its own fact. Separately, GitHub Copilot in Slack and in Microsoft Teams entered public preview on August 21 and run PR work in what GitHub describes as a cloud sandbox; that is a hosted product with its own billing and eligibility wording, not a local permission model, and it is covered in its own post.

The table is designed to be cited cell by cell. The file-write and shell columns answer the two headline questions; the flag column tells you what to add to an unattended invocation; the read-only column tells you whether a genuinely inert mode exists, which for Kimi under -p it does not. The last column is the part to quote alongside any cell: a documented-only row is a claim about documentation, and an observed row is a claim about one machine on one date.

The trend the table makes visible is that the industry has not converged. In August 2026 the headless default for the same action, writing a file, ranges from “exit 1 and write nothing” to “write it, run the build, and there is no flag to stop me”. The projection is that the spread narrows from the permissive end: the in-window change that touched file access on an observed row (Anthropic’s **/.env wildcard deny and the NTLM pre-approval closure) was made at the file level rather than by changing the mode, and Claude Code’s own auto-mode classifier, covered in the auto-mode shift post, is a move toward deciding per action rather than per session. Whether the permissive rows follow is what the next refresh of this page will record.

This slug is stable and the dataset is refreshed in place; the modified date in the page metadata is the refresh marker, and the as-of date travels with the table. For teams standardising an agent toolchain across several of these CLIs at once, the fleet-boot procedure that produced the observed rows is part of our AI transformation work; the table itself is free to use with attribution.