Skip to content

When One Command Becomes a Standing Permission

For coding agents, a useful reason to run one command does not establish the scope or lifetime of a saved permission for future commands.

Claude Code, an AI assistant that works in software projects, shows a revealing choice when it asks permission to run a test suite. In Anthropic’s documented permission prompt, a developer can approve this run or save a rule covering matching commands in the project, including future sessions. Both choices get the tests moving. Only one changes what the assistant can do later without asking.

The command has an immediate purpose. The saved rule describes future commands, some of which the assistant has not proposed yet. My reading is that this generalization deserves an explanation of its own: what may change between commands, where the permission applies, and when it ends. A convincing reason to perform today’s task does not settle those questions.

An October 16 security preprint gives this distinction practical weight. Researchers altered project files to steer coding agents toward reusable permissions, assumed those permissions were approved, then altered the files again to pursue unwanted actions without another prompt. Their constructed experiments examined how permission requests could be shaped and used. They did not test whether people would agree to them.

What the saved rule keeps

A coding agent learns how a project works by reading its instructions and trying its setup steps. A missing dependency or failed check can give it a sensible reason to fetch something, install something or inspect another location. Someone who can change the project files can also change which obstacles the agent encounters and which remedies appear relevant.

In the paper’s selected sample-data example, missing dependencies provided the setup context for acquiring reusable permission. A fresh continuation then presented a verification requirement involving a sample-data download. The authors recorded completion of that download goal, an action matching an acquired command rule, and no new permission request. They describe a synthetic success, not an incident on a developer’s computer.

The important transition is from the reason for the first operation to the condition governing the next one. A download may genuinely help complete a report. But a rule that recognizes a download command does not, by itself, retain the reason that particular file was needed. Another command can match the rule while serving a different purpose.

Current Claude Code documentation makes that generalization concrete. Its command-family examples include a rule covering scripts run through npm, a JavaScript package manager. It matches both a build command and a test command that keeps watching for changes. An exact-command rule would admit less variation. The broader rule is useful precisely because the next command need not be identical to the first.

That flexibility can be intentional. A developer maintaining a project across many sessions may want the assistant to run its scripts without repeated interruption. The problem is not that every general rule is mistaken. It is that the task’s immediate need and the desired range of continuing autonomy supply different reasons for choosing one.

This is also why the proposed permission can be a target even when the software checking it works correctly. Project context helps the agent decide what to do; the proposed rule turns some part of that action into continuing authority. An adversary can try to influence that conversion, rather than break the rule-checking mechanism afterward.

How far the experiment reaches

Across four tested combinations of two coding tools, Codex CLI and Claude Code, with their underlying AI models, the researchers’ iterative search elicited permissions judged sufficient for an unwanted goal in 58 of 100 constructed cases, compared with 32 for direct requests. After assumed approval, the follow-up procedure completed 47 of those 58 goals without another prompt. Of those completions, 33 explicitly matched an acquired command rule; the others used different already-authorized routes.

The distinction matters. The experiment shows that permission formation can be an attack target. It does not supply a human approval rate, and not every unwanted outcome depended on using the new grant. Even an action that matched the grant might have been possible another way.

The stronger procedure also received agent feedback and repairs, so its advantage cannot be assigned to task framing alone. Exact tested software releases remain unclear. These results establish a conditional risk in the studied configurations, rather than a ranking of current products or a claim that every saved rule defeats their controls.

One simpler explanation belongs beside the adversarial one: general-purpose tools already cover many legitimate activities. Their breadth is part of their convenience. An attacker may only need to make a legitimate task appear to require that existing breadth, while the agent does the ordinary work of proposing permission.

The practical consequence is that reviewing the current command and reviewing the reusable rule are not interchangeable checks. If the same project context helped shape both, a second presentation of the current task’s rationale does not independently justify the rule’s future reach.

Convenience needs an endpoint

Breadth is only one part of that reach. A permission can also last longer than the work that made it useful.

In a February 2 GitHub comment, a Claude Code user posting as mimkorn described wanting fewer confirmations during a search-heavy conversation without adding permanent project permission. Choosing the permanent option meant remembering to correct the settings afterward. This is one person’s reported preference, but it identifies a concrete mismatch: the useful period of autonomy could end with the conversation, while the saved permission continued.

A session-limited rule and a narrow command rule would address different parts of that mismatch. A short-lived grant can still cover a wide range of actions while it is active. An exact command can remain authorized long after its original task ends. Neither duration nor command specificity substitutes for deciding the other.

Existing controls also matter. Claude Code gives deny and ask rules priority over allow rules, and some prompts offer only one-time approval. A saved command rule operates within those other boundaries. It is not unconditional permission to do everything the named program could possibly do.

The design opportunity is to explain the continuing grant with the same care as the immediate action. Showing why a test is needed explains the interruption. Showing which arguments may vary, which project the rule covers and how long it persists explains the choice to stop interrupting. The latter is a decision about future work, not merely a quicker answer to the present prompt.

Choosing the boundary before the obstacle

One independent research design changes the order of those decisions. CapScope predicts a task-wide permission ceiling from the user’s request and the project’s file tree before reading file contents or tool output. Later grants to delegated agents must fit within that ceiling. The design gives a later permission request something to be checked against, instead of deriving the whole boundary from the setup problem that prompted it.

That separation is useful to think with, but it has limits. The initial prediction can be too broad or too narrow. File names are among its inputs, and attacks embedded in those names were outside its evaluation. CapScope was not tested against the newer paper’s attack procedure.

Nor does moving the decision earlier remove its cost. A user’s initial request may omit a legitimate dependency. A tight ceiling could then stop useful work and require a new authorization. The benefit sought is a boundary chosen from different inputs; the price is that an unforeseen requirement may bring the decision back to a person.

The same distinction is available at an ordinary approval prompt. Approving one sensible command can let the work advance while leaving the larger permission unsettled. Saving a rule can be equally deliberate when its variation and lifetime fit the intended work. What deserves explanation is how the system got from one choice to the other.

The search-heavy conversation described by mimkorn supplies a concrete endpoint: the conversation ends. A permission designed to end with it could provide the requested continuity without leaving a project setting to undo. The consequential design choice comes before the click: whether the rule offered for approval expresses that period of work at all.

Sources

Understand How People and Agents Work Together.

Practical essays, experiments, and lessons from building software for people and agents.

Occasional emails, sent when there is something worth reading. Free to subscribe. Unsubscribe at any time.