Where Claude Code Auto Mode Gets Its Verdict - Server Review, the Local Classifier, and the Denial When No Verdict Arrives

First Published: 2026-11-10
Last Updated: 2026-11-10

In Claude Code's auto mode, a classifier reviews tool calls before they are invoked. This article refers to the outcome of this review as a "verdict." The responsibility for issuing this verdict can fall to either the server or Claude Code's own classifier requests, based on the specific session. When the server is responsible for the review, the server's verdict determines whether the tool call is executed. If the server does not perform the review, the documentation states that Claude Code falls back to its own classifier requests. If the server is performing the review but a verdict is not received for a particular call, Claude Code will deny that call. These two scenarios represent separate branches, not three sequential steps.

The CHANGELOG for Claude Code v2.1.319, released on November 6, 2026 (UTC), states that this fallback to Claude Code's classifier requests has been eliminated for sessions with telemetry or feature flags disabled, including those behind the LLM gateway. However, as of November 10, 2026, the permission modes page still mentions this fallback. This article presents both statements without asserting which is correct.

This article aims to organize the information from the documentation, clarifying where the auto mode's verdict originates, where it might fail, what happens when it does, and where operators can verify the process. This article does not describe ways to avoid a verdict. It distinguishes between what the documentation states, what is absent from the documentation, and where the sources disagree. This analysis is based on the documentation alone and has not been tested in a live environment. Pricing information is not included.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. Where a Verdict Comes From
4. Which Sessions Ask the Server
5. When the Session Falls Back to Its Own Classifier
6. When No Verdict Arrives
7. When the Input Changes After Review
8. What Changed in v2.1.319 and Where the Sources Disagree
9. Where to Check Each Case
10. Where the Sources Disagree and What They Do Not Say
11. Failure Modes
12. Frequently Asked Questions About Claude Code Auto Mode Verdicts
13. Summary
14. References

1. Scope and Assumptions

This chapter will first define the intended audience, the scope of this article, the relevant source materials, and the terminology used. The following eleven points will outline the conclusions.

The verdict for auto mode is based on two sources: the server's review and requests from Claude Code's own classifier. In sessions reviewed by the server, the server's verdict dictates the outcome (Chapter 3).
When the server does not review a session, and when the server reviews but its verdict for a call fails to arrive, different branches are followed. The permission modes page states that in the former case, Claude Code falls back to its own classifier, while in the latter, the call is denied (Section 3.3).
Four kinds of sessions ask the server: direct connections, cloud providers and LLM gateways, Claude apps gateway, and cloud sessions that Anthropic runs. The minimum version requirements for direct connections vary depending on the session type, specifically v2.1.271, v2.1.278, and v2.1.281. Even when the minimum version is met, a direct connection waits for Anthropic's rollout (Chapter 4).
When the session falls back to the classifier, the usage is tracked against accounts where those requests are billed, and Claude Code issues a notice. This notice is not displayed for Pro, Max, Ultra, or Team plans (Chapter 5).
Setting CLAUDE_CODE_AUTO_MODE_SERVER=0 disables requests to the server. This does not remove review; instead, Claude Code's own classifier does the review. The documentation describes this variable as a temporary setting (Sections 4.4 and 5.6).
If no server verdict arrives for 10 responses in a row, auto mode stops the turn. In a -p run, the run ends. The CHANGELOG for v2.1.319 states that -p runs whose calls are denied because no safety check was available now end with exit code 1 for text and JSON output (Chapter 6).
The threshold for repeated blocking by the classifier (three consecutive blocks, or a total of 20) is separate from the case where the server's verdict does not arrive. Even when this threshold is reached during a -p run, the run does not stop (Section 6.5).
If a hook or mod alters the input of a call after the server's review, Claude Code may deny the call. The denial message names this change only with direct connections to the Anthropic API, in interactive terminal and VS Code sessions (Chapter 7).
The CHANGELOG for v2.1.319 states that in sessions with telemetry or feature flags disabled, including those behind an LLM gateway, calls the server can't check are asked about or denied without falling back to the built-in classifier. The permission modes page still mentions the fallback as of November 10, 2026 (Sources disagree). The documentation does not specify the criteria for whether a call is asked about or denied (Chapter 8).
The permissions.denyInsteadOfPrompting setting was added in v2.1.319 and is documented in the settings reference as of November 10, 2026 (Section 8.4).
The status can be verified in several ways: the Auto mode server row in /status, the denial text, the classifier_verdict in OpenTelemetry's tool_decision event, and through debug logs. Prior to v2.1.319, the /status display was inaccurate for sessions behind a gateway (Chapter 9).

1.1 Intended Audience

This article is intended for the following readers:

Operations personnel who are using Claude Code behind an LLM gateway or proxy and want to verify the behavior of auto mode.
Engineers responsible for running claude -p --permission-mode auto in CI environments and investigating why runs might stop or exit with a non-zero status code.
Developers using PreToolUse hooks or mods to modify the input for tool calls.
Operations personnel collecting Claude Code's tool decisions using OpenTelemetry.

This article assumes that readers are considering the following points, and checks each one against the text of the sources:

A verdict is decided by trying three stages in order: the server, the local classifier, and denial.
If no verdict is available, the call is always denied.
If the Auto mode server status in /status is Enabled, the server is reviewing.
Setting CLAUDE_CODE_AUTO_MODE_SERVER=0 removes review.
If a -p run exits with a non-zero status code, it is because the classifier blocked calls many times.

1.2 What This Article Covers and What It Does Not

This article covers the following topics: verdict branching, the sessions that ask the server (including the minimum version), fallback to the own classifier and its notice, handling cases where a verdict is not received (including denial, stopping, and the -p exit code), classifier-side failures, modifying input after review, the v2.1.319 changes and where the sources disagree, and verification methods.

This article does not cover the following:

Organization of versions with auto mode as the default starting mode. This is covered on this site's Claude Code Version History and Timeline, which uses npm-based date tracking.
Values for defaultMode and a list of locations for configuration settings. This is covered on this site's Claude Code Features and Settings Reference 2026.
The order of a mod's tool.check, hooks, the permission prompt, and the classifier. This is covered on this site's Claude Code Mods Next to Settings Hooks.
The mechanics of hooks and general usage of updatedInput. This is covered on this site's Claude Code Hooks Complete Guide.
General information regarding the exit codes when running -p. This is covered on this site's Claude Code in CI/CD and Headless Automation.
Gateway operations. This is covered on this site's Running Claude Apps Gateway on AWS.
Methods for avoiding verdicts. This includes how to make the gateway drop review requests or results, how to modify input after review, how to write calls to prevent denial messages, and procedures for changing behavior by disabling telemetry and feature flags. The hooks page also describes cases where the denial in Chapter 7 does not appear, but this article does not copy that list.
Criteria for what the classifier blocks, pricing and per-unit costs, and comparisons of different models.

