[BUG] Write/Edit on Windows SMB UNC path crashes CLI with uncaught EUNKNOWN

Summary

On Windows, when the Write or Edit tool targets a file on an SMB share via a UNC path (\server\share\...), an SMB-side error returns EUNKNOWN from openSync. The Bun runtime does not catch this and the entire claude CLI process terminates instead of surfacing the error to the model as a normal tool failure.

Reproduced twice in the wild. Both crashes have the same Bun stack trace.

Stack trace

ERROR  EUNKNOWN: unknown error, open '\<server>\<share>\<path>\<file>'

 -     at openSync (unknown)
 - readSync (B:/~BUN/root/src/entrypoints/cli.js:55:1177)
 - btH (B:/~BUN/root/src/entrypoints/cli.js:127:10601)
 - xm  (B:/~BUN/root/src/entrypoints/cli.js:128:181)
 - yG  (B:/~BUN/root/src/entrypoints/cli.js:130:54)
 - _2_ (B:/~BUN/root/src/entrypoints/cli.js:9040:20754)
 - $Y  (B:/~BUN/root/src/entrypoints/cli.js:517:21131)
 - r3  (B:/~BUN/root/src/entrypoints/cli.js:517:39896)
 - n4  (B:/~BUN/root/src/entrypoints/cli.js:517:50706)
 - j_H (B:/~BUN/root/src/entrypoints/cli.js:517:87761)

(Frame line numbers vary slightly between builds; identical shape.)

Repro

1. Windows 10/11 client with an SMB share mounted (\server\share\...).
2. In a Claude Code session, ask Claude to write a file to a UNC path where the parent directory either:

• does not exist, OR
• was just created in the same session via an SSH mkdir -p to the same share (so the SMB negative-name cache on the client is still populated).

1. The Write tool call crashes the entire CLI. Conversation context is lost unless /resume works.

Trigger #2 is the easier one to reproduce: Bash tool runs ssh host 'mkdir -p /mnt/share/newdir', immediately followed by Write to \host\share\newdir\file.md. SMB on the client hasn't refreshed, the open returns an NT status that libuv can't classify, and you get EUNKNOWN instead of ENOENT.

Root cause (probable)

Windows SMB returns NT status codes such as STATUS_OBJECT_PATH_NOT_FOUND and STATUS_BAD_NETWORK_NAME. libuv maps recognised codes (e.g. ERROR_FILE_NOT_FOUND → UV_ENOENT) but unrecognised codes fall through to UV_UNKNOWN → EUNKNOWN. The CLI catches ENOENT (which is why missing-file errors on local Windows paths return cleanly) but does not catch EUNKNOWN, so the exception escapes the tool boundary and crashes the process.

Expected behaviour

Any filesystem error from the Write or Edit tool — including EUNKNOWN, EACCES, EBUSY, EPERM, etc. — should be caught and returned to the model as a regular tool error, the same way ENOENT already is. The CLI should never terminate because of a single failed tool call.

Suggested fix

Wrap the openSync/writeFileSync calls in the Write and Edit tool implementations with a try/catch that converts any thrown Error (regardless of code) into a structured tool error result. The current catch appears to only special-case a small set of codes.

Workaround

Avoid Write/Edit against UNC paths on Windows. Write to a local Windows path and copy with scp, or write via SSH heredoc on the remote host.

Environment

• OS: Windows 10/11
• Claude Code: Bun-packaged build (per the B:/~BUN/root/... paths in the stack trace)
• Filesystem: file targeted via SMB UNC path