claude auto-mode critique returns "No critique was generated" for a large autoMode block; works with a small one
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
- Populate
autoModein~/.claude/settings.jsonwith a substantial block. Mine is 15 customenvironmententries plus one customsoft_denyrule, roughly 13,000 characters of custom rule text. The effective config printed byclaude auto-mode config(defaults plus custom) is roughly 75,000 characters. - Run
claude auto-mode critique. - Observe
No critique was generated. Please try again.Retry - same result. - Now replace the whole
autoModeblock 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."
]
}
}
- Run
claude auto-mode critiqueagain. It succeeds and returns a long, detailed critique. - 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
environmentwas the only populated section and there were no customallow/soft_deny/hard_denyrules 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.
4 Comments
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+ 8soft_deny+ 3allow+ 2hard_denyentries, all with"$defaults"): 2 successes out of ~30 runs across a session. With a minimal probe config (a single one-linesoft_denyrule, 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 sonnetand--model opusfail 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."
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.
Confirming this on macOS / Claude Code 2.1.241 (Anthropic API), so it's not Windows-specific.
ANTHROPIC_LOG=debug claude auto-mode critiqueshows 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
autoModeblock: 1 customsoft_denyrule plus several sharp-stop entries, effective config (claude auto-mode configoutput) around 75KB — in the same range as the original report. Same failure with--model claude-sonnet-5explicitly 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_tokenson 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. Raisingmax_tokensfor this call (or streaming + reporting partial output with a clear "truncated" note, the way/auto-mode-setupalready does forstop_reason) would fix it.I'm seeing the same failure on Windows, Claude Code 2.1.246.
--model haikuis a workaround, and I don't think config size is the trigger.--model haikucompletes. 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 opusand--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: 4096as a literal, soCLAUDE_CODE_MAX_OUTPUT_TOKENSdoes nothing on this path. Two more that look like they should reduce thinking and don't:MAX_THINKING_TOKENS=0in the environment, and"alwaysThinkingEnabled": falsein the file passed to--settings.If that reading is right, raising
max_tokenshelps but isn't a complete fix, since thinking scales with the input. Turning thinking off for this one call, or surfacingstop_reason: max_tokensthe way/auto-mode-setupalready does, would hold up better. Maybe.