1.3 Date of Review and Materials Reviewed

This article was written after reviewing the following materials on November 10, 2026 (Japan Standard Time). The documents were located on code.claude.com under Claude Code, and all pages carried a Last-Modified date of November 9, 2026 (UTC). The body text uses the short English names in parentheses.

Configure permission modes page (permission modes page)
Error reference page (errors page)
Auto mode classifier request charges page (billing notice page)
Hooks reference page (hooks page)
Environment variables page (env vars page)
All settings page (settings reference)
Monitoring page (monitoring page)
LLM gateway protocol page (gateway protocol page)
CHANGELOG for anthropics/claude-code on GitHub (CHANGELOG)
Package information for @anthropic-ai/claude-code on npm (npm registry)

As of November 10, 2026, the latest version on npm was 2.1.322, and the stable version was 2.1.311. The CHANGELOG also lists 2.1.322 at the top.

1.4 Terms, and Different Things with the Same Spelling

This article will consistently use the following terms:

verdict: The result a review gives, either allow or block. It is the verdict of the documentation.
server review: The review process that Claude Code requests from the server as part of the session's model requests. The heading on the permission modes page is "Server-side classifier review."
own classifier: Classifier requests sent directly by Claude Code itself. This article uses this single term to encompass "own classifier requests" in the documentation and "local classifier," "client-side auto mode classifier," and "built-in classifier" in the CHANGELOG.
fall back: In this article, this term refers only to moving to the own classifier when the server does not review the session.
block: The result of the classifier's review, indicating that the call should be stopped.
deny: The instance where Claude Code does not execute the call. There are two types of denials: those resulting from a "block" verdict and those occurring when no verdict is available.

The term "fall back" also has a different meaning. On the permission modes page, the section "When auto mode falls back" refers to the situation where the auto mode stops and returns to the permission prompt after the classifier repeatedly blocks calls. This article will refer to this as "returning to the prompt" and will not use the term "fall back" in this context.

Similarly, the term "no verdict" also has a different meaning. The documentation uses "no verdict from the server" to indicate that a verdict has not been received from the server. It uses "no verdict from the classifier" to indicate that the classifier's response is unreadable. The OpenTelemetry value "no_verdict" also refers to this latter meaning (see Section 9.3). This article will use "no verdict arrives" to describe the former and "classifier-side failure" to describe the latter.

The names of cloud providers may vary in different sources. The documentation uses "Google Cloud's Agent Platform," while the CHANGELOG uses "Vertex." This article will retain the original spellings used in both the documentation and the CHANGELOG.

2. How to Read the Tables

This chapter defines the terminology used in the tables within this article, specifically regarding the state of the sources, as well as the format for recording version and date.

2.1 Terms for the State of the Sources

This article uses six terms to describe the state of the documentation. These terms, including their English spellings, will also be used in the tables.

Stated: The documentation contains a statement regarding the matter.
Stated as not supported: The documentation explicitly states that the matter is not supported or cannot be used.
Documentation does not list: While a list or table exists, the specific item is not included. This does not necessarily indicate that the matter is unsupported or unavailable.
No statement found: Despite searching using different search terms and examining different categories of documentation (as described in Section 1.3), no relevant statement could be found. This does not necessarily indicate that the matter is absent or does not occur.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This includes cases where the statements directly contradict each other, as well as cases where the scope, strength, or subject matter differs, and the text alone does not settle which one applies. This article presents both statements and their sources without designating either as incorrect.
Inference: This represents an inference made by this article, and is not a statement found in any of the documentation. This article says in the same sentence that it is an inference.

This article distinguishes between "Stated as not supported" and "No statement found." The former refers to a statement in the documentation, while the latter indicates that this article was unable to find a relevant statement.

2.2 How This Article Writes Versions and Dates

The version numbers, default values, and denial text in this article reflect the values in the documents read on November 10, 2026. The behavior of auto mode changed sequentially through versions v2.1.316, v2.1.317, and v2.1.319 during the period from October to November 2026. Readers should verify these values against the documentation for their specific version.

The CHANGELOG does not include dates for each version. The dates referenced in this article correspond to the time values found in the npm registry and represent UTC dates.

3. Where a Verdict Comes From

This chapter shows which calls are sent for review, where the verdict comes from, and where it can no longer be obtained.

3.1 Calls Sent for Review

In auto mode, not all calls are routed for review. The permission modes page describes how calls proceed through a series of steps, and the first matching step determines the outcome. In summary:

Calls that match the rules for "allow," "ask," or "deny" are resolved according to those rules, although there are exceptions, such as writing to protected paths.
Read operations and file editing in the working directory are automatically approved.
Otherwise, calls are routed to the classifier.

Server-reviewed sessions have additional conditions. The permission modes page states:

In a session with server-side classifier review, read-only and sandboxed shell commands wait for that review and are blocked if it flags them

Specifically, in server-reviewed sessions, both read-only shell commands and shell commands executed in the sandbox also await review. This change is documented in the CHANGELOG, version v2.1.281.

Regarding auto mode itself, the permission modes page includes the following warning:

Auto mode reduces permission prompts but does not guarantee safety.

Auto mode is not a substitute for containment. The layers of containment are covered in this site's Hardening and Governance Guide for Claude Code and Claude Desktop.

3.2 Server Review

The Server-side classifier review section of the permission modes page describes the server review process as follows:

In auto mode, Claude Code can ask the server to check the actions that the decision order sends for review, as part of the session's model requests, in place of sending its own classifier requests.

The server review runs as part of the session's model requests. For calls that the server reviews, Claude Code does not send a separate request for the review itself. The gateway protocol page states that this review adds an anthropic-beta value and a safeguards field to the request. The billing notice page indicates that the results of the review are returned in the safeguard_results field of the response.

When the server reviews, the server gives the verdict. The same section further states:

Where the server reviews the actions, its verdicts decide them. Two other outcomes are possible:

3.3 Two Separate Branches

The same section lists two other possible outcomes. The first is when the server does not review the session.

The server doesn't review the session: a response completes with no review results, or the server answers that it doesn't review this session. The most common causes are an LLM gateway or proxy that drops the request for review or the results, and a platform, region, or credential that doesn't have server-side checks yet. Claude Code falls back to its own classifier requests.

The second is when the server reviews, but no verdict arrives for a call.

