Snapshot revert does not restore modified Unicode filenames

[ryrenz]

Summary

Snapshot.revert() does not reliably restore modified files when the filename contains Unicode characters.

Current behavior

• Creating a new Unicode-named file and reverting works
• Modifying an existing Unicode-named file and reverting does not restore the original content

There is already a skipped regression test for this case in:
packages/opencode/test/snapshot/snapshot.test.ts

test.skip("unicode filenames modification and restore", async () => {

Suspected cause

My current suspicion is that Snapshot.revert() falls back incorrectly after git checkout fails for the target path.

In packages/opencode/src/snapshot/index.ts, patch.files are stored as absolute paths, and revert() tries to run:

git checkout <hash> -- <file>

If that checkout fails, the fallback checks whether the file existed in the snapshot with a relative path via git ls-tree. When the file did exist, the code keeps the current file instead of restoring its original contents.

That would explain why:

• new Unicode files get deleted correctly on revert
• but existing Unicode files stay modified

Repro

A minimal repro seems to already exist in the skipped test above:

1. Create a tracked file with a Unicode filename
2. Take a snapshot
3. Modify the file contents
4. Call Snapshot.revert([patch])
5. Expected: original contents restored
6. Actual: modified contents remain

If this sounds like a valid bug, I can send a PR with a regression test and a fix.

[ryrenz]

Quick update: I dug into this further and could not reproduce it locally on macOS after running the skipped test logic directly against the current codebase.

I also checked the git history:

• The Unicode snapshot tests were added on January 24, 2026 in commit 32e6bcae3 (core: fix unicode filename handling in snapshot diff by disabling quote escaping)
• This specific test was changed to test.skip(...) on February 1, 2026 in commit 0f3630d93 with the message ci: skip unicode filename test due to inconsistent behavior causing CI failures

So this now looks more like a historical CI inconsistency / stale skipped test than a currently confirmed product bug. Closing this issue for now unless someone can still reproduce it on a current environment.