Sessions using the advisor() tool become permanently unrecoverable — "Advisor tool result content could not be processed" 400 on every subsequent prompt and on /compact

Summary

Any Claude Code session that used the advisor() tool eventually becomes unrecoverable: every new prompt returns 400 "Advisor tool result content could not be processed", and /compact returns the same error (so compaction can't clear it either). The only command that works is /clear, but that wipes all conversation context — which defeats the purpose of recovery.

I have 4 affected sessions in one project directory. 7 more sessions in the same directory contain advisor_tool_result blocks and will presumably break the next time a prompt is sent.

Environment

• Claude Code versions observed in affected sessions: 2.1.105 (when the advisor result was stored) and 2.1.112 (when the error started surfacing)
• Platform: macOS (Darwin 25.3.0, arm64)
• Shell: zsh
• Default model during the affected period: claude-opus-4-7[1m], with some earlier advisor calls recorded under claude-opus-4-6
• The sessions were all in plan permission mode and used extended context (1M tokens)

Reproduction

Hard to deterministically reproduce because the trigger involves server-side encryption key state, but the pattern is consistent:

1. Start a long-lived Claude Code session (hours of work, tens of turns)
2. Call advisor() one or more times during that session
3. Resume / continue the session 1–3 days later
4. Ask any prompt, even hi or what's next?
5. API returns 400 "Advisor tool result content could not be processed"
6. Try /compact — same 400 error (inherits the poison; compaction is itself a model call with full history)
7. /clear — works, but wipes all conversation context. Not a real recovery — the user loses everything they wanted to pick back up.

What the JSONL actually stores

Each affected assistant message has this block inside message.content:

{
  "type": "advisor_tool_result",
  "tool_use_id": "srvtoolu_01...",
  "content": {
    "type": "advisor_redacted_result",
    "encrypted_content": "Es4VCio...<~3-10 KB base64 blob>"
  }
}

Notable:

• srvtoolu_ prefix (not toolu_) — this is a server-side tool
• The content type is advisor_redacted_result with a server-encrypted payload
• message.usage.iterations on these turns also includes an entry with "type": "advisor_message"

On replay, the API rejects the request with the 400 above.

Expected behavior

One of:

1. Advisor tool results should be replayable indefinitely for the life of the session (same as any normal tool result)
2. Or — if server-encrypted results have a TTL — Claude Code should either:

• Strip expired advisor_tool_result blocks from the request before sending
• Replace them with a plaintext summary / placeholder
• Warn the user and offer a one-click "scrub expired advisor results from this session" action

Most importantly, /compact should never inherit this failure. Compaction is specifically the user's escape hatch when a session is in a bad state; if /compact can't run, the user has no recovery path within Claude Code itself short of /clear, which defeats the point of recovery by throwing away the conversation.

Actual behavior

• Every new turn → 400 "Advisor tool result content could not be processed"
• /compact → same 400
• /clear → works, but wipes all context (not a real recovery)
• Session is effectively dead. User loses all open work unless they manually edit the JSONL.

Impact

• Permanent loss of session context for any user who calls advisor() in a long-running session
• No non-destructive recovery path via supported commands
• Silent data hazard: the session looks fine when stored, breaks days later with no prior warning

Specifically in my case: 4 named sessions (webpack-chunk-config-simplify, cleanup-orphan-components, fix-state-bleed-bugs, social-cards-cleanup) are all blocked. I can't continue any of them without losing context.

Request IDs for server-side trace

• First advisor result stored (works at the time): req_011Ca3Kizz4BMioaM4zc2ymR (2026-04-14 T08:11:30Z, CC 2.1.105)
• First 400 on the same session: req_011Ca9Qj8EEDCDMNXcWMVwFQ (2026-04-17 T13:19:00Z, CC 2.1.112)
• Error request_id from a typical repro after rename: req_011Ca9TztHsdsM6pzmbnmy6v
• /compact failure: req_011Ca9U4i64pTN5XSzr4You6

~3-day gap between storage and first failure in this case. Unclear whether that's a TTL, a model-version rollover, or something else.

Suggested mitigations

Short term (user-visible):

• Make /compact robust to advisor_tool_result blocks in history (strip before compaction call). This alone restores a non-destructive recovery path.
• Add a /recover or /scrub-advisor command that replaces expired advisor results with plaintext placeholders in place
• Surface a clearer error message than "Advisor tool result content could not be processed" — current wording doesn't hint that the fault is in stored history, not the current prompt

Medium term (architectural):

• Store advisor result summaries as plaintext in the JSONL alongside the encrypted payload, so replay has a fallback if decryption fails
• Document the TTL/lifecycle of advisor_redacted_result so users know long-running sessions are at risk

Happy to share JSONL snippets (sanitized) if helpful.