The server gives no verdict for an action: Claude Code denies the action rather than run it unreviewed. On any connection, this happens when the response ends before the review results arrive or the results arrive in a form Claude Code can't read. An LLM gateway or proxy that cuts responses short or rewrites the results can cause either. On a direct connection to the Anthropic API, it also happens when the server's check fails for the action, for example by timing out.

These two branches differ in scope. The first relates to the session as a whole, where the server does not perform a review. The permission modes page states that once this fallback holds for the rest of the session, a notice is shown on accounts where those requests are billed. The second relates to individual calls, where a verdict is missing for a call that should be reviewed. In this situation, Claude Code denies the call, rather than executing it without review. The permission modes page does not state that Claude Code will fall back to its own classifier in this case.

The gateway can be the cause of either branch. A gateway that drops review requests or results is a cause of the first branch, while a gateway that interrupts responses or alters results is a cause of the second. The billing notice page states that the gateway should pass requests and responses without modification.

The fallback branch disagrees with the v2.1.319 CHANGELOG. This discrepancy will be addressed in Chapter 8.

3.4 Classifier-Side Failures

Even when the own classifier is reviewing, it may sometimes fail to provide a verdict. The section of the errors page titled "Auto mode cannot determine the safety of an action" lists the messages generated when the classifier's model is unable to give a verdict. The message generated when the model is unavailable is as follows:

<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool> right now. Wait a moment and then try this action again.

The message when the classifier's response can't be read is:

Auto mode could not evaluate this action and is blocking it for safety — run with --debug for details

In both cases, Claude Code does not approve the call automatically. The errors page states that operations in the working directory, such as reading, searching, and editing, do not go through the classifier, and therefore, these operations will continue to function.

3.5 Input Changes After Review

There are instances where the verdict no longer covers a call. This occurs when a hook or mod alters the input of a call after the server has completed its review. The permission modes page notes that in such cases, Claude Code may deny the call as one with no verdict. Chapter 7 discusses this in more detail.

4. Which Sessions Ask the Server

This chapter shows which sessions ask the server for review, and their minimum versions.

4.1 Four Kinds of Sessions

The permission modes page lists four kinds of sessions that ask the server.

Session	Conditions in the documentation	Status
Direct Connection to Anthropic API	Interactive terminal, `-p`, Agent SDK, VS Code extension, and desktop app sessions. Regardless of plan or account type, they ask as Anthropic rolls it out	Stated
Cloud Provider and LLM Gateway	Sessions using Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, as well as sessions that direct `ANTHROPIC_BASE_URL` to an LLM gateway or proxy. They ask regardless of plan	Stated
Signed-in Claude apps gateway sessions	Only the minimum version is stated	Stated
Cloud sessions in an Anthropic-hosted environment	Sessions started from the web, the mobile app, or the desktop app with Cloud selected. They ask regardless of plan. Sessions started by a cloud scheduled task ask as Anthropic rolls it out	Stated

The conditions in the direct connection row need care. The permission modes page states the following regarding direct connections:

whatever your plan or account type, as Anthropic rolls it out

In other words, even if a direct connection session meets the minimum requirements outlined in the next section, that session may not ask the server. To verify whether your session asks the server, check /status (Section 9.1).

4.2 Minimum Versions and Release Dates

The permission modes page lists the minimum version requirements for each session type. The dates refer to the UTC dates from the npm registry.

Session	Minimum Version	Release Date (UTC)
Direct connection interactive terminal (Pro, Max, Ultra, Team plans)	`2.1.271`	2026-09-14
Direct connection interactive terminal (Enterprise plan and Claude API account)	`2.1.278`	2026-09-19
Direct connection sessions using `-p` and VS Code extension	`2.1.278`	2026-09-19
Direct connection sessions using the Agent SDK and desktop app	`2.1.281`	2026-09-23
Direct connection sessions that do not retrieve feature flags (asks by default in any kind of session)	`2.1.282`	2026-09-24
Cloud provider and LLM gateway (asks by default)	`2.1.278`	2026-09-19
Signed-in Claude apps gateway sessions	`2.1.280`	2026-09-22
Cloud sessions in an Anthropic-hosted environment	Documentation does not list	—

Regarding direct connection sessions that do not retrieve feature flags, the permission modes page gives turning telemetry off as an example.

The 2.1.280 version for the Claude apps gateway reflects the value listed on the permission modes page. However, no corresponding entry was found in the CHANGELOG under the v2.1.280 section (No statement found). This article gives only the documentation's value.

4.3 Changes by Version in the CHANGELOG

The CHANGELOG says the defaults changed by version as follows:

v2.1.273 (2026-09-15): For Bedrock, Vertex, and Foundry, auto mode used the own classifier by default for now.
v2.1.278 (2026-09-19): For users of the Claude API and Enterprise, as well as for Bedrock, Vertex, Foundry, and gateways, the default has been changed to use the server-side classifier. A warning is now displayed on a billed fallback. The /status command now includes an Auto mode server row.
v2.1.281 (2026-09-23): The CLAUDE_CODE_AUTO_MODE_SERVER setting now also applies to direct connections.
v2.1.282 (2026-09-24): Even on a direct connection with telemetry disabled, the default classifier is now set to the server-side classifier.

The original text for the entry regarding v2.1.278 is as follows:

Changed auto mode for Claude API and Enterprise users, and on Bedrock, Vertex, Foundry and gateways, to default to the server-side classifier, which does not charge for classifier overhead (CLAUDE_CODE_AUTO_MODE_SERVER=0 opts out on Bedrock, Vertex, Foundry and gateways); warns on billed fallback.

4.4 Settings That Stop Asking the Server

The permission modes page describes the setting that stops Claude Code from asking the server as follows:

To skip asking the server and always use Claude Code's own classifier requests, set CLAUDE_CODE_AUTO_MODE_SERVER=0.

CLAUDE_CODE_AUTO_MODE_SERVER=0 does not disable the review process. Claude Code's own classifier will continue the review. This variable takes effect with direct connections in version v2.1.281 and later. On the env vars page, the same variable's entry lists v2.1.281 as the requirement for direct connections, and v2.1.271 as the minimum version of the variable itself. This article reads these two as two conditions in one row and does not treat them as a disagreement.

When set to 1 in a direct connection, this setting enables the review process in a session that does not have server review yet. However, this effect is nullified if CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 is also configured. If CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 is set and CLAUDE_CODE_AUTO_MODE_SERVER is not configured, Claude Code also stops asking the server. There are exceptions to this behavior, as described in the section "Disable pre-release capabilities" on the gateway protocol page. This applies when the application hosting Claude Code sets the CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST variable. The handling of 1 behind the gateway changed in version v2.1.319 (see Section 8.5).

