Claude Code Error writing file: причина в Ctrl+O и что делать

Красная строка Error writing file под вызовом Write(путь) причину не называет. Это короткая метка: в обычном виде разговора Claude Code показывает только её, а полный текст ошибки, который получила модель, открывается в режиме транскрипта по Ctrl+O. Как только этот текст перед глазами, становится ясно, какой нужен тип исправления: поменять окружение (права каталога, путь, кодировку, доступ macOS к папке), поменять способ записи (перечитать файл, писать частями) или признать известный баг и просто проверить файл на диске.

Сценарии с правами, каталогом вместо файла и изменённым файлом воспроизведены 16 октября 2026 года в Claude Code 2.1.295 (десктопное приложение, macOS, модель Opus 5.5). Windows, обрезка записи по лимиту токенов и старые баги с относительными путями и plan mode не воспроизводились: для них ниже указаны версии и номера issue на GitHub. Свежая версия на npm по состоянию на 16 октября 2026 года — 2.1.301, поэтому поведение может отличаться от теста.

Где увидеть настоящую причину Error writing file: Ctrl+O

Нажмите Ctrl+O: откроется режим транскрипта (transcript view), где, по документации Claude Code об интерактивном режиме, показаны подробности вызовов инструментов. Найдите неудачный Write или Update и прочитайте текст после Error:. Если он обрезан, в классическом интерфейсе Ctrl+E внутри транскрипта показывает содержимое целиком. Выход обратно — q или Esc.

Справочник ошибок Claude Code описывает ту же схему для правок: в разговоре видна только строка Error editing file, а полное сообщение уходит Claude как результат инструмента и лежит в транскрипте. Отдельного пункта про Error writing file в справочнике нет, поэтому ориентироваться приходится по тексту под меткой.

Вне терминала путь другой. В десктопном приложении Claude на версии 2.1.295 текст результата был виден прямо в развёрнутом вызове. В расширениях для VS Code и JetBrains проще всего попросить Claude дословно процитировать ошибку, которую вернул инструмент: модель получает полный текст в любом интерфейсе.

Прежде чем что-то чинить, посмотрите, что было дальше. Claude обычно сам исправляет ошибку инструмента и повторяет вызов. Если после красной строки идёт успешная запись или Claude записал файл через Bash или python, сначала проверьте сам файл (как это сделать — в конце статьи).

Таблица: текст ошибки, причина и что делать

Тексты в первой, второй и четвёртой строках получены в тесте на 2.1.295, остальные взяты из документации и issue на GitHub. Ниже — подробности по тем случаям, где решение неочевидно.

File has been modified since read: файл изменился между чтением и записью

Это защита, а не поломка. Claude Code помнит, каким прочитал файл, и не даёт Write перезаписать его, если файл с тех пор изменился на диске: иначе пропали бы ваши правки или результат форматировщика. В тесте хватило одной команды echo в файл между Read и Write, чтобы получить ровно это сообщение.

Кто обычно меняет файл, судя по issue #10498, #11463, #8750 и #13207 (версии 2.0.x, конец 2025 года):

• редактор или IDE: автосохранение и форматирование при сохранении. На macOS сообщали, что хватало просто открыть файл в предпросмотре: менялось время изменения, а не содержимое;
• форматировщик или линтер, который запускает ваш hook после правки;
• другой процесс, который держит или переписывает файл. В Windows, WSL и с редактором Unity это давало повторяющийся цикл File has been unexpectedly modified; по issue #10245, тем же сообщением в Windows оборачивается и блокировка файла другим процессом.

Если ошибка случилась один раз, ничего делать не нужно: Claude перечитает файл и повторит запись. Если цикл повторяется, остановите его и уберите источник изменений: закройте вкладку с этим файлом в IDE, выключите форматирование при сохранении на время работы Claude, проверьте собственные hooks. Где в Claude Code включается форматировщик после правки и чем hooks отличаются от других механизмов, разобрано в статье Claude Code: чем отличаются hooks, skills и слэш-команды.

Для Edit правило мягче. По справочнику инструментов Claude Code, начиная с 2.1.208 правка изменённого файла проходит, если заменяемый фрагмент точно и однозначно совпадает с текущим содержимым. Для Write такого послабления в документации нет, и на 2.1.295 запись по-прежнему отклонялась.

Write без предварительного Read: правило зависит от модели и версии

Перезаписывать существующий файл, не прочитав его, можно не всегда. Справочник инструментов делит модели так:

• Claude Opus 4.6, Claude Haiku 4.5 и более старые модели всегда требуют Read: Write в непрочитанный существующий файл заканчивается ошибкой;
• новые модели с Claude Code 2.1.228 могут перезаписать непрочитанный файл, если чтение не потребовало бы запроса разрешения и инструмент Read доступен. В тесте Opus 5.5 так и сделал;
• Jupyter notebooks и файлы, прочитанные лишь частично с пометкой PARTIAL view, требуют чтения на любой модели;
• на новые файлы правило не распространяется. До 2.1.228 чтение требовалось всем моделям.

