Your coding agent's permission rules had gaps. Update this week

Most teams set up their coding agent's permission rules once, then forget about them. “Ask before running this”, “never read .env”, “don't touch these files”. This week's release notes are a reminder that those rules are code, and code has bugs.

The latest Claude Code releases, 2.1.321 to 2.1.325, fixed several cases where permission and deny rules did not apply as written. Codex changed how it trusts projects in non-interactive runs, which can break CI jobs. Neither is an emergency, but both are worth ten minutes on Monday.

What Claude Code fixed

Straight from the official changelog, version 2.1.321 fixed, among other things:

MCP OAuth requests sending secrets such as refresh tokens to another host when a server redirected them;
a case where a read-only Bash command ran outside the sandbox without a permission prompt;
a case where Bash permission checks judged a file write from the wrong folder and didn't prompt;
deny rules and protected-file prompts not applying to the file that a cp or mv into a directory writes.

Version 2.1.325 added more:

a security issue in how zstd-compressed responses are decoded;
a gap where some compound Bash commands could run without asking;
a case where a Bash allow rule could run a different program than the one it names;
some deny and ask rules not applying to certain Bash commands;
relative deny and ask rules, such as Read(./.env), no longer covering the project after a cd.

Version 2.1.323 also added a start-up warning for Bash allow rules with a * in a variable's value, such as Bash(PORT=* npm run dev), a pattern that can match more than intended. The changelog does not say whether any of these gaps were exploited, and it gives no severity ratings.

What changed in Codex

On the Codex side, a weekly release digest reports that Codex 0.169.0 keeps project config and MCP servers disabled for codex exec in untrusted directories, and that you now declare trust explicitly for non-interactive runs. A write-up of the change says non-interactive runs against an untrusted project now fail at startup, which can break CI jobs that used to just work.

The two sources name the flag differently (--trust in one, --trust-project in the other), so check codex exec --help on your version before you change a pipeline. The direction is the important part: Codex no longer assumes a folder is safe just because a script started it there.

Why this matters beyond these two tools

Permission rules are a guardrail, not a wall. They are written in a small pattern language, matched against shell commands that can be combined, quoted and redirected in endless ways, and enforced by a tool that ships a new version every few days. Gaps like the ones above are normal for software this young. Every agent will have them.

That has two practical consequences. First, your agent's version matters as much as its configuration. A team with careful deny rules on a two-month-old build may be less protected than it thinks. Second, permission rules should be one layer among several, never the only thing between an agent and something you care about.

What to do this week

Update everyone. Check which versions your team and your CI images actually run:
```
claude --version
codex --version
```
If CI pins an old version, bump it. Agents in CI images are the ones most likely to be left behind.
Fix CI before it breaks. If you run codex exec in pipelines, add the explicit trust declaration on jobs that run trusted branches only, never on jobs triggered by pull requests from forks.
Review wildcard allow rules. Look for broad patterns in your settings files, especially * inside variable assignments or after commands that can chain others. Narrow them to the exact commands you mean.
Don't rely on deny rules for secrets. A rule that says “don't read .env” is good. A .env file that isn't in the agent's working directory at all is better.
Use the sandbox where you can. Several fixes above are about commands that slipped past a prompt. An OS-level sandbox and limited network access catch what a pattern match misses.
Make reading changelogs someone's job. Five minutes a week from one person, looking for the words “permission”, “sandbox”, “deny” and “security”, is enough for most teams.

The takeaway

Treat your coding agent like any other dependency with access to your machines: keep it current, know which version runs where, and don't trust a single layer to protect you. The vendors are finding and fixing these gaps quickly. Your part is making sure the fixes actually reach every laptop and every pipeline.

Sources: Claude Code changelog (versions 2.1.321 to 2.1.325), “This week in Claude Code, Codex and Gemini CLI” (14 November 2026), Codex CLI explicit project trust write-up (updated 15 November 2026).