The billing notice page describes this variable as follows:

CLAUDE_CODE_AUTO_MODE_SERVER is a temporary setting and may be removed in a later release.

Any operational procedures that rely on this variable will need to be revised if the variable is removed in a future version.

5. When the Session Falls Back to Its Own Classifier

This chapter describes what happens when the server does not review the session.

5.1 Causes of the Fallback

The permission modes page lists potential reasons why a server might not review a session: an LLM gateway or proxy that drops the review request or results, and platforms, regions, or credentials where server-side review has not yet arrived (see Section 3.3). The billing notice page describes what the gateway does more specifically:

one that strips or rewrites request headers, drops request fields it doesn't recognize, or edits responses.

The billing notice page outlines the conditions the gateway must meet to ensure the server's review is successful, both for requests and responses. For requests, the gateway must send the anthropic-beta header and the safeguards field as a pair, without modification. For responses, the gateway must avoid dropping any fields, preserve the tool call ID, and retain the safeguard_results field. The overall compatibility of the gateway is addressed in the Feature pass-through section of the gateway protocol page.

5.2 Counting Toward Usage, and the Notice

Server review is performed as part of the session's model requests and does not incur any charges. The billing notice page states the following regarding requests after a fallback:

This notice means the server's checks aren't reaching your session, so Claude Code is making its own classifier requests instead, and on your account those requests count toward your token usage:

When this happens, Claude Code shows the following notice:

We're changing auto mode to no longer charge for classifier requests in Claude Code. However, this session isn't eligible.

The billing notice page also states that this notice will not appear for Pro, Max, Ultra, and Team plans. The absence of this notice does not indicate that the server is currently reviewing (Inference). You can check the status of your session at /status (Section 9.1).

5.3 Answering the Notice

During an interactive session, the notice will hold the first call checked with the own classifier until a response is provided. The billing notice page describes the meaning of a response as follows:

Enter: The held call and any remaining portion of the session will continue using the own classifier. In that session, the notice will not reappear. If the notice specifically referenced a gateway, the notice will not appear on that machine for 24 hours.
Esc or Ctrl+C: The held call does not run, and that turn stops. The session remains in auto mode, and the notice appears again before the next checked call.

If Claude Code is unable to wait for a response to the notice, it will report the same message and continue in auto mode. When running with the -p flag, the message will appear in stderr. In stream-json output, it becomes a system warning message.

5.4 The Classifier Model After a Fallback

The permission modes page specifies the default model used for classifier requests as follows:

By default, classifier requests go to Claude Sonnet 5. If /status shows Auto mode server as Enabled, they're sent only for calls outside the server's review.

The same page lists the scenarios in which a different model may be used instead of the default. In sessions where Anthropic is configuring the classifier model, the model used is the configured model. In sessions running with Claude Sonnet 4.6, the model used is Sonnet 4.6. In sessions where ANTHROPIC_DEFAULT_SONNET_MODEL is set, the model used is the value specified. However, if that value is either Claude Sonnet 5.5 or Claude Opus 5.5, the model used will be Sonnet 5.

As of version v2.1.302 (2026-10-16), you can choose the model of the own classifier with CLAUDE_CODE_AUTO_MODE_MODEL. The entry for version v2.1.302 in the CHANGELOG indicates that this variable does not modify the model used for server-side review.

Added CLAUDE_CODE_AUTO_MODE_MODEL to choose the model the client-side auto mode classifier uses; it does not change the model for server-side auto mode

5.5 The `Auto mode server` Row in `/status`

The billing notice page describes how to verify the status of an auto mode session, as follows:

To check a session that's in auto mode, run /status at the Claude Code prompt: its Auto mode server row reads Enabled while the server's checks decide the session's actions and Disabled once the session has fallen back.

This row was added in the CHANGELOG for version v2.1.278. However, the CHANGELOG for version v2.1.319 states that a display issue was corrected.

Fixed /status showing "Auto mode server: Enabled" when the server-side review isn't reaching the session, for example behind an LLM gateway that drops it

Therefore, in versions prior to v2.1.319, it was possible for /status to display Enabled behind a gateway even though the server's review was not reaching the session. This article does not use the Enabled status in pre-v2.1.319 versions as confirmation that the server is reviewing.

5.6 Choosing `=0`

The billing notice page instructs users to set CLAUDE_CODE_AUTO_MODE_SERVER=0 before starting a session, in cases where you already know that the gateway will not pass the server's checks. When this setting is enabled, all classifier requests are consistently Claude Code's own, and no notice is shown. Even in this scenario, Claude Code's own classifier performs the review.

6. When No Verdict Arrives

This chapter describes what happens when a server is reviewing, but a verdict for a call does not arrive.

6.1 The Denial Message

The section of the errors page titled "The server returned no safety verdict" lists the denial message generated at that time. The classification within parentheses appears when Claude Code can determine one.

The server-side auto mode classifier gave no verdict (timed out), so auto mode cannot determine the safety of <tool>.

The remainder of the message informs Claude whether a single retry attempt will be helpful. The errors page also states that Claude Code waits before some of these denials. During an interactive session, while waiting, the spinner shows Auto mode check unavailable with a countdown, and pressing Esc interrupts the turn.

6.2 Stopping After 10 Responses

When responses without a verdict continue, auto mode stops the turn. The errors page lists the following:

Auto mode is unavailable — the server returned no safety verdict for the last 10 responses, so Claude stopped. Send a message to try again, or switch out of auto mode.

The count refers to 10 consecutive responses. The errors page also notes that certain denials, such as those resulting from the hook or mod changes in Chapter 7, are not included in this count. Sending another message starts the count over.

This stopping behavior was added in version v2.1.280 (2026-09-22). The errors page describes the previous behavior as follows:

Before v2.1.280, Claude Code denied each action from a response without a verdict immediately and never stopped the turn.

6.3 How Each Kind of Session Stops

The errors page documents where the stop message appears in each kind of session.

Interactive session: The message appears as a warning in the conversation log, and the turn ends.
-p run: The run ends, and an execution error is reported. With the default text output, messages are output to stderr.
Subagent: The subagent terminates before completing its task, and Claude receives the output generated up to that point, along with a note indicating that auto mode has stopped it.

6.4 `-p` Exit Codes

The CHANGELOG for v2.1.319 includes the following correction regarding the exit codes for -p:

Fixed claude -p exiting 0 in auto mode when its actions were refused because no safety check was available: text and JSON output now exit 1