Чтением считается и просмотр через Bash: cat, head, tail, sed -n, grep, rg и ещё несколько команд, если они запущены на одном файле без пайпов и перенаправлений. Чтение первых трёх строк через параметр limit в тесте Write не заблокировало: это не то же самое, что пометка PARTIAL view.

Если вы работаете на старой модели или на Claude Code до 2.1.228 и видите отказ на существующем файле, попросите Claude сначала прочитать файл целиком. Какая ветка правила действует для сторонних моделей через Anthropic-совместимый API, в документации не сказано.

EACCES и chmod 444: запись блокируют права каталога, а не файла

Судя по тексту ошибки, Write пишет не прямо в целевой файл, а во временный файл рядом с ним и затем переименовывает его: при записи new.txt в каталог с правами 555 тест вернул EACCES: permission denied, open '…/rodir/new.txt.tmp.35734.7a96eba60d51' — имя вида файл.tmp.номер-процесса.хеш.

Из этого следуют две практические вещи.

Первая: при EACCES смотрите права каталога, а не файла.

ls -ld путь/к/каталогу
chmod u+w путь/к/каталогу

Если владелец каталога — другой пользователь, chmod не поможет; меняйте владельца или работайте в каталоге, куда у вас есть запись.

Вторая: chmod 444 файл от Write не защищает. В тесте файл с правами -r--r--r-- в доступном для записи каталоге был перезаписан, а права после этого остались прежними. Защищать файл от правок Claude нужно deny-правилом в settings.json. Правило Edit(...) действует на Edit, Write и NotebookEdit, а правило Read(...) в deny запрещает ещё и запись, включая создание нового файла (для Write — с 2.1.228):

{
  "permissions": {
    "deny": ["Edit(./config/prod.env)"]
  }
}

Режим без подтверждений здесь ничего не меняет: тест шёл в режиме bypass, и EACCES всё равно появился, потому что права выдаёт операционная система, а не Claude Code. Что именно обходит этот режим и что продолжает блокировать вызовы, описано в статье Claude Code --dangerously-skip-permissions: как включить и что он обходит.

На macOS отдельный случай — EPERM в ~/Desktop, ~/Documents, ~/Downloads и iCloud Drive. Справочник ошибок объясняет это тем, что macOS не пускает терминал в такие папки; описано это для чтения рабочего каталога, но та же блокировка мешает и записи. Закройте терминал через Cmd+Q и откройте снова. Если не помогло, включите папку для своего терминала в «Системные настройки → Конфиденциальность и безопасность → Файлы и папки» (System Settings > Privacy & Security > Files and Folders).

Файлы в Windows-1251: Edit отказывается, Write переводит их в UTF-8

С кодировкой Edit и Write ведут себя противоположно, и второй вариант опаснее.

Edit файл не в UTF-8 не трогает: возвращает File is not valid UTF-8…, а Claude получает подсказку внести изменение командой оболочки с сохранением кодировки или спросить вас о переводе в UTF-8. В документации примеры — Windows-1252, Shift-JIS и GBK, но Windows-1251 с кириллицей попадает в ту же категорию. Такой отказ появился только в Claude Code 2.1.296: по справочнику ошибок о File is not valid UTF-8, более ранние версии Edit и NotebookEdit применяли правку и заменяли каждый нераспознанный байт на U+FFFD, то есть молча портили файл в Windows-1251. Если у вас версия старше 2.1.296, обновите Claude Code через claude update.

Write такой файл заменить может (если в новом тексте нет символа замены U+FFFD) и сохраняет результат в UTF-8. Исходная кодировка теряется без всякой ошибки, и программа, которая ждёт Windows-1251, увидит кракозябры.

Как проверить и перевести файл (проверено на macOS):

file -I старый.txt
iconv -f WINDOWS-1251 -t UTF-8 старый.txt > старый.utf8.txt

file -I покажет только то, что это не UTF-8: для файла в Windows-1251 macOS выводит charset=iso-8859-1. Если файл можно держать в UTF-8, переведите его и замените оригинал. Если кодировку нужно сохранить, прямо скажите Claude не использовать Write для этого файла и править его командой оболочки.

Большие файлы, субагенты и шлюзы: content is missing и обрезанная запись

Сообщение InputValidationError: Write failed due to the following issue: The required parameter content is missing (или file_path) означает, что вызов Write пришёл без параметра: ответ модели оборвался посреди вызова инструмента. Открытая issue #895 собирает такие случаи на больших файлах и в длинных сессиях, вплоть до Claude Code 2.1.161 с Opus 4.7; похожие отчёты есть у субагентов (#47189) и на версиях 2.1.19–2.1.20 (#21159). В issue #7927 Error writing file шёл сразу после API Error: Claude's response exceeded the 32000 output token maximum (старая версия 1.0.120).

Лимит вывода описан и в справочнике ошибок: если ответ отправляется повторно без стриминга, его потолок — 64 000 токенов, и переменная CLAUDE_CODE_MAX_OUTPUT_TOKENS его не поднимает. До 2.1.299 такой обрезанный ответ ещё и молча завершал ход.

