fix(claude-code): remove incorrect agent_visible filter on user message

[blackgirlbytes]

Summary

Fixes #7930 - Claude Code provider silently drops user messages in CLI

Reported in Discord by community member https://discord.com/channels/1287729918100246654/1287729920319033345/1483114312720584794

Problem

The last_user_content_blocks function finds the last user message to send to Claude Code CLI, but then incorrectly filters it by is_agent_visible(). Since we explicitly selected this message to send, the visibility filter should not apply.

When a message has agent_visible: false in its metadata, the filter removes it entirely, resulting in empty content being sent to Claude. This causes the CLI to appear to hang with no response.

Root Cause

This was introduced in commit 4abf91e (PR #7108, Feb 10, 2026) when refactoring from messages_to_content_blocks to last_user_content_blocks. The original function iterated over all messages (where filtering made sense), but the new function only processes the single last user message - the filter was incorrectly preserved.

Fix

Remove the .filter(|m| m.is_agent_visible()) since we explicitly want to send the user's input regardless of visibility metadata.

Testing

• Existing tests pass
• The fix is a one-line change with clear semantics

[blackgirlbytes]

/goose review this PR . Tell me if there's any issues you found in this change.

[github-actions]

Summary: This PR removes a redundant is_agent_visible() filter from last_user_content_blocks in the Claude Code provider. The change is correct - filtering a single explicitly-selected message makes no semantic sense. However, the impact described in the PR may be overstated since upstream code already filters messages before they reach this point.

✅ Highlights

1. Correct fix for a logic error (claude_code.rs:286): The original code first finds the last user message, then filters it by visibility - which effectively discards it if agent_visible: false. Since the function explicitly selects this message to send, the filter should not apply.

2. Minimal, surgical change: Single-line removal that correctly addresses the issue without collateral changes.

🟢 Suggestions

1. PR description accuracy (LOW confidence):

   The PR claims this bug causes "CLI to appear to hang with no response." However, I traced the code path and found that stream_response_from_provider in reply_parts.rs (line ~25) already filters messages to only agent-visible ones before passing them to any provider:

   let filtered_messages: Vec<Message> = messages
       .iter()
       .filter(|m| m.is_agent_visible())  // Already filtered here
       .map(|m| m.agent_visible_content())
       .collect();

   This means in normal execution, non-visible messages would never reach last_user_content_blocks. The fix is still correct (removes dead code that's semantically wrong), but the described bug scenario may not occur in practice through the normal agent flow. The issue could only manifest through:

   • Direct unit tests
   • Future code paths that bypass stream_response_from_provider

   Consider adjusting the PR description to reflect this is primarily a code clarity/correctness fix rather than a critical bug fix.

2. Consider adding a test case (optional):

   The existing test_last_user_content_blocks test cases don't include a message with agent_visible: false. Consider adding a test to prevent regression:

   #[test_case(
       vec![Message::user().with_text("Hello").user_only()],
       &[json!({"type":"text","text":"Human: Hello"})]
       ; "user_only_message_still_processed"
   )]

---

Review generated by goose

[codefromthecrypt]

Thanks for fixing this!

[codefromthecrypt]

ps I added a commit to feed the bot, but I think we should soon plan getting off double-maintenance of both acp and non-acp variants of the claude provider. a lot of this hairy stuff should be in one place (in the acp adapter we use as a lib)