In other words, in versions prior to v2.1.319, -p runs whose calls were denied because no safety check was available could sometimes end with an exit code of 0. This correction addresses output formats, specifically text and JSON. The exit code for stream-json output is not in this entry (No statement found). The headless page states, as a general rule, that a failed run ends with a non-zero code, but it does not give the value for this auto mode case.

This discussion applies only to -p runs in auto mode. The permission modes page states that, since v2.1.302, if -p and the Agent SDK are executed without a specified permission mode, they will start in Manual mode. In settings and SDK values, this mode appears as default. To run in auto mode, pass --permission-mode auto.

6.5 Separate from Repeated Classifier Blocks

The classifier blocking calls and a verdict not being received are separate events. The "When auto mode falls back" section on the permission modes page describes what happens when the classifier blocks repeatedly, as follows:

Repeated blocks: if the classifier blocks an action 3 times in a row or 20 times total, auto mode pauses and Claude Code resumes prompting.

This limit cannot be changed. The total count persists for the session and resets only when the total limit triggers. Regarding -p runs, the "Repeated-block thresholds" section on the same page states:

A non-interactive -p run without a --permission-prompt-tool has no prompt to fall back to. When repeated blocks reach a threshold, the action doesn't run and Claude keeps working. Claude Code doesn't stop the run.

In other words, even if the classifier blocks three times in a row during a -p run, the run will not stop. The run stops if a verdict is not received, as described in Section 6.2. When -p stops or ends with a value other than zero in a CI environment, it is necessary to determine whether the message indicates a block or that a verdict was not received.

6.6 Classifier-Side Failures

Regarding failures on the classifier side, as described in Section 3.4, the errors page lists the following classifications, appearing after the message temporarily unavailable: (rate-limited), (overloaded), (server error), (timed out), and (connection failed). If a classification cannot be determined, no parentheses are included. On Amazon Bedrock, this message also appears when the AWS account can't invoke the model the message names, and it repeats with each retry attempt.

In addition to the message related to unreadable classifier responses (as described in Section 3.4), a safety check separate from auto mode may sometimes refuse classifier requests based on the content of the conversation. The errors page lists the message associated with this refusal, clarifying that it does not indicate a dangerous call. This refusal does not count against the limits outlined in Section 6.5 and will not stop a -p run.

In an interactive session, from version v2.1.296 (2026-10-09) onwards, a dim row appears under the tool call in place of some of these failure messages.

Not run · auto mode's check had no usable answer

To view the messages, open the conversation log viewer by pressing Ctrl+O.

6.7 With `permissions.denyInsteadOfPrompting` Enabled

When permissions.denyInsteadOfPrompting is enabled, Claude Code denies calls that would otherwise wait for a permission prompt, and the turn continues (see Section 8.4). The settings reference describes the behavior when this setting is enabled in auto mode as follows:

In auto mode with the setting on, the turn ends after 20 calls in a row that the classifier blocked or a safety check refused, and you see this message:

The message is below. In this scenario, the system reports the -p run's turn as error_during_execution.

20 actions were refused and no work went ahead in between, so Claude stopped.

7. When the Input Changes After Review

This chapter describes what happens when, after the server has completed its review, a hook or mod alters the input to the call.

7.1 What Happens

The PreToolUse updatedInput in auto mode section of the hooks page says:

When your hook returns updatedInput with no permissionDecision in auto mode, Claude Code can deny the changed call. The server reviewed the input Claude wrote, not the input your hook returned.

The server reviewed the input that Claude generated. The input returned by the hook was not reviewed. The errors page explains the meaning of this denial as follows:

This denial means a hook or mod changed the call's input after the server reviewed it, so the review doesn't cover what would run. It isn't a judgment that the action is unsafe.

This denial does not indicate that the call itself is unsafe. Rather, it signifies that the review does not cover the input being executed.

7.2 Sessions That Show the Denial Text

The permission modes page and the hooks page limit the sessions where the denial text appears.

In interactive terminal and VS Code sessions on a direct connection to the Anthropic API, the denial's text includes a hook changed this call's input after auto mode reviewed it.

For sessions behind a gateway and -p runs, the sources do not say how this denial is shown (No statement found). This article does not state that the same message appears in other sessions.

7.3 Other Calls in the Same Response

The errors page states that later calls in the same Claude response can also be denied with this reason:

another call in this response was changed by a hook after auto mode reviewed it, or could not be confirmed unchanged

After a denial, Claude can resubmit each call for review by the server. The hooks page explains that if Claude repeats the modified input exactly in the subsequent response, the hook will trigger again, but the updatedInput returned by the hook will be discarded. Only the input reviewed by the server will be processed.

7.4 Relationship with the Count of Ten

The errors page states that denials caused by hook or mod changes are not counted as part of the count of ten described in Section 6.2. Even if these denials persist, they do not lead to the stop for a verdict that is not received.

7.5 What the Documentation Says to Do

The errors page states that if the permission prompt appears, the user should respond to it. Otherwise, unless Claude indicates in its response that auto mode was unable to check the call, the user needs to take no action. In the event that Claude does indicate such an issue, the errors page lists the following two options:

Stop the change: Turn off the hook or mod that changed the call or an earlier call in the same Claude response, or ask your administrator to turn it off. Hooks can be found at /hooks, and terminal session mods can be found at /plugin.
Approve manually: Switch to Manual mode.

The order of a mod's tool.check and the classifier is addressed in this site's Claude Code Mods Next to Settings Hooks. The general usage of updatedInput is covered in Section 7.8 of Claude Code Hooks Complete Guide.

8. What Changed in v2.1.319 and Where the Sources Disagree

This chapter shows the auto mode entries in the v2.1.319 (2026-11-06) CHANGELOG and how they disagree with the documentation.

8.1 The CHANGELOG Entry

The v2.1.319 CHANGELOG says this about the fallback:

Changed auto mode with telemetry or feature flags off, including behind LLM gateways: calls the server can't check are asked about or denied, with no fallback to the built-in classifier; set CLAUDE_CODE_AUTO_MODE_SERVER=0 to keep using it (Bedrock, Vertex and Foundry are unchanged)

This entry covers sessions where telemetry or feature flags have been disabled, including those behind the LLM gateway. Within this scope, calls that the server cannot check are either asked about or denied, rather than routing them to the built-in classifier. To continue using the built-in classifier, set CLAUDE_CODE_AUTO_MODE_SERVER=0. Bedrock, Vertex, and Foundry remain unchanged.

8.2 The Permission Modes Page Sentence

