Claude Code 2.1.302 Flips Two claude -p Defaults: Permission Mode and Fork Subagents

Your nightly job calls claude -p with no --permission-mode. It ran fine on Thursday. After an upgrade, the same command can come back with its edits denied while the run itself carries on.

On October 16, Anthropic tagged Claude Code 2.1.302. Most of its 60-odd lines are fixes. Two of them change what a headless run does when your script doesn't say what it wants: the permission mode a claude -p or Agent SDK session starts in, and whether Claude can fork the conversation into subagents. If you run Claude Code in CI, on Amazon Bedrock or with telemetry off, read this before you bump the version.

Here they are, verbatim from the release notes:

Changed claude -p and Agent SDK sessions with no permission mode to start in default mode on third-party providers, with telemetry off or on a fresh install; --permission-mode auto keeps auto

Changed fork subagents ( subagent_type: "fork" ) to be on by default in claude -p, the Agent SDK, the desktop app and VS Code, as they already are in the terminal; CLAUDE_CODE_FORK_SUBAGENT=0 turns them off, and claude mcp serve never offers them

The changelog tracker gradually.ai lists the same release on October 16 with the same two changes. Neither is flagged as breaking. But an unpinned script inherits whatever the default is, so both change what your job does.

The permission modes page, as of October 18, still says a -p or Agent SDK session that doesn't fetch feature flags, "such as on a third-party provider or with telemetry off," starts in auto on v2.1.285 or later. In auto mode a classifier model reviews actions instead of you. Release 2.1.302 moves those sessions back to default, which the CLI calls Manual mode.

The third trigger in the note is a fresh install, and that one can reach CI on the Anthropic API too. The same permission-modes section notes that the first session after an install or upgrade can pick its starting mode before its feature flags arrive. A runner that installs Claude Code at the start of every job, with no saved config, can look like a fresh install every time.

Manual mode lets reads run without asking and prompts for most edits and shell commands. A -p run has nobody to answer that prompt. The headless docs are plain about it: "In a -p run with no host, these requests are denied either way."

So a job that leaned on the built-in default to edit files can come back with denials where it used to have a diff, whether it runs on a cloud provider (Bedrock, Google Cloud's Agent Platform, Microsoft Foundry), with telemetry off, or on a fresh runner. A job that lists every tool it needs with --allowedTools, or sets permissions.defaultMode in ~/.claude/settings.json or managed settings, keeps doing what it did. I haven't run 2.1.302 against Bedrock myself. This reading comes from the release note and the docs.

The fix is to stop relying on the default. Pick the mode in the command. For hands-off work with a classifier reviewing actions:

claude -p "Run the test suite and fix failures" \ --permission-mode auto \ --permission-prompts none Enter fullscreen mode Exit fullscreen mode --permission-prompts none needs v2.1.259 or later, and it tells Claude not to retry a request nobody can approve. On Bedrock and the other cloud providers, auto mode only works with Sonnet 5 or later, Opus 4.7 or later, Haiku 5.5 and the Fable models. On any other model, the session starts in Manual anyway.

For locked-down CI, dontAsk denies anything that would prompt. Reads and read-only commands still run, plus whatever your --allowedTools entries allow:

claude -p "Apply the lint fixes" \ --permission-mode dontAsk \ --allowedTools "Read,Edit,Bash(npm run lint *)" Enter fullscreen mode Exit fullscreen mode To catch silent denials, read them from the stream. With stream-json, the final result message lists them in permission_denials. This pipes it through jq:

claude -p "Apply the lint fixes" \ --permission-mode dontAsk \ --output-format stream-json --verbose \ | jq -c 'select(.type == "result") |.permission_denials' Enter fullscreen mode Exit fullscreen mode Fork subagents are on in claude -p and the SDK A fork, in the subagents docs, "is a subagent that inherits the entire conversation so far instead of starting fresh." It has the same system prompt, tools and model as the main session, and only its final result comes back. Because the prefix is identical, its first request reuses the parent's prompt cache, so the docs say a fork "costs less than a fresh subagent for tasks that need the same context."

Until 2.1.302, that was an interactive-terminal default. As of October 18, the subagents page still says fork mode is off by default in -p and the Agent SDK. The release note is the newer word.

Fork mode changes more than forks. When it is on, the docs say Claude Code runs the subagents Claude spawns in the background, "forks and non-fork subagents alike," and removes the Agent tool's run_in_background parameter. Background subagents get a smaller built-in tool set than foreground ones, forks excepted. And a -p run stays open until background subagents finish, because their result is part of the final output. The same release also makes a subagent's own Agent calls run in the foreground by default in -p, the SDK, the desktop app and VS Code.

If a pipeline depends on custom subagents behaving as they did, turn fork mode off for that job:

export CLAUDE_CODE_FORK_SUBAGENT = 0 claude -p "Summarize the open TODOs" \ --permission-mode dontAsk Enter fullscreen mode Exit fullscreen mode To keep fork mode but stop Claude from spawning forks, the docs suggest denying the fork type with an Agent(fork) rule:

{ "permissions": { "deny": [ "Agent(fork)" ] } } Enter fullscreen mode Exit fullscreen mode The smaller lines worth knowing The rest of the 2.1.302 notes are mostly fixes, but a few touch behaviour:

I build Hermes IDE, so weigh this section with that in mind. Hermes runs Claude Code in a real terminal by default, as an interactive session, so the two -p defaults above don't apply there. The optional Agent view for Claude runs the Claude Agent SDK instead, so for those sessions the SDK defaults are the ones to check. In the ⌘N New task sheet (Ctrl+Shift+N on Windows and Linux), shown below, the permission mode sits in a chip next to the agent and project, and a "Hermes will run" line shows the claude command before it starts.

The ⌘N New task sheet in Hermes 2.3.4: chips for Claude Code, the project, a new worktree, Accept edits, model and effort, and the "Hermes will run" preview of the claude command.

Hermes never answers a permission prompt for you. When an agent is blocked on one, the attention inbox counts it and ⌘I jumps to the agent that has waited longest. It's free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. Download it here. Hermes is not affiliated with Anthropic.

Before 2.1.302 reaches your runners, find the headless calls that never name a mode:

grep -rn "claude -p".github/ scripts/ \ | grep -v -- "--permission-mode" Enter fullscreen mode Exit fullscreen mode That only catches one-line invocations. A command split across lines with \ needs a look by eye. Then add --permission-mode to each one, decide whether you want forks in that job, and set CLAUDE_CODE_FORK_SUBAGENT to match.

Have you pinned the permission mode in your CI jobs, or were you riding the default? Tell me in the comments.

If you run coding agents unattended, I build Hermes IDE for the interactive side of the same work: one terminal per agent, one worktree per task.

Permission modes and forked subagents are two answers to the same old questions: how much autonomy an agent gets, and how one agent hands work to another. The AI Agents Pocket Guide covers those patterns, from tool-calling loops to multi-agent orchestration and guardrails, without tying them to one vendor's flags.