[BUG] Advisor tool returns redacted result despite Opus 4.7 model selected (docs say plaintext)
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?
The advisor tool always returns advisor_redacted_result (encrypted) in Claude Code, but the API docs explicitly state that Claude Opus 4.7 as advisor returns plaintext advisor_result.
What Should Happen?
The expected behavior (per API docs) is
Which variant you receive depends on the advisor model: - advisor_result with text — "The advisor model returns plaintext (for example, Claude Opus 4.7)."
With claude-opus-4-7 as the advisor model, the response should contain advisor_result with a readable text field.
Actual behavior
The response always contains advisor_redacted_result with encrypted_content. This is true for Opus 4.6 as executor with Opus 4.7 as advisor, on a Max 20x subscription via Claude Code CLI (v2.1.119).
The CLI renders this as: "Advisor has reviewed the conversation and will apply the feedback" — the actual advice text is inaccessible even in verbose mode.
Error Messages/Logs
Steps to Reproduce
- Set "advisorModel": "claude-opus-4-7" in ~/.claude/settings.json (or run
/advisor claude-opus-4-7) - Start a new Claude Code session with Opus 4.6 as executor
- Give it a multi-step task that triggers an advisor call, or just instruct it to "Call the advisor tool"
- Observe the advisor result displays as: "Advisor has reviewed the conversation and will apply the feedback"
- Press Ctrl+O to expand transcript mode: nothing happens, the full text is not available
- The same happens if starting claude in
--verbosemode.
Expected: In verbose mode or via Ctrl+O, the advisor's plaintext response should be visible.
Actual: The response is always redacted.
Claude Model
claude-opus-4-6
Is this a regression?
No
Last Working Version
_No response_
Claude Code Version
2.1.119 (Claude Code)
Platform
Anthropic API
Operating System
macOS and Linux
Terminal/Shell
iTerm2
Additional Information
Why this matters
- Transparency: In any other service, paying for compute entitles you to the output. Here you're paying for Opus 4.7 inference at Opus rates, and the product of that computation is deliberately hidden from you while being consumed on your behalf. It's a novel and somewhat uncomfortable arrangement, essentially asking customers to trust a black box.
- Debuggability: When the executor makes a questionable decision, knowing whether it followed or ignored the advisor's guidance is essential for understanding what went wrong.
- Trust: Encrypting the response (not just collapsing it in the UI) actively prevents inspection even from users who explicitly want it.
Request
If redaction is intentional for Claude Code / Max users despite the docs, please document that distinction and provide an opt-in to receive plaintext responses.
If this is a bug, the fix should be straightforward since the codebase already handles advisor_result rendering in verbose mode.
3 Comments
Update: Reproducible with direct API call (no Claude Code involved)
Tested with a raw
curlto the Messages API using a pay-as-you-go API key (not OAuth/Max), minimal headers, Sonnet 4.6 executor + Opus 4.7 advisor:Response contains
advisor_redacted_resultwithencrypted_content— same as Claude Code.This rules out OAuth vs API key, Claude Code beta headers, and Max subscription as causes. The API appears to always return encrypted advisor responses regardless of auth method, contradicting the docs.
I can't edit the github issue labels myself but they should probably shift from
platform:macosto something likearea:apiordocs. And the fix isn't in Claude Code's rendering layer, it's either in the API (to actually return plaintext as documented) or in the docs (to stop claiming it does).This appears to be resolved — as of late April 2026 (claude v2.1.123), the API now returns plaintext
advisor_resultinstead ofadvisor_redacted_result. No client-side changes were needed. Closing.This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.