[BUG] /auto-mode-setup always fails: propose side query returns HTTP 429 rate_limit_error at 2% utilization

Status Open
Reported on v2.1.240
Maintainer reply None cached
Activity 0 comments · opened Aug 22, 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?

/auto-mode-setup always fails. It prints its banner, then a few seconds later:

Auto-mode setup scan failed: The model call didn't complete. This is usually temporary - re-run to try again.

It is not temporary. It has failed on every attempt since at least 2026-08-15, and no autoMode block has ever been written on this account.

Under --debug, the cause is visible: the propose side query is refused with HTTP 429 rate_limit_error, three times on the primary model and three times on the fallback, each in roughly 300ms.

This is not ordinary rate limiting. At the moment of failure, reported utilization was 2% of the 5-hour window (56% weekly), and the interactive session's own requests were succeeding in the same second the side query was refused. Only source=side_query requests were rejected.

I varied everything reachable from the client, and the result never changed:

| Variable | Values tried | Result |
| --- | --- | --- |
| Repository | 3 different repos | 429 in all |
| Classifier model | claude-opus-5[1m], its auto-selected fallback, claude-sonnet-5 | 429 in all |
| Recon scope | scope=all depth=both and scope=project depth=here | 429 in both |
| Entry point | interactive wizard and headless --propose | 429 in both |
| Date | 2026-08-15 and 2026-08-22 | 429 on both |

The claude-sonnet-5 run carries no 1M-context beta and still fails, so the beta is not implicated. No proxy and no ANTHROPIC_BASE_URL are set on the process.

What Should Happen?

/auto-mode-setup should return a drafted auto-mode proposal for review. Failing that, it should surface an actionable error. A permanent entitlement or quota refusal should not be reported to the user as a transient failure with an instruction to re-run, since no number of re-runs can clear it.

Error Messages/Logs

18:37:25.461 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:26.237 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:27.632 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:27.935 [ERROR] auto-mode-setup sideQuery failed: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Error"},"request_id":"req_011CeJGjtLpKA52vNtVJpBFk"}
18:37:27.936 [WARN]  auto-mode-setup propose: primary model failed; retrying on fallback
18:37:27.939 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:28.768 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:29.803 [DEBUG] [API REQUEST] /v1/messages source=side_query
18:37:30.061 [ERROR] auto-mode-setup sideQuery failed: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Error"},"request_id":"req_011CeJGk3cfqMpmn7bvQNiJN"}

A separate run on a different model produced:
  req_011CeJGxHFnvw18UFaXrwAsg
  req_011CeJGxSipA9kQcs2X82Ktf

Steps to Reproduce

The headless form reproduces it in about ten seconds and writes nothing to settings:

  1. Open a terminal in any git repository.
  2. Run:

``
claude --debug -p "/auto-mode-setup --wizard posture=mixed scope=project depth=here --propose"
``

  1. Observe stdout:

``json
{
"ok": false,
"code": "api_failed",
"reason": "The model call didn't complete. This is usually temporary - re-run to try again."
}
``

  1. Open the debug log named at session start and search for sideQuery failed. The 429 and its request ID are there.

The interactive path fails identically: run /auto-mode-setup, arrow down to Continue, press Enter, and the scan failure appears within about 40 seconds.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

N/A

Claude Code Version

2.1.240 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Account context, in case it is the cause. This account has hasExtraUsageEnabled: false and cachedExtraUsageDisabledReason: "org_level_disabled" (Max subscription held through an organization). In the same debug log, Fast mode is refused with Fast mode requires usage credits. If the propose call is metered against the extra-usage path, an entitlement refusal surfaced as a bare 429 would explain an instant rejection at 2% utilization, on every model, indefinitely. I cannot confirm that from the client side, and the redacted "message":"Error" body gives the user nothing to act on either way.

Why this took so long to diagnose. The user-facing string is a catch-all around the API call, so a permanent refusal and a transient blip render identically, and the text advises the only action that cannot work. The real status is reachable only via --debug, which the message does not mention. Noting this as context on the same bug rather than as a separate report.

Not a duplicate. #86778 reports a hang with no error surfaced. #87078, #87608 and #88450 fail at removeFromPermissionsAllow validation, which runs only after a proposal has come back, so their propose call succeeded and mine never returns one. #65054 and closed #83037 are in the same family of confusingly surfaced entitlement states, but neither covers this command.

View original on GitHub ↗