write_file / replace fail with ENAMETOOLONG on file names of 215–255 bytes (temp file name exceeds NAME_MAX)

Finding: In Gemini CLI built from commit fb972b2f87 (0.65.0-nightly.20261006), an external report says write_file and replace can fail with ENAMETOOLONG when the destination file name is about 215–255 bytes, even though the name itself is legal. This is an external report only; KFA did not reproduce it. Source: https://github.com/google-gemini/gemini-cli/issues/29702 Reported symptom and environment: The reporter tested on Linux x86_64 (ext4) with Node 20+, via --acp mode with a client lacking fs capabilities, so the write goes through StandardFileSystemService, which they say is the same path as the interactive CLI. The error names only the temp file ('<name>.<uuid>.tmp'). The target file is not created, and an existing file with such a name can't be overwritten or edited. The reporter notes that shell writes of the same name succeed (issue #29702). Reported cause (not maintainer-confirmed): The reporter links this to the atomic-write change (#29499). writeTextFile writes to a sibling temp file named as the destination plus .<uuid>.tmp, which is 41 bytes longer, then renames it into place. A name of 215 bytes or more can therefore push the temp name past the 255-byte NAME_MAX on Linux/macOS. Length is in bytes, not characters, so CJK names (3 bytes per character in UTF-8) hit it at roughly 72–85 characters. A community commenter said the cause matches the cited line (issue comments). No maintainer has confirmed it in the supplied comments. Reproduction as reported: ask the agent to create a file whose name is 250 'a' characters plus .txt (254 bytes) containing hello, and approve write_file. The reporter says it fails with ENAMETOOLONG on the .tmp path while a shell echo to that name works. Fix status: Unmerged. A contributor said they opened draft PR #29703, aiming to keep the temp file in the same directory so the rename stays atomic, with tests for ASCII and CJK names. The reporter said they will not fix it themselves. No merged commit or released fix is evidenced in the supplied sources, and the draft PR itself was not inspected. Diagnosis hint, as reported: if write_file or replace fails with an ENAMETOOLONG error that mentions a .tmp path while the target name is close to 255 bytes, this issue is a candidate explanation. Check the byte length of the name, not the character count. Limitations: single reporter, Linux ext4 only, and comment coverage may be incomplete. No workaround is documented in the sources, so none is offered here. Affected stable versions are unknown.