[BUG] Edit tools don't normalize Unicode (NFC vs NFD) causing edit failures on macOS

[LifetimeVip]

Description

Both V1 and V2 edit tools do not normalize Unicode before comparing file content with oldString. On macOS where files are often stored in NFD (decomposed) form, while AI-generated text is NFC (precomposed), Unicode canonically-equivalent characters like é (U+00E9) vs e + combining accent (U+0065 U+0301) will not match, causing edit failures.

Affected Files

• packages/core/src/tool/edit.ts:164 - countOccurrences uses indexOf without normalization
• packages/core/src/tool/edit.ts:187 - replace uses string comparison without normalization
• packages/opencode/src/tool/edit.ts:132 - replace() function uses indexOf without normalization

Inconsistency

packages/opencode/src/patch/index.ts:486 already has NFC normalization for apply_patch:

return tryMatch(lines, pattern, startIndex, (a, b) => a.normalize("NFC") === b.normalize("NFC"), eof)

The edit tools should have the same normalization for consistency.

Steps to reproduce

1. On macOS, create a file with decomposed Unicode (e.g., touch $(echo '\u00e9' | iconv -f UTF-8 -t UTF-8-MAC))
2. Ask the AI to edit text containing accented characters
3. The AI's NFC-formatted oldString won't match the file's NFD content
4. Edit fails with "oldString not found"

OpenCode version

1.17.3

[github-actions]

This issue might be related to an existing open issue. Please check:

• apply_patch verification fails on canonically-equivalent Unicode — seekSequence needs an NFC pass #31651: Same NFC vs NFD canonical-equivalence mismatch — that issue targets apply_patch/seekSequence while this one targets the edit tool, but they share the same root cause and proposed fix pattern.

You may want to coordinate with the reporter of #31651 or consider whether a single PR could address both tools at once.

[LifetimeVip]

已提交此问题的修复 PR #31896（device path validation, edit safety, Unicode NFC, glob/grep security）