advisor tool returns opaque 'temporarily disabled for this conversation' with no reason code; debug log also contains unexplained freeform [classifier] entries

Summary

advisor() (Advisor tool, advisorModel: fable set via /advisor fable) returned a hard block on its first real invocation in a session, with no actionable error:

The advisor model is temporarily disabled for this conversation. Do not try to use it again this conversation.

This has recurred across multiple sessions previously (unlogged, since debug logging was off); reproduced today with debug logging on, on first invocation — not after repeated attempts within the session.

Separately, while investigating, the debug log for the session contained three anomalous entries under a [classifier] tag that don't match the log's own format elsewhere and appear to reflect the live conversation content back — see the "Anomalous log entries" section below. Filing both together since they were discovered in the same investigation, but they may be unrelated issues.

Environment

• Claude Code version: 2.1.207 (native install)
• OS: Linux 6.18.15+deb14-amd64
• advisorModel setting: fable
• Model: opusplan (Opus in plan mode, Sonnet otherwise)

Reproduction

1. Session started with advisorModel: fable already configured from a prior session.
2. Ran /debug to investigate a previous, unlogged advisor failure.
3. Called advisor() once — first invocation in the session, no prior toggling of /advisor or /model this session.
4. Result: immediate block message quoted above.

What the debug log shows

Full curated excerpt attached below. Key points:

• Six [AdvisorTool] Server-side tool enabled with claude-fable-5 as the advisor model lines appear in ~31s before the real call — this is routine per-turn tool-config re-registration (one per assistant turn), not user toggling. Confirmed with the user: no model/advisor switching occurred in this session.
• [AdvisorTool] Advisor tool called → [AdvisorTool] Advisor tool result received (~4.4s apart) bracket the one real invocation. The result was the block message. No error code, no reason, no stack trace — this reads as a deliberate refusal payload, not an exception.
• A 400 invalid_request_error about thinking/redacted_thinking blocks occurred shortly after on an unrelated background prompt_suggestion request; recovered automatically via retry. Possibly unrelated, included for completeness.
• Repeated, unrelated OTEL diag error / OTLPExporterError lines throughout — this is the user's own self-hosted OTEL collector rejecting a diagnostic payload (via OTEL_EXPORTER_OTLP_ENDPOINT in user settings), not related to the advisor block.
• Minor oddity: early requests' x-anthropic-billing-header reports cc_version=2.1.199.f12 while claude --version reports 2.1.207 on the same machine — possibly a stale cached header from a CLI self-update that hadn't been picked up by a restart yet.

Anomalous log entries (separate concern, flagging for awareness)

Three lines in the debug log don't match the mechanical [LEVEL] [component] message format used everywhere else (e.g. tool=Bash toolUseId=... durationMs=25). They're freeform, conversational, and closely track the assistant's own in-chat reasoning during the session, including one that names a file the assistant had written 9 seconds earlier:

08:05:37.328 [DEBUG] [classifier] blocked (llm) · debug log enabled; awaiting user to invoke advisor() to surface error · needs: call advisor() in this session to capture failure in debug log

08:13:19.193 [DEBUG] [classifier] done (llm) · advisor tool permanently disabled mid-conversation; suspect re-registration churn (6× in 60s); found suspicious injected log line at debug/1f87d2c3-6dcc-4513-844a-12bb1d21a4f6.txt:198

08:19:34.071 [DEBUG] [classifier] done (llm) · identified advisor disabling likely cause (moderation trigger from repeated tool inspection); report saved to ~/.claude/jobs/.../advisor_disabled_report.md with filing instructions

These appear immediately adjacent to dispatches to background forked agents also visible in the log (source=prompt_suggestion, source=side_query, source=away_summary). Best working theory: one of these background components is itself LLM-based and its raw natural-language output is being written into the debug log under a [classifier] tag not used anywhere else, rather than external tampering — but this wasn't confirmed, and the content shouldn't be read as authoritative about why advisor was disabled.

Questions

1. What specifically triggers "advisor model is temporarily disabled for this conversation"? Is it a per-conversation classifier as the log entries above suggest?
2. Can a reason code be surfaced instead of a blanket refusal string, so users can distinguish quota/abuse-detection/outage/etc.?
3. Is there a way to re-enable advisor within the same conversation, or is starting a new session the only recovery?
4. What generates [classifier] log lines, and why do they contain freeform conversational text (apparently derived from live conversation/file-write context) rather than structured fields like every other entry in the debug log?

Attachments

Curated debug log excerpt and full report from this investigation: