claude auto-mode critique returns "No critique was generated" for a large autoMode block; works with a small one

Status Open
Reported on v2.1.233
Maintainer reply None cached
Activity 4 comments · opened Aug 16, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

claude auto-mode critique always fails on my configuration, printing:

Analyzing your auto mode rules…

No critique was generated. Please try again.

Retrying does not help. The configuration itself is valid and working: auto mode runs normally, and claude auto-mode config prints the effective config correctly.

The CLI distinguishes three outcomes here, and it matters which one this is:

| Message | Meaning |
|---|---|
| Failed to analyze rules: <error> | the model query itself failed |
| No custom auto mode rules found. | there was nothing to review |
| No critique was generated. Please try again. | what I get |

I confirmed the first is reachable and genuinely distinct: pointing CLAUDE_CONFIG_DIR at a directory with no credentials produces Failed to analyze rules: Could not resolve authentication method….

So in my case the model call is completing and returning empty text, rather than erroring or finding nothing to critique.

The failure is size-dependent. With my real autoMode block (15 custom environment entries plus one custom soft_deny rule) it fails every time. Replacing autoMode with a single small rule, leaving the rest of settings.json untouched, makes it succeed immediately and return a long, detailed critique. Swapping back makes it fail again.

What Should Happen?

claude auto-mode critique should either return a critique, or report an error that says what actually went wrong.

If the underlying cause is a truncated or empty model response, that case is worth distinguishing from a generic "please try again". The message as written implies a transient failure, whereas in my case it is deterministic and will never succeed at my configuration size.

For comparison, the /auto-mode-setup path already inspects stop_reason and reports truncation explicitly. The critique path appears to fall through to this generic message whenever the extracted text is empty.

Error Messages/Logs

$ claude auto-mode critique
Analyzing your auto mode rules…

No critique was generated. Please try again.


For contrast, the genuine query-failure path (isolated config dir with no credentials), showing these are different code paths:

$ CLAUDE_CONFIG_DIR=/tmp/cfgtest claude auto-mode critique
Analyzing your auto mode rules…

Failed to analyze rules: Could not resolve authentication method. Expected one of apiKey, authToken, credentials, config, or profile to be set. Or for one of the "X-Api-Key" or "Authorization" headers to be explicitly omitted


No debug output is available for this command - see Additional Information.

Steps to Reproduce

  1. Populate autoMode in ~/.claude/settings.json with a substantial block. Mine is 15 custom environment entries plus one custom soft_deny rule, roughly 13,000 characters of custom rule text. The effective config printed by claude auto-mode config (defaults plus custom) is roughly 75,000 characters.
  2. Run claude auto-mode critique.
  3. Observe No critique was generated. Please try again. Retry - same result.
  4. Now replace the whole autoMode block with a single small rule, leaving everything else in settings.json unchanged:
{
  "autoMode": {
    "soft_deny": [
      "$defaults",
      "Never delete the build output directory without being asked."
    ]
  }
}
  1. Run claude auto-mode critique again. It succeeds and returns a long, detailed critique.
  2. Restore the original block. It fails again immediately.

Variables ruled out:

  • Not nesting - fails both from a shell inside a running Claude Code session and from a standalone terminal.
  • Not the model - fails with the default and with --model claude-sonnet-5.
  • Not the custom rules - it also failed when environment was the only populated section and there were no custom allow/soft_deny/hard_deny rules at all.
  • Not transient - about six attempts over several hours.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

The critique prompt embeds the entire classifier system prompt together with the user's custom rules. The practical effect is that the more environment context you add - which the documentation actively encourages, saying "the more specific context you give, the better the classifier can distinguish routine internal operations from exfiltration attempts" - the more likely critique is to fail.

The feature therefore stops working at exactly the configuration size where having your rules reviewed is most valuable, and it fails in a way that reads as transient rather than permanent.

Configuration contents are omitted deliberately, as they describe private infrastructure. I can supply sizes, structure, or a synthetic block of equivalent size on request.

View original on GitHub ↗

4 Comments

santinelst-boop · 8 days ago

Same failure on macOS (Darwin 24.6.0), Claude Code 2.1.233 — with two data points that refine the size hypothesis:

It's intermittent, not deterministic. With a large custom block (11 environment + 8 soft_deny + 3 allow + 2 hard_deny entries, all with "$defaults"): 2 successes out of ~30 runs across a session. With a minimal probe config (a single one-line soft_deny rule, passed via --settings): 4 failures out of 5 runs, then one success — so a small config also fails, and a large one occasionally succeeds. --model sonnet and --model opus fail identically.

The successful runs support your truncation reading. Both critiques that did come back were cut off mid-sentence — the second ended literally at "That exception says p" — so the generated text appears to be truncated at a varying point; when it truncates to zero, the CLI falls through to "No critique was generated. Please try again."

santinelst-boop · 8 days ago

Update: still reproduces after upgrading to 2.1.239 — 5/5 runs returned "No critique was generated. Please try again." on the same config as above.

stephenkiers · 6 days ago

Confirming this on macOS / Claude Code 2.1.241 (Anthropic API), so it's not Windows-specific.

ANTHROPIC_LOG=debug claude auto-mode critique shows the model call completing successfully (status: 200) but returning "stop_reason": "max_tokens" with "output_tokens": 4096 — the response is being truncated at the token cap before the critique text is complete, so the parser gets nothing usable and falls through to the generic "No critique was generated" message.

My autoMode block: 1 custom soft_deny rule plus several sharp-stop entries, effective config (claude auto-mode config output) around 75KB — in the same range as the original report. Same failure with --model claude-sonnet-5 explicitly set.

This matches the hypothesis in the original report exactly: the critique prompt embeds the full effective config (defaults + custom rules) as context, and the fixed max_tokens on the output isn't scaled to the size of that input, so past a certain config size the model can't finish its answer within the cap. Raising max_tokens for this call (or streaming + reporting partial output with a clear "truncated" note, the way /auto-mode-setup already does for stop_reason) would fix it.

matthoneycutt-sm · 4 days ago

I'm seeing the same failure on Windows, Claude Code 2.1.246. --model haiku is a workaround, and I don't think config size is the trigger.

--model haiku completes. Four out of four runs complete critiques ending on a finished sentence. Eleven runs on other models in the same session (session default Opus 5, plus explicit --model opus and --model sonnet) produced zero complete critiques: seven truncated mid-sentence, four returned "No critique was generated".

Config size is not the trigger. A settings file holding exactly one custom allow rule returned "No critique was generated" after 59 seconds. Every failing run took 49 to 62 seconds no matter what it printed, which is what you would expect if every run generates the full 4096 tokens and only the leftover after thinking arrives as text. That also explains why one config both truncates and returns nothing on different runs: thinking length varies per run.

The cap is hardcoded. In 2.1.246 the critique handler passes max_tokens: 4096 as a literal, so CLAUDE_CODE_MAX_OUTPUT_TOKENS does nothing on this path. Two more that look like they should reduce thinking and don't: MAX_THINKING_TOKENS=0 in the environment, and "alwaysThinkingEnabled": false in the file passed to --settings.

If that reading is right, raising max_tokens helps but isn't a complete fix, since thinking scales with the input. Turning thinking off for this one call, or surfacing stop_reason: max_tokens the way /auto-mode-setup already does, would hold up better. Maybe.