[BUG] Interactive turns silently no-op (0s, 0 tokens, no /v1/messages request) on a Claude Team seat — --print works, no error shown

Open 💬 0 comments Opened Jun 22, 2026 by aziztoba

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?

On a Claude Team seat, every interactive turn ends instantly with no model response — the spinner shows "… for 0s", the transcript records
a turn_duration with no assistant message, and --debug shows no /v1/messages request is ever dispatched for the user's prompt. There is
no error message — it silently does nothing.

The same account works fine via claude --print, and a personal Claude Max account works perfectly in interactive mode on the exact same
machine and binary. So the turn-dispatch path is being silently skipped for this account, with no surfaced error — that silent failure is
itself the bug, whatever the underlying entitlement cause.

In --debug, the only /v1/messages calls that fire are source=quota_check (startup) and source=generate_session_title (haiku). The main
Opus turn shows 0 dispatches in every debug log.

Steps to Reproduce

  1. Log in with a Claude Team seat (org-managed).
  2. Start an interactive session: claude
  3. Type any message (e.g. hi) and press Enter.

Expected: the model responds, or an explicit error explains why the turn can't run.
Actual: spinner shows "… for 0s", no response, no error; transcript has the user message + turn_duration but no assistant entry; --debug
shows no /v1/messages request for the turn.

Environment

  • Claude Code: 2.1.185
  • OS: WSL2 (Linux) on Windows
  • Login: Claude Team account (org-managed); organizationRole: user
  • Usage at time of failure: ~7% session / ~1% week (not a quota limit)

Already ruled out (interactive still fails after each)

  • Model (Opus and Sonnet) · Auto mode (disabled via disableAutoMode) · MCP (--strict-mcp-config) · hooks · the project directory (fails in

a neutral dir too) · quota (7%/1%) · a fresh/clean .claude.json · a fresh /login · extended thinking (MAX_THINKING_TOKENS=0).

  • A personal Max account on the same machine/binary works interactively → isolates it from the local setup.

Note (transparency): this install is patched with tweakcc, but since the identical binary works interactively for a personal account and
fails only for the Team seat, the patch is not the cause. Happy to reproduce on a stock build if helpful.

What Should Happen?

The interactive turn should dispatch to the API and the model should respond. If the
account/seat genuinely cannot run the turn (e.g., an entitlement/quota gate), Claude Code
should show an explicit error explaining why — not silently end the turn in 0s with no
message, no response, and no /v1/messages request.

Error Messages/Logs

There is NO error message — silent failure is part of the bug.

  --debug shows only background calls dispatch; the user's turn never does:

  [DEBUG] [API REQUEST] /v1/messages ... source=quota_check
  [DEBUG] Org fast mode: disabled (extra_usage_disabled)
  [DEBUG] [auto-mode] verifyAutoModeGateAccess: enabledState=enabled model=claude-opus-4-8 modelSupported=true
  [DEBUG] [API:timing] dispatching to firstParty model=claude-haiku-4-5-20251001
  [DEBUG] [API REQUEST] /v1/messages ... source=generate_session_title
  [DEBUG] Stream started - received first chunk        # <- title generation only
  # user prompt submitted here
  # (no further [API REQUEST]; the main turn is never dispatched; turn_duration recorded with no assistant message)

  # Across every debug log: 0 occurrences of "dispatching to firstParty model=claude-opus".
  # Account usage at the time: ~7% session / ~1% week (not a quota limit).

Steps to Reproduce

  1. Log in with a Claude Team seat where the org has extra usage / fast mode disabled

(extra_usage_disabled).

  1. Start an interactive session: claude
  2. Type any message (e.g. "hi") and press Enter.

Result: spinner shows "… for 0s", no response, no error. Transcript has the user
message + a turn_duration entry but no assistant message. --debug shows no /v1/messages
request for the turn.

Cross-checks that isolate it:

  • claude --print "hi" on the SAME account → works.
  • A personal Claude Max account on the SAME machine/binary, interactive → works.
  • Fails in any directory; fails after a fresh /login; fails with a clean config.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.185 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Likely root cause: a gate introduced/changed in 2.1.185 around quota/extra-usage/fast-mode
appears to block interactive turn dispatch on Claude Team seats where the org has
extra_usage disabled. It worked on 2.1.175; a personal Max account (extra usage available)
is unaffected on 2.1.185; --print bypasses it. The real defect is that the turn is dropped
silently with no surfaced error.

Already ruled out (interactive still fails after each): model (Opus & Sonnet), Auto mode
(disabled via disableAutoMode), MCP (--strict-mcp-config), hooks, the working directory
(fails in a neutral dir), quota (7%/1%), a clean .claude.json, a fresh /login, extended
thinking (MAX_THINKING_TOKENS=0).

Transparency: this install is patched with tweakcc, but the identical binary works
interactively for a personal account and fails only for the Team seat, so the patch is not
the cause. Happy to reproduce on a stock build if needed.

View original on GitHub ↗