The section on "Server-side classifier review" in the permission modes page, as read on November 10, 2026, states the following (as per Section 3.3) for when the server does not review sessions:

Claude Code falls back to its own classifier requests.

The Last-Modified date of the permission modes page obtained on November 10, 2026, was November 9, 2026 (UTC). This was three days after the release of version v2.1.319. When the page was fetched again later the same day, the text was unchanged, and only the Last-Modified date was newer. The Last-Modified date does not indicate when the text of the page was written.

8.3 The Scope of the Disagreement

The two sources disagree for the sessions in the scope of the v2.1.319 CHANGELOG entry. This range covers sessions where telemetry or feature flags are disabled, including sessions behind the LLM gateway, and excludes those using Bedrock, Vertex, and Foundry. Within this range, when the server does not review the session, the permission modes page indicates a fallback to its own classifier, while the CHANGELOG states that calls are either asked about or denied without a fallback (Sources disagree).

Outside of this range, the CHANGELOG does not document any changes. While this article suggests that the two sources do not differ outside this range, this is based on inference (Inference).

The CHANGELOG names only Bedrock, Vertex, and Foundry as unchanged. Regarding the Claude Platform on AWS (as listed as a cloud provider in Section 4.1) and sessions for signed-in Claude apps gateway, the sources do not state their behavior after v2.1.319 (No statement found).

This article does not determine which source is correct. Readers on v2.1.319 or later should verify the behavior of their own sessions using the methods described in Chapter 9.

8.4 Asking or Denying

The CHANGELOG entry writes calls the server can't check as asked about or denied. The criteria for determining whether a call is "asked about" or "denied" cannot be found in the materials of Section 1.3 (No statement found). This article searched the documentation pages using the terms asked about or denied, no fallback, and 2.1.319, but no text was found that explicitly stated this distinction.

The absence of a clear description does not imply that either option is acceptable. This article does not state that a call the server cannot check is always denied, nor that it is always asked about.

In the same version, v2.1.319, the CHANGELOG mentions the addition of the permissions.denyInsteadOfPrompting setting.

Added permissions.denyInsteadOfPrompting setting: a tool call that would wait on a permission prompt is denied and the turn continues, in terminal sessions, subagents and teammates

As of November 10, 2026, the settings reference includes a section dedicated to this setting, requiring version 2.1.319 or later. The settings reference states that this setting applies to -p runs, interactive terminal sessions, VS Code extensions, local sessions within desktop applications, subagents, and agent teams. The CHANGELOG entry lists terminal sessions, subagents, and teammates. This article sets these two side by side as different ways of writing the scope, not as a disagreement.

The documentation does not state whether the "asking" behavior in v2.1.319 is a permission prompt that this setting changes to a denial (No statement found). Assuming this is the case would be an inference (Inference). The settings reference indicates that this setting results in a denial when the notice in Section 5.2 would open an interactive dialog. In such instances, Claude Code does not show the notice and instead denies the calls that need those requests.

8.5 Behind the Gateway: `=1`

The CHANGELOG for v2.1.319 also mentions CLAUDE_CODE_AUTO_MODE_SERVER=1 in relation to the gateway, as follows:

Changed auto mode behind an LLM gateway: CLAUDE_CODE_AUTO_MODE_SERVER=1 turns on the server-side check even with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS set; if managed settings set the latter, they must set the 1 too

The text on the permission modes page in Section 4.4 states that, when using a direct connection, setting the value to 1 will not take effect if CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 is also set. This entry in the CHANGELOG refers to the configuration behind the gateway. This article will present the two sentences as separate statements with different scopes.

8.6 The v2.1.319 Fixes to How You Check

v2.1.319 includes two fixes that affect how you check. One corrects the display of the /status command as described in Section 5.5, and the other corrects the exit code for the -p option as described in Section 6.4. Both of these changes address instances in versions earlier than 2.1.319 where the information presented to operators did not accurately reflect the server's review status.

9. Where to Check Each Case

This chapter indicates where operators can verify the various scenarios described in Chapters 3 through 8.

Case	`/status` - `Auto mode server`	Message	`tool_decision` - `classifier_verdict`
Server reviews the session	`Enabled` (misreport fixed in v2.1.319)	None	The verdict
Fell back to the own classifier	`Disabled`	The notice in Section 5.2. Not displayed on Pro, Max, Ultra, or Team	The verdict
No verdict from the server	`Enabled`	`gave no verdict`. After 10 consecutive occurrences, `Auto mode is unavailable`.	`"unavailable"`
Classifier request failed	Either	`temporarily unavailable`	`"unavailable"`
Classifier response can't be used	Either	`could not evaluate this action`	`"no_verdict"`
Input changed after review	`Enabled`	The text in Section 7.2. Direct connection, interactive terminal and VS Code only	No statement found
Classifier blocked the call	Either	Notification and the "Recently blocked" tab in `/permissions`. Returns to the prompt after 3 consecutive or a total of 20 occurrences.	`"block"`

In the /status column of this table, only the first two rows come from the sources (the billing notice page, Section 5.5). The Enabled status for cases where a verdict is not received or the input changes is inferred based on the fact that these events occur during a session the server reviews. The "Either" designation is an inference based on the fact that during sessions the server reviews, requests for its own classifier are sent for calls outside of the review (as described in Section 5.4) (Inference).

9.1 `/status`

/status displays a row labeled Auto mode server, which indicates whether it is Enabled or Disabled (see Section 5.5). Disabled signifies that the session has fallen back to its own classifier. In versions prior to v2.1.319, the status Enabled could occasionally be displayed incorrectly behind the gateway.

9.2 Messages

The denial and stop messages are listed in Chapters 6 and 7. During an interactive session, you can view the message behind a dim row by opening the conversation log viewer with Ctrl+O (see Section 6.6). When running with the -p option, the stop message (with the default text output) and the fallback notice will appear on stderr.

9.3 OpenTelemetry's `tool_decision`

The monitoring page describes the classifier_verdict attribute of the tool_decision event as follows. This attribute is included starting with version v2.1.301 (2026-10-15).

classifier_verdict: The auto mode classifier verdict for the call, or why Claude Code denied the call when none came. Requires Claude Code v2.1.301 or later

There are two possible values for denials without a verdict. The monitoring page describes "no_verdict" as follows:

"no_verdict": the check ran but gave no usable verdict, so Claude Code denied the call. The denial doesn't mean the classifier found the call unsafe

It describes "unavailable" as follows:

"unavailable": the request to the classifier failed, for example on a rate limit, timeout, or connection error, so Claude Code denied the call. With server-side classifier review, it also marks a call denied because the server returned no safety verdict

