[FEATURE] Add encoding parameter to Read/Edit tools for non-UTF-8 files

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When working with source files in non-UTF-8 encodings (e.g., ISO-8859-2), the only option is to use pre/post hooks that convert files on disk before Read/Edit and convert back after. This causes several issues:

1. Edit "unexpectedly modified" errors - the post-hook after Read restores the original encoding, then the pre-hook before Edit converts again, and Edit detects the file changed between Read and Edit. Workaround: leave file in UTF-8 after Read and clean up later via Stop hook.
2. git diff shows false encoding changes - during a response, all touched files are temporarily in a different encoding on disk, making git operations unreliable.
3. Complex hook choreography - requires coordinating PreToolUse, PostToolUse, and Stop hooks with backup files, stale backup detection, and cleanup scripts. Easy to get wrong.

Proposed Solution

Add an optional encoding parameter to the Read and Edit tools (and possibly Write). When specified, the tool would handle encoding conversion in memory:

• Read with encoding: "ISO-8859-2" - reads bytes from disk, converts to UTF-8 in memory, returns UTF-8 to Claude. File on disk is never modified.
• Edit with encoding: "ISO-8859-2" - converts old_string/new_string from UTF-8 to the target encoding in memory, applies the edit on the file in its original encoding. File stays in its original encoding throughout.

This would make non-UTF-8 files work as smoothly as UTF-8 ones, with no hooks needed.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

File operations

Use Case Example

_No response_

Additional Context

This came up working with a medium to large C++ ERP codebase (~1000 .cc/.h files in ISO-8859-2 encoding). The current hook-based solution theroretically works, but mostly creates issues, and bloats context with information, how to handle it.