Через шлюзы и сторонние модели сбой встречается чаще. Один из участников #895 объясняет это так: при сбое стриминга LiteLLM и OpenAI-совместимые прокси переходят на нестриминговый запрос с меньшим лимитом вывода, и JSON вызова обрывается посреди параметра. Это разбор пользователя, Anthropic его не подтверждала. Другой участник сообщил, что после перехода с GLM 4.5 на GLM 4.7 все вызовы инструментов стали приходить с пустыми параметрами.

Повторять ту же запись бесполезно, если ошибка дважды подряд вернулась на том же файле: вызов того же размера оборвётся так же. Меняйте способ записи:

1. Попросите сначала каркас файла примерно на 100 строк, а затем дописывать его правками по 100–200 строк. Этот приём участники #895 подтверждают чаще всего.
2. Закрепите правило в CLAUDE.md, чтобы не повторять его в каждом запросе:

Большие файлы пиши частями: сначала каркас до 100 строк,
потом дописывай правками по 100–200 строк. Один файл или один раздел за ответ.

3. Если ответ оборвался по лимиту вывода, документация советует ответить continue или просить вывод меньшими частями, «one file or one section per reply».
4. Если работаете через шлюз или стороннюю модель, сравните ту же задачу на другой модели или другом провайдере. Как в Claude Code задаются базовый URL, ключ и модель, описано в статье Настройка Claude Code API: ключи, settings.json, модели и шлюзы, а первые ошибки с OpenRouter и DeepSeek — в статье Claude Code с OpenRouter и DeepSeek: маршруты, настройка и первые ошибки.

Error writing file, а файл записан: известные баги по версиям

Иногда красная строка — ложная тревога или сбой первой попытки, а файл в итоге на месте. Ни в одной из этих issue исправление не указано, так что статус исправления неизвестен.

Что делать: проверить файл на диске (следующий раздел), посмотреть версию через claude --version и обновиться командой claude update, если вы на одной из перечисленных версий. Для Windows с Git Bash переход Claude на python -c — обходной путь, а не исправление. Убедитесь, что спецсимволы в итоговом файле не испортились.

Error editing file и String to replace not found: строка не совпала

Error editing file — та же короткая метка, только для Edit. Причины частично общие с Write: изменённый или непрочитанный файл, кодировка, защита worktree, deny-правило Read. Своя причина у Edit одна: заменяемый фрагмент не найден или найден больше одного раза. В тесте на 2.1.295 это дало два сообщения: String to replace not found in file. и Found 2 matches of the string to replace, but replace_all is false….

Edit ищет точное совпадение, без регулярных выражений и нечёткого поиска. Достаточно одного лишнего пробела или другого отступа, чтобы промахнуться. Кроме того, фрагмент должен встречаться в файле ровно один раз; если он повторяется, Claude нужно взять кусок длиннее или заменить все вхождения через replace_all. Обычно Claude справляется сам: перечитывает файл и берёт актуальный фрагмент. Если правка срывается снова и снова, проверьте, не переписывает ли файл форматировщик сразу после каждой правки: это тот же случай, что и File has been modified since read.

Куда Claude Code сохраняет файлы и как проверить, что запись прошла

Claude Code пишет туда, куда указывает параметр file_path в вызове Write; путь виден в строке Write(…) и полностью — в транскрипте. Отсутствующие родительские каталоги Write создаёт сам: в тесте запись в newparent/sub/file.txt прошла без ошибки. Поэтому «нет папки» не бывает причиной Error writing file, а опечатка в пути не вызовет ошибку — файл просто появится в новом каталоге. Если не можете найти файл, сверьте путь в транскрипте.

Проверка после записи, особенно после ложной тревоги или записи через Bash:

ls -l путь/к/файлу
head -n 20 путь/к/файлу
git diff --stat

Файл на месте, его начало совпадает с ожидаемым, а git diff показывает правку там, где она нужна, — значит, всё в порядке и повторять запись не нужно. Если файл пустой, обрезан на середине или в нём кракозябры, вернитесь к разделам про обрезанную запись и про кодировку.

Вопросы об ошибках записи в Claude Code

Почему Claude Code после ошибки записи переходит на Bash или python?

Так модель обходит неудачный вызов Write. Это нормально, если файл в итоге правильный, но причина сбоя никуда не делась. Откройте Ctrl+O и посмотрите текст первой ошибки. В Windows с Git Bash такое переключение типично для текста со спецсимволами (#63838).

Поможет ли --dangerously-skip-permissions от Error writing file?

Нет. Этот режим убирает запросы подтверждения, но не права файловой системы, не блокировки macOS, не кодировку и не обрезку вызова. В тесте EACCES появился именно в режиме bypass. Deny-правила в этом режиме тоже продолжают действовать.

Почему Claude Code не работает вообще, а не только не записывает файлы?

Если падает сам процесс, а не отдельный вызов Write или Edit, это другая проблема. Разбор по веткам — в статье Claude Code process exited with code 1: найдите ветку перед переустановкой.