In other words, denials where no verdict arrives from the server will be marked as "unavailable" rather than "no_verdict". The value "no_verdict" is used when the classifier's response can't be used.

The monitoring page also notes the following regarding "block":

A classifier check that fails partway through can also end as "block", so a partial classifier outage can appear as more blocks rather than as "unavailable"

An increase in "block" instances does not necessarily indicate that the classifier is identifying more instances as potentially risky. It can also increase due to partial classifier failures.

9.4 OpenTelemetry's `safety_event`

The monitoring page lists the safety_event event, requiring version v2.1.307 or later. The category values for this event include "auto_mode_block", indicating that the classifier blocked something, and "auto_mode_no_verdict", indicating that there was no usable classifier verdict.

On the other hand, the CHANGELOG mentions the addition of this event in version v2.1.307 (2026-10-21) and later states in version v2.1.312 (2026-10-27):

Changed Claude Code to stop sending the claude_code.safety_event OpenTelemetry event

No statement was found in subsequent CHANGELOG entries regarding the resumption of sending this event (No statement found). The monitoring page still lists this event as of November 10, 2026, and the two sources disagree (Sources disagree). This article lists the classifier_verdict of the tool_decision first to confirm the verdict, and uses the safety_event only after verifying whether it is being received on your version.

9.5 Debug Log

The permission modes page describes a method for verifying which model the classifier is using. This involves writing a debug log using the --debug-file flag and searching for the classifier_request_started line.

claude --permission-mode auto --debug-file classifier-debug.log

If this line is not present, the page instructs the user to check Auto mode server in /status. If it displays Enabled, it indicates that the server is configured to review calls for that session. This article assumes that the presence of this line signifies that Claude Code itself initiated a request to the classifier, although this is an inference (Inference).

10. Where the Sources Disagree and What They Do Not Say

This chapter collects the items in this article that carry a term for the state of the sources.

10.1 Where the Sources Disagree

Handling of sessions when the server does not review: The permission modes page states that sessions fall back to Claude Code's own classifier. However, the CHANGELOG for v2.1.319 states that, with telemetry or feature flags disabled, including behind the LLM gateway, calls are either asked about or denied without a fallback (Sources disagree, Section 8.3).
safety_event: The monitoring page lists this as an event from v2.1.307 onwards, while the CHANGELOG for v2.1.312 states that it was discontinued (Sources disagree, Section 9.4).

This article does not treat the following three as disagreements.

Minimum version of CLAUDE_CODE_AUTO_MODE_SERVER: This is the same line on the environment variables page, which specifies a direct connection requirement (v2.1.281) and the minimum version of the variable itself (v2.1.271) (Section 4.4).
Scope of permissions.denyInsteadOfPrompting: There is a difference in how the scope is described between the settings reference and the CHANGELOG (Section 8.4).
CLAUDE_CODE_AUTO_MODE_SERVER=1 and CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS: The description of direct connections on the permission modes page differs from the description regarding sessions behind the gateway in the CHANGELOG for v2.1.319 (Section 8.5).

10.2 What the Documentation Does Not List

The minimum version for cloud sessions in an Anthropic-hosted environment, as defined by the minimum version table in Section 4.2, is not listed in the documentation (Documentation does not list).

10.3 Items with No Statement Found

After v2.1.319, when a call the server can't check is asked about and when it is denied (Section 8.4).
Whether the asking in v2.1.319 is a permission prompt that permissions.denyInsteadOfPrompting turns into a denial (Section 8.4).
Following v2.1.319, the session behavior of Claude Platform on AWS and signed-in Claude apps gateway (Section 8.3).
The line pertaining to the minimum version of the Claude apps gateway in the v2.1.280 section of the CHANGELOG (Section 4.2).
The exit code when stream-json output with the -p flag results in a denial due to a lack of safety checks (Section 6.4).
The denial message displayed after a change in input following review, when using the gateway and the -p flag (Section 7.2).
The value of classifier_verdict when the input changes after review (the table in Chapter 9).
Following v2.1.312, the line regarding the resumption of safety_event transmission (Section 9.4).

The absence of a description does not necessarily indicate that the feature or behavior does not exist.

10.4 Important Notes When Reading

The versions, default values, and denial text in this article reflect the values as of the materials read on November 10, 2026. The behavior of auto mode also changed in November 2026, and the values may be subject to change.
The documentation calls CLAUDE_CODE_AUTO_MODE_SERVER a temporary setting. It may be removed in a later release.
This article has not been tested in a real-world environment. The behavior when no verdict arrives comes from the documentation's text.
Sentences marked with "Inference" are not based on the source materials.

11. Failure Modes

This chapter gathers common failures identified from the materials presented in Chapters 3 through 9.

Thinking that a verdict is determined by sequentially testing the server, the local classifier, and denial: When the server does not review a session, it is a fallback. When a call's verdict is not received, it is a denial, representing a separate branch. The permission modes page states that for calls where a verdict is not received, a denial occurs, rather than a fallback (Section 3.3).
Writing that a call is always denied if a verdict is not received: When the server does not review the session, the permission modes page describes a fallback to Claude Code's own classifier, and the CHANGELOG for v2.1.319 states asked about or denied for calls the server cannot check. The distinction is not found in the documentation (Sections 8.3 and 8.4).
Assuming that only one of the two documents, either the CHANGELOG for v2.1.319 or the permission modes page, is correct: The two sources conflict regarding telemetry or feature flag-disabled sessions, including sessions behind the LLM gateway. Verify this with your own sessions (Section 8.3).
Assuming that direct connections send requests to the server if the minimum version is met: For direct connections, the request is sent based on Anthropic's rollout (Section 4.1).
Reducing the minimum version to a single value by connection path: Within direct connections, the session type branches into v2.1.271, v2.1.278, and v2.1.281, with exceptions starting from v2.1.282 (Section 4.2).
Considering the Enabled status for /status in versions prior to v2.1.319 as evidence that the server is performing a review: Behind the gateway, the status could sometimes show Enabled even when the review was not reaching the session (Section 5.5).
Considering the absence of the notice as evidence that the server is performing a review: For Pro, Max, Ultra, and Team plans, no notice is shown even when a fallback occurs (Section 5.2).
Assuming that CLAUDE_CODE_AUTO_MODE_SERVER=0 removes review: Claude Code's own classifier performs the review (Section 4.4).
Documenting procedures that rely on CLAUDE_CODE_AUTO_MODE_SERVER as permanent settings: The documentation states that this is a temporary setting that may be removed in future versions (Section 4.4).
Interpreting the reason a -p run stops as the continuous blocking of the classifier: Unless permissions.denyInsteadOfPrompting is enabled, a -p run does not stop even when the classifier continuously blocks. It stops when a verdict fails to be received for 10 consecutive responses (Sections 6.5 and 6.7).
Considering the exit code 0 for -p in versions prior to v2.1.319 as evidence that no denial occurred: In some cases, runs whose calls were denied because no safety check was available would end with an exit code of 0 (Section 6.4).
Interpreting the denial triggered after an input change as a judgment that the call is potentially unsafe: The documentation states that this denial is not a judgment that the call itself is unsafe (Section 7.1).
Assuming that the denial message for an input change appears in all sessions: This message appears in direct connection interactive terminal and VS Code sessions (Section 7.2).
Counting denials where the server's verdict is not received as "no_verdict" in OpenTelemetry: These denials become "unavailable". "no_verdict" represents cases where the classifier's response can't be used (Section 9.3).
Interpreting increases in "block" as solely due to changes in the classifier's judgment: Even partial classifier failures can increase "block" (Section 9.3).
Structuring the aggregation on the assumption that safety_event is received: The CHANGELOG for v2.1.312 states that the transmission of this event was discontinued (Section 9.4).
Using auto mode as a substitute for containment: The documentation states that auto mode does not guarantee safety (Section 3.1).
Stating "not possible" or "either is fine" when a description is not found: The absence of a description does not necessarily mean that the matter does not exist (Section 10.3).

