fix(cli): prevent UTF-8 panic in MCP tool description truncation (fixes #1947)

[willamhou]

Summary

• Fix &tool.description[..57] byte-index slice panic in ironclaw mcp test when tool descriptions contain multi-byte UTF-8 characters (CJK, emoji)
• Extract truncate_description() helper using existing floor_char_boundary() from util.rs
• Also fix same pattern in config/channels.rs where &scope[..32] could panic on non-ASCII OAuth scopes

Changes

src/cli/mcp.rs

• Replace inline &tool.description[..57] with truncate_description() that uses floor_char_boundary()
• Add 4 regression tests: ASCII, CJK, emoji, mixed-boundary truncation

src/config/channels.rs

• Replace &scope[..32] with &scope[..floor_char_boundary(scope, 32)]

Test plan

• All 11 mcp cli tests pass
• cargo fmt clean
• cargo clippy zero warnings
• Grep for [.. pattern — no other hardcoded byte-index slices on user-facing strings remain
• CI (needs maintainer workflow approval for fork PR)

[gemini-code-assist]

Code Review

This pull request refactors string truncation logic into a dedicated truncate_description function in src/cli/mcp.rs and updates src/config/channels.rs to use character-safe slicing for error messages. These changes aim to prevent panics when handling multi-byte UTF-8 characters. Comprehensive unit tests were added to verify the truncation logic across various character sets. The review feedback suggests an alternative manual implementation for finding character boundaries to ensure robustness.

[gemini-code-assist]

The implementation should use character-aware truncation to avoid panics. In Rust, s.len() returns byte length, and slicing at an arbitrary index can fail if it's not a character boundary. When truncating, walk backwards from the desired length until a valid character boundary is found using is_char_boundary. Also, ensure tool outputs are truncated for previews to prevent excessive resource usage. Magic numbers are kept inline to maintain readability as per repository guidelines.

Suggested change

	/// Truncate a description to at most 57 display chars, appending "..." if needed.
	/// Uses char-safe boundary to avoid panicking on multi-byte UTF-8.
	fn truncate_description(s: &str) -> String {
	if s.len() <= 60 {
	return s.to_string();
	}
	let end = crate::util::floor_char_boundary(s, 57);
	format!("{}...", &s[..end])
	}
	fn truncate_description(s: &str) -> String {
	if s.len() <= 60 {
	return s.to_string();
	}
	let mut end = 57;
	while end > 0 && !s.is_char_boundary(end) {
	end -= 1;
	}
	format!("{}...", &s[..end])
	}

References

1. When truncating a UTF-8 string at a byte boundary, walk backwards from the desired length until a valid character boundary is found using is_char_boundary to prevent panics.
2. Always truncate tool output for previews or status updates to a reasonable maximum length.
3. Avoid extracting magic numbers into constants if the values are self-documenting in context and creating many constants would reduce readability.

[willamhou]

Hi @henrypark133 @serrrfirat — small bug fix for UTF-8 panic in ironclaw mcp test (same pattern as merged #1679). Rebased onto latest staging. Would appreciate a review. Thanks!

[willamhou]

@henrypark133 @serrrfirat @ilblackdragon Ready for review — fixes UTF-8 panic in MCP tool description truncation (#1947). Tests pass, fmt/clippy clean.

[willamhou]

@henrypark133 @serrrfirat @ilblackdragon Rebased onto latest staging. Small bug fix — same UTF-8 panic pattern as merged #1679.

[henrypark133]

Review: UTF-8 panic fix (Risk: Low)

Clean, focused bug fix. LGTM.

Positives:

• Correctly uses the existing floor_char_boundary utility to prevent byte-index panics
• Both fix sites addressed: mcp.rs (inline slicing) and channels.rs (scope truncation)
• Excellent test coverage: ASCII, CJK, emoji, and mixed-boundary edge cases
• Same pattern as the merged #1679 fix

Convention notes:

• Doc comment on truncate_description says "57 display chars" but the implementation operates on byte length (s.len() <= 60). For multi-byte text the threshold is applied differently than documented. Consider changing the comment to "57 bytes" for accuracy. Non-blocking.