12. Frequently Asked Questions About Claude Code Auto Mode Verdicts

This section answers common questions related to the reader's expectations, as outlined in Section 1.1, using sentences from Chapters 3 through 9.

Q1. Does the auto mode verdict proceed by first checking the server, then the local classifier, and finally by denying?

It does not work by sequentially trying those options. In sessions where the server performs review, the server's verdict dictates the outcome. When the server does not review a session, the permission modes page describes a fallback to Claude Code's own classifier. If the server is reviewing but a verdict is not received for a call, Claude Code will deny that call, preventing it from executing without review. The permission modes page does not describe a fallback to Claude Code's own classifier in this scenario. These two cases represent separate branches (see Section 3.3).

Q2. If no verdict is available, is the call always denied?

Not necessarily. If the server reviews the session and the verdict for a call does not arrive, the call is denied (see Section 3.3). When the server does not review the session, the permission modes page describes a fallback to Claude Code's own classifier. The CHANGELOG for v2.1.319 states that, in sessions with telemetry or feature flags disabled, including sessions behind the LLM gateway, calls the server cannot check are asked about or denied (see Section 8.3). The distinction between whether a call is "asked about" or "denied" is not specified in the documentation (see Section 8.4).

Q3. If `Auto mode server` in `/status` shows `Enabled`, is the server reviewing?

In versions 2.1.319 and later, as described on the billing notice page, a status of Enabled signifies that the server's review is deciding session calls. In versions prior to 2.1.319, it was occasionally possible for the status to show as Enabled even when the server's review was not reaching the session (see Section 5.5).

Q4. Does setting `CLAUDE_CODE_AUTO_MODE_SERVER=0` disable the review process?

No, it does not. Instead of asking the server, Claude Code's own classifier will perform the review. This setting is effective with direct connections in version v2.1.281 and later. The documentation states that this variable is a temporary setting and may be removed in future versions (Section 4.4).

Q5. Did `claude -p` exit with a non-zero code in auto mode because the classifier repeatedly blocked calls?

In cases of continuous blocking by the classifier, a -p run does not stop. It ends when the server fails to deliver a verdict for 10 consecutive responses. The CHANGELOG for v2.1.319 states that runs whose calls are denied because no safety check was available now terminate with exit code 1, both for text and JSON output. In auto mode with permissions.denyInsteadOfPrompting enabled, a turn with 20 refusals in a row is reported as error_during_execution (see Sections 6.4, 6.5, and 6.7).

Q6. What changes when you use auto mode behind a gateway?

When the gateway drops a request for review or the result, the server will not review the session. The permission modes page states that in this situation, Claude Code falls back to its own classifier. The v2.1.319 CHANGELOG indicates that in sessions where telemetry or feature flags are disabled, including behind LLM gateways, calls the server can't check are asked about or denied without a fallback (Section 8.3). If the gateway terminates a response prematurely or modifies the result, the verdict will not be received, and the call will be denied (Section 3.3). The documentation specifies that the gateway should pass requests and responses without modification (Section 5.1).

Q7. After attempting to modify the input using a hook, the call was denied. Was this due to a judgment that the call posed a risk?

It was not a judgment of risk. The server reviewed the input written by Claude, not the input returned by the hook. Therefore, the server's review does not cover the input that would run. The errors page states that you should answer the permission prompt if it opens; otherwise, you do not need to act unless Claude says within its response that it was unable to check the call (Chapter 7).

Q8. In OpenTelemetry, which value shows denials where no verdict arrived?

Look for calls where the classifier_verdict in the tool_decision event is "unavailable". The monitoring page indicates that this value is also assigned to calls that are denied because the server gave no verdict. "no_verdict" is the value for a classifier response that can't be used. This attribute is included from version v2.1.301 onwards (see Section 9.3).

13. Summary

Before you use Claude Code auto mode behind a gateway or in -p runs, check the following:

Verify that your session type and pathway align with the four categories outlined in Section 4.1, and that the minimum requirements specified in Section 4.2 are met. If using a direct connection, be aware that even if the minimum requirements are met, a session still waits for Anthropic's rollout.
Document the fallback when the server does not review the session and the denial when a verdict is not received as separate branches in the operational guide.
Using version v2.1.319 or later, check the status of your session by reading the Auto mode server row in the /status output.
For sessions in the scope where the v2.1.319 CHANGELOG and the permission modes page disagree, verify the behavior on your own version.
Confirm with the gateway operators that the gateway passes the anthropic-beta header, the safeguards field, and the safeguard_results field of the response without modification.
If using CLAUDE_CODE_AUTO_MODE_SERVER=0, be aware that the own classifier keeps reviewing, and that the variable is temporary.
Make the procedures for troubleshooting failed -p runs differentiate between classifier blocking and the absence of a verdict. Be aware that even with exit code 0, denials were possible in versions prior to v2.1.319.
If you modify input using hooks or mods, be aware that auto mode can deny those calls, and that this denial is not a judgment that the call is unsafe.
Using OpenTelemetry, count "unavailable" and "no_verdict" for classifier_verdict separately, and verify that safety_event arrives on your own version.
Have procedures in place to re-check versions, default values, and denial text after the date of review.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi